Na kratko: Varnost Symfony po PHP2Shell pomeni: popraviti PHP, znova zagnati vse procese, vključno z delavci Messenger, nato pa preveriti skrivnosti, predpomnilnik in Profiler. Ranljivost je v PHP, ne v Symfony; sama posodobitev Symfony je ne zapre.
Zakaj PHP2Shell zadeva vsak projekt Symfony
Symfony je osnova številnih poslovnih aplikacij, API-jev in portalov ter je poleg tega vgrajen v sisteme, kot sta Shopware 6 in Contao. Ranljivosti PHP CVE-2026-109618 in CVE-2026-109619 po navedbah ekipe PHP omogočata izvajanje škodljive kode brez prijave. Ali je aplikacija čisto programirana, pri tem ni pomembno.
Ekipa PHP tveganje pri mod_php ocenjuje kot najvišje, prizadeti pa so tudi PHP-FPM, php-cgi, FrankenPHP in LiteSpeed. Projekti Symfony, ki prek Symfony Runtime tečejo s FrankenPHP ali drugimi trajno delujočimi strežniki, po posodobitvi potrebujejo popoln ponovni zagon ali novo sliko.
Varnost Symfony: preverite različico PHP in procese
php bin/console about prikaže različico Symfony, okolje, način odpravljanja napak in različico PHP v ukazni vrstici. Spletne zahteve pa tečejo prek PHP-FPM ali aplikacijskega strežnika, in to je lahko druga različica. Preverite obe poti ali ju dajte potrditi upravljavcu.
Odpravljene različice izvorne kode so 8.5.12, 8.4.27, 8.3.36 in 8.2.35; backporti distribucij pogosto nosijo starejše številke. Katere različice PHP podpira vaša različica Symfony, preverite v sistemskih zahtevah v dokumentaciji na symfony.com.
# Prikaži okolje, način odpravljanja napak in različico PHP
php bin/console about
# Delavce Messenger pusti končati po trenutnem sporočilu
php bin/console messenger:stop-workers
# Znane ranljivosti v odvisnostih
composer audit
Če več primerkov teče za uravnoteževalnikom obremenitve ali v containerjih, mora biti vsak posamezen popravljen in znova zagnan. Pozabljen primerek še naprej streže del zahtev s starim PHP.
Delavci Messenger, ukazi cron in drugi procesi v ozadju naložijo PHP enkrat ob zagonu. Dokler se ne zaženejo znova, tečejo s starim PHP v pomnilniku. Upravitelj procesov jih mora po ustavitvi spet zagnati.
Kje so aplikacije Symfony ranljive
| Mesto | Vsebina | Točka preverjanja |
|---|---|---|
.env, .env.local, .env.local.php |
Spremenljivke okolja, pogosto podatkovna zbirka in ključi API | Ne sme biti dosegljivo v korenu spleta, ob sumu obnoviti vrednosti |
config/secrets/prod/ |
Šifrirane skrivnosti | Zasebni ključ za dešifriranje ne sodi v repozitorij |
public/ |
Korenska mapa dokumentov z index.php |
Dodatne datoteke PHP |
var/cache/prod/ |
Ustvarjen container in predloge kot PHP | Ob sumu izbrisati in ustvariti znova |
var/log/ |
Dnevniki | Zavarovati |
config/packages/security.yaml |
Požarni zidovi, vloge, pravila dostopa | Nepričakovane spremembe |
Predpomnilnik je podcenjeno skrivališče. Symfony tam ustvari datoteke PHP, ki se naložijo ob vsaki zahtevi. Sprememba teh datotek v repozitoriju ne pade v oči, ker predpomnilnik ni pod nadzorom različic.
V produkciji morata biti APP_ENV=prod in APP_DEBUG=0, WebProfilerBundle pa tam ne sme biti aktiven. Javno dosegljiv Profiler pod /_profiler izda konfiguracijo in podatke zahtev.
Skrbniška območja, bundle in odvisnosti
Projekti Symfony imajo glede na zgradbo lastna skrbniška območja, pogosto z bundli, kot sta EasyAdmin ali Sonata. V security.yaml preverite, katere poti zahtevajo katere vloge, in v podatkovni zbirki, kdo ima te vloge. Skrbniške poti, ki so potrebne samo interno, naj bodo na ravni spletnega strežnika omejene na znana omrežja.
Bundli in paketi Composer so tuja koda z lastnimi ranljivostmi. composer audit prikaže znane težave; podrobneje v prispevku Preverjanje odvisnosti Composerja glede ranljivosti. Zastareli paketi so poleg tega najpogostejši razlog, da nadgradnja PHP v projektih Symfony traja dlje od načrtovanega.
Kaj posodobitev Symfony zmore in česa ne
Posodobitev komponent Symfony zapre napake v ogrodju. PHP ne popravi, ne zažene znova delavcev, ne obnovi iztekle skrivnosti in ne odstrani manipuliranega predpomnilnika. Ali obstajajo znaki napada, opisuje prispevek Ali smo že ogroženi?. Ker potrjenih indikatorjev ogroženosti (IOC) ni, pomaga predvsem opazovanje nenavadnega vedenja, na primer nepričakovanih procesov ali odhodnih povezav.
Če se projekt dostavlja kot container, sodi novi PHP v osnovno sliko. Sliko zgradite znova, tudi če se koda ni spremenila, in jo uvedite v vseh okoljih. Pogled v Dockerfile pokaže, katera osnovna slika se uporablja; trdno nastavljena stara oznaka (tag) sicer prepreči, da bi nova gradnja sploh prejela popravljeni PHP. Podrobnosti so v prispevku Popravljanje PHP v containerjih Docker.
Kako PHP SOS pomaga konkretno?
- Ugotovimo, kateri PHP uporabljajo splet, CLI in delavci vašega projekta Symfony, ter spremljamo urejen ponovni zagon.
- Dnevnike od 20. 10. 2026 zavarujemo in kodo na strežniku uskladimo z vašim repozitorijem.
- Preverimo datoteke okolja, skrivnosti, predpomnilnik, nastavitve Profilerja in skrbniške vloge.
- Za tekoče opazovanje procesov in povezav nudimo varnostni nadzor (monitoring).
Pogosta vprašanja
Ali je Symfony prizadet zaradi PHP2Shell?
Symfony sam nima nove ranljivosti. PHP2Shell je v PHP, torej v izvajalnem okolju vsake aplikacije Symfony. Ranljivost se zapre s posodobitvijo PHP ali potrjenim backportom in ponovnim zagonom vseh procesov PHP.
Kako po posodobitvi PHP ustavim delavce Messenger?
Z php bin/console messenger:stop-workers se tekočim delavcem naroči, naj se končajo po trenutnem sporočilu. Upravitelj procesov, kot sta Supervisor ali systemd, jih nato znova zažene z novim PHP.
Zakaj je Profiler Symfony v produkciji nevaren?
Profiler prikazuje zahteve, konfiguracijo in pogosto spremenljivke okolja. Če je aktiven na javnem strežniku, lahko te informacije pridobi vsakdo. Sodi samo v razvojno okolje.
Kaj se po napadu zgodi s predpomnilnikom?
Predpomnilnik pod var/cache vsebuje ustvarjeno kodo PHP. Napadalec tam lahko odloži kodo, ki teče ob vsaki zahtevi. Ob sumu je treba predpomnilnik izbrisati in ga znova ustvariti iz preverjene izvorne kode.