Ukratko: Symfony sigurnost nakon PHP2Shella znači: zakrpati PHP, ponovno pokrenuti sve procese uključujući Messenger workere, a potom provjeriti secrets, predmemoriju i profiler. Ranjivost je u PHP-u, a ne u Symfonyju; samo Symfony ažuriranje je ne zatvara.
Zašto PHP2Shell pogađa svaki Symfony projekt
Symfony je temelj mnogih poslovnih aplikacija, API-ja i portala, a nalazi se i u sustavima poput Shopwarea 6 i Contaa. PHP ranjivosti CVE-2026-109618 i CVE-2026-109619 prema PHP timu omogućuju izvršavanje zlonamjernog koda bez prijave. Je li aplikacija čisto programirana, pritom nije važno.
PHP tim rizik ocjenjuje najvišim kod mod_php-a, ali pogođeni su i PHP-FPM, php-cgi, FrankenPHP i LiteSpeed. Symfony projekti koji se putem Symfony Runtimea vode s FrankenPHP-om ili drugim trajno pokrenutim poslužiteljima nakon ažuriranja trebaju potpuno ponovno pokretanje ili novu sliku.
Symfony sigurnost: provjera verzije PHP-a i procesa
php bin/console about prikazuje verziju Symfonyja, okruženje, debug način i verziju PHP-a naredbenog retka. Web zahtjevi, međutim, idu preko PHP-FPM-a ili aplikacijskog poslužitelja, a to može biti druga verzija. Provjerite oba puta ili ih dajte potvrditi operateru.
Ispravljene upstream verzije su 8.5.12, 8.4.27, 8.3.36 i 8.2.35; backportovi distribucija često nose starije brojeve. Koje PHP verzije podržava Vaša verzija Symfonyja, provjerite prema sistemskim zahtjevima u dokumentaciji na symfony.com.
# Prikaz okruženja, debug načina i verzije PHP-a
php bin/console about
# Messenger workeri neka se završe nakon trenutne poruke
php bin/console messenger:stop-workers
# Poznate ranjivosti u ovisnostima
composer audit
Ako više instanci radi iza load balancera ili u kontejnerima, svaka pojedina mora biti zakrpana i ponovno pokrenuta. Zaboravljena instanca i dalje poslužuje dio zahtjeva sa starim PHP-om.
Messenger workeri, cron naredbe i drugi pozadinski procesi PHP učitavaju jednom pri pokretanju. Dok se ponovno ne pokrenu, rade sa starim PHP-om u memoriji. Upravitelj procesa mora ih nakon zaustavljanja ponovno podići.
Gdje su Symfony aplikacije ranjive
| Mjesto | Sadržaj | Točka provjere |
|---|---|---|
.env, .env.local, .env.local.php |
Varijable okruženja, često baza podataka i API ključevi | Nisu dostupne u webrootu, nakon sumnje obnoviti vrijednosti |
config/secrets/prod/ |
Šifrirani secrets | Privatni ključ za dešifriranje ne pripada u repozitorij |
public/ |
Korijen dokumenata s index.php |
Dodatne PHP datoteke |
var/cache/prod/ |
Generirani kontejner i predlošci kao PHP | Nakon sumnje izbrisati i ponovno generirati |
var/log/ |
Zapisnici | Osigurati |
config/packages/security.yaml |
Firewalli, uloge, pravila pristupa | Neočekivane izmjene |
Predmemorija je podcijenjeno skrovište. Symfony tamo generira PHP datoteke koje se učitavaju pri svakom zahtjevu. Izmjena tih datoteka u repozitoriju se ne primjećuje jer predmemorija nije pod verzioniranjem.
U produkciji moraju biti APP_ENV=prod i APP_DEBUG=0, a WebProfilerBundle ne smije biti aktivan. Javno dostupan profiler na /_profiler otkriva konfiguraciju i podatke o zahtjevima.
Admin područja, bundleovi i ovisnosti
Symfony projekti imaju, ovisno o izgradnji, vlastita admin područja, često s bundleovima poput EasyAdmina ili Sonate. U security.yaml provjerite koji putovi traže koje uloge, a u bazi podataka tko te uloge ima. Admin putovi koji se trebaju samo interno trebali bi na razini web-poslužitelja biti ograničeni na poznate mreže.
Bundleovi i Composer paketi strani su kôd s vlastitim ranjivostima. composer audit prikazuje poznate probleme; detaljnije na stranici Provjera Composer ovisnosti na ranjivosti. Zastarjeli paketi uz to su najčešći razlog zašto nadogradnja PHP-a u Symfony projektima traje dulje od planiranog.
Što Symfony ažuriranje postiže, a što ne
Ažuriranje Symfony komponenti zatvara pogreške u frameworku. Ne zakrpava PHP, ne pokreće ponovno workere, ne obnavlja iscurjele secrets i ne uklanja manipuliranu predmemoriju. Ima li naznaka napada, opisuje članak Jesam li već kompromitiran?. Budući da nema potvrđenih pokazatelja kompromitacije (Indicators of Compromise), najviše pomaže promatranje neuobičajenog ponašanja, primjerice neočekivanih procesa ili odlaznih veza.
Ako se projekt isporučuje kao kontejner, novi PHP pripada u bazu sliku. Ponovno izgradite sliku čak i ako se kôd nije promijenio te je postavite u svim okruženjima. Pogled u Dockerfile pokazuje koja se bazna slika koristi; fiksno postavljena stara oznaka inače sprječava da ponovna izgradnja uopće dobije zakrpani PHP. Pojedinosti su na stranici Zakrpavanje PHP-a u Docker kontejnerima.
Kako PHP SOS konkretno pomaže?
- Utvrđujemo koji PHP koriste web, CLI i workeri Vašeg Symfony projekta te pratimo uredno ponovno pokretanje.
- Osiguravamo logove od 20.10.2026. i uspoređujemo kôd na poslužitelju s Vašim repozitorijem.
- Provjeravamo datoteke okruženja, secrets, predmemoriju, postavke profilera i admin uloge.
- Za trajno promatranje procesa i veza nudimo sigurnosni monitoring.
Česta pitanja
Pogađa li PHP2Shell Symfony?
Sam Symfony nema novu ranjivost. PHP2Shell je u PHP-u, dakle u izvršnom okruženju svake Symfony aplikacije. Ranjivost se zatvara PHP ažuriranjem ili potvrđenim backportom i ponovnim pokretanjem svih PHP procesa.
Kako zaustaviti Messenger workere nakon PHP ažuriranja?
Naredbom php bin/console messenger:stop-workers pokrenutim se workerima nalaže da se završe nakon trenutne poruke. Upravitelj procesa poput Supervisora ili systemd-a zatim ih ponovno pokreće s novim PHP-om.
Zašto je Symfony profiler opasan u produkciji?
Profiler prikazuje zahtjeve, konfiguraciju i često varijable okruženja. Ako je aktivan na javnom poslužitelju, te informacije može dohvatiti svatko. Pripada samo u razvojno okruženje.
Što se događa s predmemorijom nakon napada?
Predmemorija pod var/cache sadrži generirani PHP kôd. Napadač tamo može odložiti kôd koji se izvršava pri svakom zahtjevu. Nakon sumnje predmemoriju treba izbrisati i ponovno generirati iz provjerenog izvornog kôda.