PHP2Shell: kritikus PHP-sérülékenység - CVE-2026-109618 és CVE-2026-109619

A PHP biztonsági csapata október 20-án, kedd este előzetesen bejelentette, hogy másnap sürgős biztonsági kiadás érkezik két kritikus hibára. A hibák részletei még a hivatalos közzététel előtt kiszivárogtak, ezért a kiadást egy nappal előrehozták. Október 21-én 16:00-kor (magyar idő) a php.net csapata maga adta ki a javított verziókat.

A kiszivárgás miatt a támadók is gyorsan reagáltak: több biztonsági cég (köztük a watchTowr, a Hadrian és a Patchstack) aktív kihasználást észlelt, a Cloudflare pedig már a javítás előtt jelezte az első támadásokat. Az Amazon Threat Intelligence jelentése szerint az első kísérletek már október 17-én megkezdődtek.

Miért kritikus?

A két hiba a PHP memóriakezelésében van:

• CVE-2026-109618: ha egy kérés feldolgozása közben elfogy a memória, a PHP félig előkészített adatokkal futtat takarítást, ami memóriasérüléshez vezet.
• CVE-2026-109619: egy korábbi kérésből visszamaradt, már felszabadított memóriára mutató állapotot használhat fel egy későbbi kérés ugyanazon a PHP-folyamaton.

Mindkettő CVSS 9,2 pontos (kritikus). Egy speciálisan összeállított webes kéréssel a támadó kódot futtathat a kiszolgálón, a PHP-folyamat jogosultságaival. Kutatók azt is bemutatták, hogy a PHP-folyamat memóriájának tartalma kiszivároghat, ami jelszavakat, tokeneket vagy API-kulcsokat is tartalmazhat.

Mivel a PHP a kérést az alkalmazás kódja előtt dolgozza fel, a CMS bejelentkezési védelme sem véd. A legnagyobb kockázatot az Apache mod_php jelenti, de a PHP-FPM, a LiteSpeed és a FrankenPHP is érintett bizonyos beállításokkal.

Érintett verziók és javítások

A hibák a PHP 5.4-es és újabb verzióit érintik.

Fontos: az alábbi táblázat kizárólag azt mutatja, hogy a PHP.net csapata (a PHP projekt maga) mely ágakra adott ki hivatalos javítást. Ez nem jelenti azt, hogy a többi verzió ténylegesen védtelen marad: az operációs rendszerek és szoftvergyártók karbantartói (például a CloudLinux, a cPanel, a TuxCare, a Debian, az Ubuntu vagy az AlmaLinux) a javítást visszaportolhatják (backport) más, régebbi PHP-verziókra is, és a gyakorlatban sokszor vissza is portolják. Hogy egy adott szerveren mi a helyzet, azt az ott használt csomag állapota dönti el, nem a PHP-verziószám.

A táblázat tehát a PHP.net hivatalos támogatását mutatja, nem azt, hogy melyik verzió biztonságos egy adott szerveren. Nálunk például a CloudLinux és a cPanel (EasyApache) csomagjai a régebbi PHP-ágakra is tartalmazzák a javítást, így ezeken a szervereken a régebbi verziók is védettek.

Miért marad ugyanaz a verziószám?

Egyes gyártók (például a CloudLinux) a javítást visszaportolják (backport) a régebbi verziószámú csomagjaikba. Ilyenkor a PHP verziószáma nem változik (például marad 8.5.11), csak a csomag build-száma, viszont a build-szám nem látható a verzióban. A csomag changelogja igazolja, hogy a javítás benne van.

Emiatt az olyan ellenőrzők, amelyek csak a PHP verziószámát nézik, tévesen jelezhetnek. Ha egy WordPress-bővítmény (például a HelloPack) azt jelzi, hogy az oldal PHP 8.5.11-et használ és frissíteni kell, az nem jelenti automatikusan, hogy a javítás hiányzik. Ha ilyen riasztást lát, írjon nekünk, és megerősítjük az állapotot.

A phpinfo() kimenetében a Build Date is segít: ha a dátum 2026. október 21. utáni, a csomagot valószínűleg a javítás után fordították újra. A biztos ellenőrzés a csomag changelogja.

Mit tettünk mi?

