Az új Heartbleed: PHP2Shell

A PHP két kritikus sérülékenysége kellemetlen döntés elé állította a webes szolgáltatásokat üzemeltető szervezeteket: azonnal telepítik a javítást, vagy megfontolják az érintett, internet felől elérhető rendszerek ideiglenes leválasztását. A technikai problémák mélyen a PHP futtatókörnyezetében találhatók, az eset azonban a koordinált sérülékenység-közzétételről, a javítások terjesztéséről és arról is tanulságokkal szolgál, hogy egy infrastrukturális sérülékenység milyen gyorsan válhat üzletmenet-folytonossági problémává.

A CVE-2026-109618 és a CVE-2026-109619 sérülékenység egyaránt 9,2-es besorolást kapott a CVSS v4.0 szerint. A PHP projekt 2026. október 21-én adta ki a javításokat. A lényegi kérdés nem egyszerűen az, hogy a weboldal használ-e PHP-t, hanem az, hogy pontosan melyik PHP-futtatókörnyezet szolgálja ki a kéréseket, hogyan dolgozza fel azokat, és milyen gyorsan cserélhető le.

Miről olvashat ebben a cikkben?

• Miben különbözik a két sérülékenység a memóriakezelés szintjén?
• Miért nem feltétlenül védik meg az alkalmazásszintű biztonsági kontrollok a PHP-értelmezőt?
• Mi siklott félre a koordinált közzététel során?
• Hogyan különböztethetők meg a kihasználási kísérletek az igazolt kompromittálódásoktól?
• Mit tegyenek most az infrastruktúráért felelős szervezetek, és min javítsanak a következő vészhelyzet előtt?

Két hiba a futtatókörnyezetben, nem az alkalmazásban

CVE-2026-109618: memóriakimerüléshez kapcsolódó memóriakorrupció. A PHP megszakíthat egy kérést, ha az eléri a beállított memóriakorlátot. Ennek normális esetben kontrollált, végzetes hibát kellene eredményeznie. Ebben az esetben azonban egy rossz pillanatban bekövetkező memóriafoglalási hiba miatt egyes belső struktúrák csak részlegesen inicializálva maradhattak. A későbbi felszabadítási műveletek ezt az érvénytelen állapotot helyes adatként kezelhették, ami memóriakorrupcióhoz vezethetett. A PHP Foundation beszámolója szerint Apache és mod_php használatával hitelesítés nélküli távoli kódfuttatást is demonstráltak, olyan támadási útvonallal is, amely már az alkalmazáskód végrehajtása előtt kiváltható. PHP-FPM esetén is igazolták a kihasználhatóságot, az alkalmazás kódján keresztül elérhető útvonalakon.

CVE-2026-109619: kérések között fennmaradó, elavult állapot. Egy végzetes hiba olyan belső állapotot hagyhatott maga után, amely egy korábbi kéréshez tartozó memóriára hivatkozott. A kérés befejezése után a memória felszabadult, de az ugyanazon kiszolgálófolyamat által feldolgozott későbbi kérés még hozzáférhetett az érvénytelenné vált hivatkozáshoz. Ez egy use-after-free hiba: a kód olyan memóriaterületen végez műveletet, amelynek eredeti objektuma már nem létezik. A PHP Foundation beszámolója igazolt use-after-free hibáról és a kiszolgálófolyamat összeomlásáról, valamint egy valós alkalmazáson demonstrált távoli kódfuttatásról szól mod_php használata mellett.

Ezek rokon meghibásodási módok, de nem azonosak. Az első egy inicializálási invariánst sért meg: a futtatókörnyezet késznek tekint egy struktúrát, amely valójában még nincs megfelelően előkészítve. A második egy élettartam-invariánst sért meg: egy hivatkozás tovább él, mint az a memória, amelyre mutat. Mindkettő végzetes hibák kezeléséhez kapcsolódó kódútvonalakat érint, amelyek helyes működését különösen nehéz átlátni egy hosszú múltra visszatekintő, C nyelven írt futtatókörnyezetben.

A különbség üzemeltetési szempontból is fontos. A WordPress, a Drupal vagy egy alkalmazásfüggőség frissítése nem javítja ki a PHP motorjának sérülékeny kódját. Ha pedig az érintett kódútvonal már az alkalmazás indulása előtt lefut, a hitelesítésre vagy az alkalmazásszintű bemenetellenőrzésre nem lehet védelemként támaszkodni.

Mit változtat a mesterséges intelligenciával támogatott kutatás?

Egy feltételezett memóriabiztonsági gyengeségtől a bizonyítottan működő távoli kihasználásig vezető út többhetes forráskód-elemzést, hipotézisvizsgálatot és környezetfüggő hibakeresést is igényelhet. A mesterséges intelligenciával (MI) támogatott biztonsági kutatás lerövidítheti ezt a folyamatot: segíthet összekapcsolni a nehezen észrevehető hibakezelési útvonalakat, elemezni az objektumok élettartamát és gyorsabban tesztelni a kihasználhatóságot. A Wiz Research kifejezetten arról számolt be, hogy MI-alapú kutatási módszereket használt a PHP2Shell feltárásához. Lásd a Wiz Research technikai elemzését és a kutatási tájékoztatóját.

