PHP2Shell: két kritikus PHP-sérülékenység, és hogyan csökkenthető a kockázat a frissítésig

Október 20-án kiszivárogtak a részletek. Október 21-én a PHP sürgősségi javítást adott ki. Mire a frissítés megjelent, már támadási kísérleteket is láttak. Ilyenkor nincs idő hosszan gondolkodni – de pánikolni sem érdemes.

2005 óta üzemeltetek IT-infrastruktúrát egészségügyi szolgáltatóknak Magyarországon, ahol a WAF mindig ott volt minden internet felé nyitott rendszer előtt. Az elmúlt két napban sokan kérdezték tőlem, mit jelent ez a hiba a gyakorlatban, és mit kell csinálni. Ezen az oldalon összefoglalom a tényeket és a teendőket. Hogy pontosan mit jelent ez egy WordPress-oldalnak, egy webshopnak vagy egy Kubernetesben futó API-nak, azt egy külön kockázati kézikönyvben írtam le.

Mi a két hiba – emberi nyelven

Mindkét hiba magában a PHP motorban van, nem egy bővítményben vagy keretrendszerben. Ezért mindegy, hogy WordPress, Laravel, Magento vagy saját fejlesztésű alkalmazás fut rajta, és az is mindegy, hogy Apache, Nginx vagy IIS áll előtte.

CVE-2026-109618 – amikor elfogy a memória

Ha a PHP egy kérés feldolgozása közben kifut a memóriából, félúton kilép, miközben a kérés adatai még csak félig vannak felépítve. A takarító kód ezután megbízik ezekben a félkész adatokban – és ebből kódfuttatás lesz. Speciálisan összeállított multipart kérésekkel kiváltható.

CVE-2026-109619 – a „beragadt” mutató

A PHP egy globális mutatót tart egy olyan memóriaterületre, amely egy adott kéréshez tartozik. Ha ez a mutató nem nullázódik, ugyanannak a workernek a következő kérése már felszabadított memóriát használ – ez is kódfuttatáshoz vezet. A hosszú életű workerek, például a PHP-FPM esetében ez különösen kedvező a támadónak.

Mely szerverkörnyezetek érintettek?

Egy gyakran elfelejtett eset: sok Windows/IIS szerver több oldalt is kiszolgál, és valamelyikhez telepítve van egy PHP FastCGI handler. Ilyenkor a szerver érintett akkor is, ha a te oldalad nem PHP-s. Mindig szerverszinten ellenőrizd, ne csak oldalszinten.

Mely verziók érintettek, és hol a javítás?

„Akkor miért nem frissítünk azonnal mindenhol?”

Ezt kérdezte tőlem az egyik kollégám, és jogos a kérdés. Frissíteni kell, ezen nincs vita. De éles környezetben – főleg egészségügyben, pénzügyben, vagy ahol egy szerveren tucatnyi alkalmazás fut – egy PHP-frissítés nem úgy megy, hogy kijön, és másnap fent van.

• Kompatibilitás és függőségek: a bővítmények, a keretrendszer és a saját kód is működjön az új patch-verzióval.
• Change management: jóváhagyás, karbantartási ablak, kommunikáció az érintettek felé.
• Visszaállási terv: ha valami mégsem működik, pontosan tudni kell, hogyan és mennyi idő alatt állunk vissza.
• Régi ágak: a PHP 8.1 vagy régebbi rendszereknél nincs egyszerű patch – ott verzióváltás kell, ami már projekt.

A frissítésig eltelt időben valaminek védenie kell a rendszert. Ezért van a WAF, a tűzfal és a szegmentálás. Ez nem kifogás a halogatásra, hanem a felelős üzemeltetés része.

Hogy egy szervezet mennyi ideig engedheti meg magának a kockázatot, és ki dönt a leállításról, azt nem a sérülékenység dönti el, hanem a BCDR. Erről, és arról, milyen három opciót adok ilyenkor, egy külön oldalon írtam.

Mitigáció lépésről lépésre

1. Leltár – hol fut PHP?

Minden szervert és konténert fel kell térképezni, ahol PHP fut: megosztott IIS-hosztok, régi „elfelejtett” rendszerek, tesztkörnyezetek, amelyek véletlenül kint vannak az interneten. Amiről nem tudsz, azt nem tudod frissíteni.

2. Frissítés és workerek újraindítása

PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 – tesztelve, majd minden worker újraindítása vagy a konténerek újratelepítése. A legkritikusabb rendszerekkel kezdve: ahol személyes adat, fizetés vagy egészségügyi adat van.

3. PHP-konfiguráció megerősítése

; Upload-progress funkció kikapcsolása (CVE-2026-109619 útvonal)
session.upload_progress.enabled = 0

; Alacsony POST-méret – az alkalmazás tényleges igényéhez igazítva
post_max_size = 10M

; Csak PHP 8.5 esetén
fatal_error_backtraces = 0

4. Ideiglenesen szigorú WAF-szabályok

Mivel memóriakezelési hibákról van szó, nincs egyetlen tiszta támadási minta, amit le lehetne tiltani. A WAF-szabályok a támadási útvonalakat szűkítik:

• multipart/form-data tiltása minden olyan végponton, amely nem fogad legitim fájlfeltöltést;
• a kérés törzsének, a POST-mezők és fájlok számának, valamint a paraméterek beágyazási mélységének korlátozása;
• a PHP session upload-progress mező tiltása – ez az egyik ismert támadási útvonal;
• a hibás formátumú multipart kérések elutasítása.

A konkrét ModSecurity- és IIS-szabályokat, a saját tudásbázisomból összeszedve, a WAF-ról szóló oldalon találod. Először detekciós módban teszteld őket.

5. Kompromittálódás jeleinek keresése

• új, ismeretlen admin-fiókok;
• ismeretlen PHP-fájlok (web shellek) a webkönyvtárban;
• módosított fizetési (checkout) szkriptek;
• szokatlan kimenő forgalom vagy nagy adatbázis-exportok.

Ha bármelyikre utaló jelet találsz: incidenskezelés, és ha személyes adat érintett, GDPR szerinti adatvédelmi incidenskezelés.

Mit tapasztaltam az elmúlt két napban?

Több helyen leteszteltük: ahol az általam üzemeltetett WAF a javasolt beállításokkal fut, ott a sérülékenység nem volt kihasználható. A szabályokat azóta is folyamatosan finomhangoljuk, mert minden alkalmazás másképp viselkedik.

Ez a hiba nem az első, és nem az utolsó. Ahogy az OpenSSL-nél, úgy a PHP-nál is rendszeresen jönnek majd hasonlók. A jól felépített környezet – tűzfal, WAF, szegmentálás, rendszeres penteszt – nem teszi feleslegessé a frissítést, de időt ad arra, hogy azt rendesen, tesztelve csináljuk meg.

Kapcsolódó oldalak

• Mi a WAF, és miért nem gondoltam, hogy 2026-ban erről kell írnom? – szabályokkal a saját tudásbázisomból
• PHP2Shell kockázati kézikönyv – mit jelent a sérülékenység weboldal-típusonként
• BCDR és IT-üzemeltetés – „Csaba, mit csináljunk?” „Mutasd a BCDR-t!”
• Autosecurit / Skyguard teljes leállás – BCDR, RTO és RPO a gyakorlatban
• Plan B – tartalékok és magas rendelkezésre állás otthoni környezetben

Az oldal a 2026. október 23-án nyilvánosan elérhető információkat tükrözi, és új részletek esetén frissítem.