# Symfony biztonság a PHP2Shell után: projektek és workerek védelme

> Symfony-projektek védelme a PHP2Shell után: PHP ellenőrzése (bin/console about), Messenger workerek újraindítása, secretek, gyorsítótár, profiler.

Forrás: https://phpsos.de/hu/plattformen/symfony/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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.

```bash
# 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.

> **Fontos:**
> É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](https://phpsos.de/hu/ratgeber/composer-abhaengigkeiten-pruefen/) 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?](https://phpsos.de/hu/php2shell/bin-ich-gehackt-anzeichen/) í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](https://phpsos.de/hu/php2shell/docker-container-patchen/) 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](https://phpsos.de/hu/leistungen/security-monitoring/) 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.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [Symfony](https://symfony.com/)
- [OWASP Cheat Sheets](https://cheatsheetseries.owasp.org/)
- [Támogatott PHP-verziók](https://www.php.net/supported-versions.php)