Üzemeltetési szempontból ebből az következik, hogy a védekezőknek nem szabad hosszú időablakkal számolniuk egy elméleti hiba, egy működő proof of concept és a rosszindulatú tevékenység megjelenése között. Az Amazon fenyegetettségi jelentése szerint a cég csapdarendszerei már október 17-én, a nyilvános közzététel előtt rögzítettek PHP2Shell-kihasználási kísérletet. Az Amazon ugyanakkor hangsúlyozza, hogy nem tudta megállapítani, ezek a kísérletek valós rendszerek ellen sikerrel jártak volna-e.

Miért vált a közzététel maga is az incidens részévé?

A PHP Foundation szerint a memóriakimerüléses sérülékenység mögött álló problémára már 2024-ben gyanakodtak, a gyakorlati hatása azonban 2026-ban vált világosabbá. Több kutatócsoport is hozzájárult az eredményekhez, köztük MI-támogatott eszközöket használó csapatok. Ez nem bizonyítja, hogy a sérülékenységeket önmagában az MI fedezte fel vagy használta ki, azt viszont jól mutatja, hogy a karbantartóknak egyre több, magas technikai színvonalú biztonsági bejelentést kell kezelniük.

A koordinált kiadást eredetileg október 22-re tervezték. Október 20-án a CVE-azonosítók a tervezettnél korábban megjelentek az interneten, kezdetben technikai részletek nélkül. A projekt ezért október 21-én 14:00 UTC-re hozta előre a kiadást. Ezután egy biztonsági cég tévedésből közzétett egy proof-of-concept videót, amely terjedni kezdett, és korlátozott mennyiségű további információt árult el. Október 21-én 07:41 UTC-kor a Chainguard a koordinált kiadás előtt közzétette a javítást tartalmazó konténerképeket.

Miért számít, ha valaki túl korán publikál egy javítást? Mert a javítás maga is információ. A javított és a sérülékeny forráskód vagy bináris állomány összehasonlításával azonosíthatóvá válhat a hibás működés. Ha csak egy beszállító adta ki a frissítést, a támadók már tanulmányozhatják azt, miközben más felhasználók még nem tudnak támogatott javítást telepíteni. Másfelől a downstream csomagok elkészülte előtti kiadás gyakorlati frissítési lehetőség nélkül hagyhatja a szervezeteket. A koordinált közzététel ezt az eltérést próbálja csökkenteni, nem pusztán a titoktartást szolgálja.

Valóban sikeresek a támadások?

A vizsgálódó forgalomról, rosszindulatú kérésekről, csapdarendszereket érő találatokról és működő laboratóriumi demonstrációkról szóló jelentések fontosak. Ezek azonban nem azonosak azzal a bizonyítékkal, hogy egy azonosítható szervezet éles rendszerét valóban kompromittálták. Egy proof of concept a technikai kihasználhatóságot igazolja, egy támadási kísérlet a rosszindulatú tevékenységet, egy igazolt betöréshez további bizonyítékok szükségesek.

A cikk írásakor az itt áttekintett források sikeres kutatói demonstrációkat és valós támadói tevékenység során megfigyelt kihasználási kísérleteket támasztanak alá, de nem neveznek meg olyan konkrét, függetlenül igazolt áldozatot, amelynek éles rendszerét a két CVE valamelyikével kompromittálták volna. A szervezeteknek nem szabad egy nyilvánosságra kerülő áldozati beszámolóra várniuk a javítás telepítésével.

Nyilvános exploitkód

A PHP2Shell egyik nyilvánosan elérhető, GitHubon közzétett proof-of-concept tárolója itt található.

Miért kapcsolhatnak le egy weboldalt?

Ha egy internet felől elérhető szolgáltatás érintett, és a javítás nem telepíthető biztonságosan, a szolgáltatás ideiglenes letiltása csökkentheti az azonnali támadási felületet. Ez költséges döntés: a rendelkezésre állás maga is biztonsági és üzleti követelmény. A közszolgáltatások üzemeltetőinek mérlegelniük kellhet a szolgáltatáskiesést a kompromittálódás, az adatlopás vagy a támadó tartós hozzáférésének kockázatával szemben.

Egy elővigyázatossági leállítás nem bizonyítja, hogy sikeres behatolás történt. Tudatos kockázatkorlátozó lépés is lehet, amíg a csapatok felmérik az üzemelő környezeteket, frissítik a rendszereket, újraindítják a kiszolgálófolyamatokat és kivizsgálják a gyanús tevékenységet.

Mit tegyenek most a szervezetek?