• Már a javítás megjelenése előtt ModSecurity-szabályokat alkalmaztunk a szervereinken, hogy addig is némi védelmet biztosítsunk. Ez kiegészítő védelem, a PHP-frissítést nem helyettesíti.
• Szervereinken: A javítások megjelenésekor 5-15 percen belül telepítettük azokat. A különböző PHP verziókhoz folyamatosan jöttek ki a javítások, valamint a csomagtárolók leterheltsége folytán azok letöltése is a megszokottnál több időt vett igénybe.
• Újraindítás: a javítás csak az érintett szolgáltatások újraindítása után lép életbe, ezért több alkalommal újraindítottuk az Apache-ot és a PHP-t (a teljes szervert nem). Ez összesen csak néhány perc megszakítást okozott.
• Ha az Ön oldala Cloudflare mögött működik, a Cloudflare is bevezette a saját védelmi szabályait: ezek 2026. október 21-én 05:02-től (magyar idő) alapértelmezetten életbe léptek a WAF szabályokon keresztül. Ingyenes CloudFlare előfizetések esetén is.

Mit tehet Ön?

1. A PHP javításához nincs teendője. A javítást a szerver üzemeltetőjének, karbantartójának kell feltennie, nem javítható magából a webalkalmazásból.
2. Nézze át az oldalát. Gyanús jelek lehetnek az ismeretlen vagy nemrég módosított .php fájlok, az ismeretlen felhasználók vagy rendszergazdák a CMS-ben, az ismeretlen időzített feladatok (cron) a tárhelyfiókban, valamint a váratlan átirányítások, spam vagy idegen tartalom. Ha ilyet talál, jelezze nekünk, és ne töröljön semmit, mielőtt egyeztetünk.
3. Fontolja meg a jelszavak cseréjét. Gyanús jel nélkül ez nem kötelező, de elővigyázatosságból, különösen ha az oldal bejelentkezést vagy fizetést kezel, érdemes lecserélni a panel-, FTP-, adatbázis- és CMS-rendszergazdai jelszavakat. A hiba a PHP-folyamat memóriájának tartalmát is kiszivárogtathatja. A cPanel-jelszó cseréjét ebben a cikkben mutatjuk be.
4. Tartsa naprakészen a CMS-t és a bővítményeket. Ez nem helyettesíti a PHP-frissítést, de csökkenti a támadási felületet.
5. Legyen óvatos az adathalász levelekkel. A hír miatt megszaporodhatnak a „sürgős biztonsági frissítésre” hivatkozó hamis levelek. Mi sosem kérjük el a jelszavát e-mailben.

Aki saját oldalát ellenőrizné, használhatja például a Searchlight Cyber nyílt forráskódú php2shell-scanner eszközét vagy az Aikido ingyenes URL-ellenőrzőjét. Ezeket csak saját szerveren és saját oldal tesztelésére használja mindenki!

Idővonal

Az időpontok magyar idő szerint (CEST) értendők, ÉÉÉÉ-HH-NN ÓÓ:PP formátumban.

Gyakori kérdések

Érinti a WordPress-oldalamat vagy a webáruházamat? Igen, minden PHP-alapú oldalt érinthet, mert a hiba a PHP-ban van. A javítás a szerveren történik.

Elég a WordPress vagy a bővítmények frissítése? Nem. A hibát a PHP javítása szünteti meg, a CMS frissítése önmagában nem.

Kiesett az oldalam? Rövid ideig igen: az Apache és a PHP újraindításai összesen csak néhány perc megszakítást okoztak.

Használhatom tovább a PHP 8.1-et vagy régebbit? A PHP.net ezekre az ágakra nem adott ki hivatalos kiadást, de az operációs rendszerek és gyártók (például a CloudLinux, a cPanel és a TuxCare) visszaportolt javítást adhatnak ki hozzájuk, így az érintett szervereken a régebbi verziók is védettek lehetnek. Hosszú távon javasoljuk a támogatott verzióra (8.3 vagy 8.4) való áttérést, ha az oldala kompatibilis vele. A váltás előtt készítsen mentést, utána próbálja ki az oldalt. A PHP-verzió cPanelben történő átállítását ebben a cikkben mutatjuk be.