Röviden: A Symfony biztonsága a PHP2Shell után azt jelenti: javítani a PHP-t, újraindítani az összes folyamatot, a Messenger workereket is, majd ellenőrizni a secreteket, a gyorsítótárat és a profilert. A rés a PHP-ben van, nem a Symfonyban; egy Symfony-frissítés önmagában nem zárja le.
Miért érinti a PHP2Shell minden Symfony-projektet
A Symfony sok vállalati alkalmazás, API és portál alapja, és olyan rendszerekben is ott van, mint a Shopware 6 és a Contao. A CVE-2026-109618 és a CVE-2026-109619 PHP-rések a PHP-csapat szerint lehetővé teszik kártékony kód futtatását bejelentkezés nélkül. Az nem számít, hogy az alkalmazás tisztán van-e programozva.
A PHP-csapat a mod_php esetében értékeli a legmagasabbra a kockázatot, de érintett a PHP-FPM, a php-cgi, a FrankenPHP és a LiteSpeed is. A Symfony Runtime-on keresztül FrankenPHP-vel vagy más tartósan futó szerverekkel üzemeltetett Symfony-projektek a frissítés után teljes újraindítást vagy új image-et igényelnek.
Symfony biztonság: a PHP-verzió és a folyamatok ellenőrzése
A php bin/console about megmutatja a Symfony-verziót, a környezetet, a hibakeresési módot és a parancssor PHP-verzióját. A webes kérések azonban a PHP-FPM-en vagy egy alkalmazásszerveren futnak, és az más verzió lehet. Ellenőrizze mindkét utat, vagy erősíttesse meg az üzemeltetővel.
A javított upstream verziók: 8.5.12, 8.4.27, 8.3.36 és 8.2.35; a disztribúciók backportjai gyakran régebbi számot viselnek. Hogy a Symfony-verziója mely PHP-verziókat támogatja, azt a rendszerkövetelmények szerint a symfony.com dokumentációjában ellenőrizheti.
# A környezet, a hibakeresési mód és a PHP-verzió megjelenítése
php bin/console about
# A Messenger workerek leállíttatása az aktuális üzenet után
php bin/console messenger:stop-workers
# Ismert rések a függőségekben
composer audit
Ha több példány fut terheléselosztó mögött vagy konténerekben, mindegyiknek javítottnak és újraindítottnak kell lennie. Egy elfelejtett példány a kérések egy részét tovább régi PHP-val szolgálja ki.
A Messenger workerek, a cron-parancsok és más háttérfolyamatok a PHP-t egyszer, induláskor töltik be. Amíg újra nem indítják őket, a memóriában lévő régi PHP-val futnak. Egy folyamatkezelőnek kell őket a leállítás után újra felfuttatnia.
Hol támadhatók a Symfony-alkalmazások
| Hely | Tartalom | Ellenőrzési pont |
|---|---|---|
.env, .env.local, .env.local.php |
környezeti változók, gyakran adatbázis és API-kulcsok | a webroot-ból nem lehet lekérni, gyanú esetén az értékeket megújítani |
config/secrets/prod/ |
titkosított secretek | a privát visszafejtő kulcs nem tartozik a tárolóba |
public/ |
dokumentumgyökér az index.php-vel |
további PHP-fájlok |
var/cache/prod/ |
generált konténer és sablonok PHP-ként | gyanú esetén törölni és újragenerálni |
var/log/ |
naplók | mentse |
config/packages/security.yaml |
tűzfalak, szerepkörök, hozzáférési szabályok | váratlan változások |
A gyorsítótár alábecsült rejtekhely. A Symfony ott PHP-fájlokat állít elő, amelyek minden kérésnél betöltődnek. Az ezeken a fájlokon végzett módosítás a tárolóban nem tűnik fel, mert a gyorsítótár nincs verziókezelve.
Éles üzemben az APP_ENV=prod és az APP_DEBUG=0 érvényes, és a WebProfilerBundle ott nem lehet aktív. Egy nyilvánosan elérhető profiler a /_profiler alatt kiadja a konfigurációt és a kéréseket.
Admin területek, bundle-ök és függőségek
A Symfony-projekteknek felépítéstől függően saját admin területeik vannak, gyakran olyan bundle-ökkel, mint az EasyAdmin vagy a Sonata. A security.yaml fájlban ellenőrizze, mely útvonalak milyen szerepköröket kívánnak, az adatbázisban pedig azt, kiknek vannak ezek a szerepkörei. A csak belsőleg szükséges admin útvonalakat webszerver-szinten ismert hálózatokra kell korlátozni.
A bundle-ök és a Composer-csomagok idegen kód saját résekkel. A composer audit ismert problémákat mutat; részletesebben a Composer-függőségek ellenőrzése résekre oldalon. Az elavult csomagok ezenfelül a leggyakoribb okai annak, hogy egy PHP-frissítés a Symfony-projektekben a tervezettnél tovább tart.
Mit ér egy Symfony-frissítés, és mit nem
A Symfony-összetevők frissítése lezárja a keretrendszer hibáit. A PHP-t nem javítja, workereket nem indít újra, az elszivárgott secreteket nem újítja meg, és a manipulált gyorsítótárat nem távolítja el. Hogy vannak-e egy támadás jelei, azt a Feltörték már? írja le. Mivel nincsenek megerősített Indicators of Compromise, főleg a szokatlan viselkedés megfigyelése segít, például váratlan folyamatoké vagy kimenő kapcsolatoké.
Ha a projektet konténerként szállítják, az új PHP-nak az alap-image-be kell kerülnie. Építse újra az image-et akkor is, ha a kódon nem változott semmi, és helyezze ki az összes környezetben. A Dockerfile-ra pillantva látszik, melyik alap-image van használatban; egy rögzített régi címke egyébként megakadályozza, hogy az újraépítés egyáltalán megkapja a javított PHP-t. A részleteket a PHP javítása Docker-konténerekben oldalon találja.
Hogyan segít konkrétan a PHP SOS?
- Megállapítjuk, melyik PHP-t használja a Symfony-projektje webje, CLI-ja és workerei, és kísérjük a rendezett újraindítást.
- Mentjük a naplókat 2026. 10. 20-tól, és egyeztetjük a szerveren lévő kódot az Ön tárolójával.
- Ellenőrizzük a környezeti fájlokat, a secreteket, a gyorsítótárat, a profiler-beállításokat és az admin-szerepköröket.
- A folyamatok és kapcsolatok folyamatos megfigyeléséhez biztonsági monitoringot kínálunk.
Gyakori kérdések
Érinti a Symfonyt a PHP2Shell?
A Symfonynak nincs új rése. A PHP2Shell a PHP-ben van, vagyis minden Symfony-alkalmazás futtatókörnyezetében. A rést PHP-frissítés vagy megerősített backport, és az összes PHP-folyamat újraindítása zárja le.
Hogyan állítom le a Messenger workereket egy PHP-frissítés után?
A php bin/console messenger:stop-workers paranccsal utasíthatók a futó workerek, hogy az aktuális üzenet után álljanak le. Egy folyamatkezelő, például a Supervisor vagy a systemd, ezután az új PHP-val újraindítja őket.
Miért veszélyes a Symfony-profiler éles üzemben?
A profiler kéréseket, konfigurációt és gyakran környezeti változókat mutat. Ha egy nyilvános szerveren aktív, bárki lekérheti ezeket az információkat. Csak a fejlesztői környezetbe tartozik.
Mi történik a gyorsítótárral egy támadás után?
A var/cache alatti gyorsítótár generált PHP-kódot tartalmaz. Egy támadó ott helyezhet el kódot, amely minden kérésnél lefut. Gyanú esetén a gyorsítótárat törölni kell, és az ellenőrzött forráskódból újra előállítani.