A futtatókörnyezetet azonosítsák, ne csak az alkalmazást. Vegyék leltárba a PHP-verziókat a kiszolgálókon, konténerekben, felügyelt platformokon, ütemezett feladatokban és webszerver-integrációkban. Ne kizárólag a csomagleíró állományokra támaszkodjanak: ellenőrizzék, mi fut ténylegesen az éles környezetben.

Frissítsenek javított kiadásra. A PHP projekt a 8.2.35, 8.3.36, 8.4.27 és 8.5.12 verziókat jelöli meg javított kiadásként. A PHP 8.1 és a korábbi ágak már elérték támogatásuk végét, ezért támogatott ágra vagy megfelelő gyártói támogatással rendelkező megoldásra kell átállni. A projekt szerint nincs olyan, kizárólag konfigurációmódosításon alapuló intézkedés, amely teljes védelmet nyújtana.

Ellenőrizzék a telepítést. Szükség esetén építsék újra és telepítsék a konténerképeket, indítsák újra a tartósan futó PHP-kiszolgálófolyamatokat, ellenőrizzék, hogy a ténylegesen használt futtatókörnyezet verziója megváltozott-e, majd teszteljék újra a fontos alkalmazásfunkciókat. Egy csomag letöltése még nem jelenti azt, hogy a szolgáltatás sérülékenységét megszüntették.

Vizsgálják meg a kitettséget. Őrizzék meg a releváns webszerver-, WAF-, alkalmazás- és rendszerszintű telemetriai adatokat. Elemezzék a gyanús kéréseket, a kiszolgálófolyamatok váratlan összeomlását és a sikeres kihasználást követő tevékenységre utaló jeleket. Ne tekintsenek minden automatizált vizsgálati találatot betörésnek, de azt se feltételezzék, hogy a riasztások hiánya bizonyítja a biztonságot.

Készítsenek elő egy tartalék döntési tervet. Határozzák meg előre, ki engedélyezheti egy szolgáltatás ideiglenes leválasztását, hogyan történik majd az ügyfelek tájékoztatása, és milyen bizonyítékok szükségesek az újbóli elérhetővé tételéhez.

A tágabb tanulság: a koordinált közzétételhez koordinált telepítés is kell

Az eset három, eltérő sebességgel járó órát mutat meg: a kutatók feltárják a technikai részleteket, a karbantartók és a terjesztők előkészítik a javításokat, az üzemeltetők pedig telepítik azokat. Az embargó segíthet összehangolni az első kettőt, de keveset ér, ha a harmadik napokig tart. Ugyanígy a bináris javítás túl korai kiadása lehetőséget teremthet a javítás összehasonlító elemzésére, miközben más felhasználók még várakoznak.

Az érett reagálási képességhez ezért nem elég egy sérülékenység-bejelentő postafiók. Megbízható együttműködés kell az érintett downstream szereplőkkel, egyértelmű feltételek a rendkívüli kiadáshoz, pontos eszközfelelősségi rend, begyakorolt javítástelepítés és annak felmérési képessége, hogy egy kitettség alatt álló szolgáltatás elérhető maradhat-e.

A Naunetnél ezt legalább annyira architekturális és ellenálló képességi kérdésnek tekintjük, mint sérülékenységkezelési feladatnak. Egy célzott felmérés segíthet azonosítani, mely nyilvánosan elérhető rendszerek függenek sérülékeny futtatókörnyezettől, hol alkalmazhatók és hol nem alkalmazhatók kompenzáló kontrollok, illetve milyen gyorsan tudja egy szervezet igazolni a javítás eredményességét. A cél nem egyszerűen egy CVE-hibajegy lezárása, hanem annak az időszaknak a csökkentése, amely alatt a támadó a futtatókörnyezet hibáját üzleti kárrá tudja alakítani.

Források

• PHP Foundation, A PHP mai biztonsági kiadása és a PHP biztonságának megerősítése (2026. október 21., angol nyelvű)
• A PHP 8.5.12 kiadásának bejelentése (angol nyelvű)
• Google Cloud, Reagálás a PHP magját érintő sérülékenységekre (2026. október 21., angol nyelvű)
• NHS England Digital, Kritikus PHP-sérülékenységek (2026. október 21., angol nyelvű)
• Wiz Research, PHP2Shell: az MI kritikus RCE-sérülékenységeket tár fel (2026. október 21., angol nyelvű)
• Wiz, PHP2Shell technikai fenyegetettségi tájékoztató (2026. október 21., angol nyelvű)
• Amazon Threat Intelligence, PHP2Shell-kihasználási kísérletek a közzététel előtt (2026. október 21., angol nyelvű)
• GitHub, eness PHP2Shell proof of concept (harmadik féltől származó, angol nyelvű)
• GitHub, wakemeiflose PHP2Shell labor és proof of concept (harmadik féltől származó, angol nyelvű)