Két nappal a kritikus PHP2Shell-hibák javítása után újabb távoli kódfuttatási lehetőséget jelentett be a PHP projekt. A CVE-2026-115560 olyan alkalmazásokat érinthet, amelyek a feltöltések előrehaladását PHP-munkamenetben követik, és futás közben egy meghatározott ponton megváltoztatják a munkamenetadatok tárolási formátumát.
A PHP fejlesztői október 23-i tájékoztatójukban ritkának nevezték ezt a beállításkombinációt. Ezért a javítást a szokásos kiadási ciklusra ütemezték. Addig az érintett alkalmazásoknál a munkamenet-alapú feltöltéskövetés kikapcsolását javasolják. A november 2-ig ellenőrzött projektközleményekben nem szerepelt olyan hivatalos PHP-kiadás, amely az új hibát javítaná. A PHP projekt október 23-i tájékoztatója
Az üzemeltetőknek így két külön feladatuk van: telepíteniük kell az október 21-i javításokat a két korábbi hibára, és ellenőrizniük kell az új hiba feltételeit. Az új közlemény megjelenésekor nem számoltak be a CVE-2026-115560 igazolt kihasználásáról. A korábbi PHP2Shell-hibákhoz köthető támadási kísérletek nem bizonyítják az új sérülékenység kihasználását. A CERT-EU frissített biztonsági közleménye
Három feltételnek egyszerre kell teljesülnie
A PHP előzetes közleménye pontosan leírja, melyik beállításváltás számít. A közzétett támadási útvonalhoz a következő három feltétel együttes fennállása szükséges:
- A
session.serialize_handlerkezdeti értékephp_binaryvagyphp_serialize. - Az alkalmazás futás közben, az
ini_set()függvénnyelphpértékre vált, még asession_start()meghívása előtt. - A
session.upload_progress.enabledbeállítás aktív, vagyis a PHP munkamenetben követi a feltöltés előrehaladását.
Ha az alkalmazás nem módosítja futás közben a munkamenetadatok formátumát, a PHP szerint a feltöltéskövetés bekapcsolva maradhat anélkül, hogy ez a konkrét támadási útvonal megnyílna. Ha pedig az üzemeltető a korábbi ajánlás alapján már letiltotta a funkciót, és a tiltás minden érintett folyamatban érvényes, az új hiba miatt nincs szükség további konfigurációs változtatásra. A PHP közleménye az érintettség feltételeiről
A session.serialize_handler szabja meg, hogyan kódolja a PHP a tárolandó munkamenetadatokat, és hogyan olvassa vissza őket. A támogatott formátumok viselkedése és korlátai eltérnek; a dokumentált alapértelmezés a php. Önmagában tehát sem egy php_serialize bejegyzés a konfigurációban, sem a php érték látványa egy futó alkalmazásban nem dönti el az érintettséget. Az ellenőrzéskor a kezdeti konfiguráció mellett az alkalmazás és a keretrendszer indítókódját, valamint az egyedi munkamenet-kezelést is át kell nézni: mi volt a kezdőérték, megváltozott-e, és a váltás megelőzte-e a munkamenet megnyitását? A PHP kézikönyve a munkamenetek beállításairól
Mi köze a fájlfeltöltésnek a munkamenethez?
A PHP feltöltéskövető funkciója lehetővé teszi, hogy egy webalkalmazás még a fájl átvitele közben megjelenítse, hol tart a feltöltés. Miközben az egyik kérésben érkezik a fájl, a böngésző egy másik kérésben lekérdezheti a munkamenetbe írt állapotadatokat.
Az időzítés a lényeg: a PHP már az alkalmazás szkriptjeinek végrehajtása előtt adatokat írhat a feltöltésről a munkamenetbe. A kérés feldolgozása tehát megkezdődik, mielőtt az alkalmazás a saját indítókódjában megváltoztatná a munkamenet beállításait. Ezért az érintettséget nem lehet pusztán a session_start() hívás környezetéből megítélni. A PHP feltöltéskövetési dokumentációja
A feltöltéskövetés kikapcsolása nem tiltja le magát a fájlfeltöltést. Azok a funkciók viszont megváltozhatnak, amelyek a PHP által rögzített állapotadatokra épülnek. A beállítás módosítása után ezért a tényleges feltöltés mellett a folyamatjelzőt és – ahol van ilyen lehetőség – a feltöltés megszakítását is érdemes kipróbálni.
Mit lehet tenni a javítás megjelenéséig?
Az érintett alkalmazásokhoz javasolt beállítás:
session.upload_progress.enabled = 0A módosítást olyan PHP- vagy kiszolgálókonfigurációban kell alkalmazni, amely már a kérés feldolgozásának kezdetén érvényes. A szkriptben utólag végrehajtott ini_set() hívás a feltöltéskövetés letiltásához már elkéshet. A CERT-EU azt javasolja, hogy a beállítás átírása után indítsák újra az összes PHP-kiszolgálófolyamatot. Több példányon futó szolgáltatásnál minden olyan szerveren és konténerben ellenőrizni kell a változást, amely feltöltési kérést fogadhat. A CERT-EU intézkedési javaslatai · A PHP műszaki útmutatója a beállítás alkalmazásához
A korábbi PHP2Shell-hibákra továbbra is a javított futtatókörnyezet telepítése szükséges. A feltöltéskövetés letiltása az újonnan ismertetett útvonalat lezárja, de a korábbi CVE-2026-109619 többféleképpen kiváltható, és ezek közül csak az egyik kapcsolódik ehhez a funkcióhoz. Ha a régebbi hibák javítása nem végezhető el időben, a CERT-EU az internet felől elérhető alkalmazások elkülönítésének mérlegelését javasolja a frissítés telepítéséig és ellenőrzéséig. Ahol pedig az alkalmazás egyáltalán nem használja a PHP feltöltéskövetését, ott a javítás után is érdemes kikapcsolva hagyni. A CVE-2026-109619 hivatalos közleménye
Miben különbözik az új hiba a két eredeti PHP2Shell-sérülékenységtől?
A CVE-2026-109618 a memória elfogyásának kezelését érinti. Ha egy memóriafoglalás meghiúsul, a PHP félbehagyhat egy műveletet, miközben a kéréshez tartozó belső adatszerkezetek még csak részben épültek fel. A kérés lezárásakor a futtatókörnyezet mégis érvényesnek tekintheti ezeket az adatokat. Apache mod_php alatt a kutatók igazolták, hogy ez hitelesítés nélkül kódfuttatáshoz vezethet, a webes kérést kezelő folyamat jogosultságaival. A kihasználás megbízhatóságát a konkrét PHP-kiadás, a betöltött bővítmények, a memória elrendezése és a kérést továbbító kiszolgáló működése is befolyásolja. A javítás megakadályozza, hogy a lezárás során a PHP ilyen érvénytelen állapotot dolgozzon fel. A CVE-2026-109618 műszaki leírása
A CVE-2026-109619 esetében egy kiszolgálófolyamatban olyan belső hivatkozás maradhat fenn, amely egy már befejezett kérés felszabadított memóriájára mutat. Ha ugyanez a folyamat kapja a következő kérést, annak feldolgozása közben még azelőtt használhatja az elavult hivatkozást, hogy az inicializálás törölné. Ez felszabadítás utáni memóriahasználatot (use-after-free) eredményez. Az egyik igazolt útvonal a munkamenet-alapú feltöltéskövetést használja, de más útvonalak a hibakezeléshez és a futtatókörnyezet egyéb műveleteihez kapcsolódnak. A CVE-2026-109619 műszaki leírása
Az alábbiak az október 21-i első hivatalos kiadások, amelyek mindkét eredeti PHP2Shell-hibát javították. A CVE-2026-115560 javítását egyik sem tartalmazza.
| PHP-ág | A CVE-2026-109618 és a CVE-2026-109619 első javított kiadása |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
Régebbi PHP-ág használatakor a disztribúció vagy a hosszú távú támogatást nyújtó szállító közleményéből kell ellenőrizni, hogy az adott csomag megkapta-e a két korábbi javítást. Ha nincs megfelelően karbantartott csomag, támogatott kiadásra kell áttérni. A PHP október 21-i biztonsági közleménye · A CERT-EU útmutatója régebbi telepítésekhez
A korábbi hibák vizsgálatát érdemes október 17-ig visszavezetni
Az Amazon fenyegetéselemző csapata a MadPot nevű, támadások megfigyelésére használt csapdarendszerben október 17-én PHP2Shell-kihasználási kísérletet rögzített. Ez négy nappal megelőzte az október 21-i biztonsági kiadást. A forgalom egy kereskedelmi anonimizáló hálózathoz kapcsolt IP-címről érkezett. A megfigyelés a korábbi PHP2Shell-hibákra vonatkozott, nem a két nappal később bejelentett CVE-2026-115560-ra. Az Amazon MadPot-vizsgálata
Az Amazon ezért azt javasolja, hogy a korábbi PHP2Shell-kitettséget vizsgáló szervezetek legalább október 17-ig tekintsenek vissza. A webszerverek naplóiban látott gyanús kéréseket érdemes összevetni azzal, hogy a webszolgáltatás indított-e váratlan folyamatot, vagy történt-e megmagyarázhatatlan fájlmódosítás az alkalmazáskiszolgálón.
A csapdarendszerben rögzített próbálkozás nem bizonyítja, hogy egy éles rendszert sikerült feltörni. A dátum azért fontos, mert ha a naplóvizsgálat a javítás megjelenésének napján kezdődik, korábbi kísérletek maradhatnak ki belőle. A frissítés a szoftverhibát zárja le; a korábbi jogosulatlan hozzáférés kérdését a megőrzött bizonyítékok alapján lehet tisztázni.
Mi nem derült még ki az új sérülékenységről?
A PHP október 23-i előzetes közleménye megnevezte a szükséges beállításokat és a védekezési lehetőséget, de nem közölt hivatalos CVSS-pontszámot, teljes érintettverzió-listát vagy konkrét javított kiadási számot. A projekt a részletes műszaki tájékoztatót a soron következő rendes hibajavító kiadással együtt ígérte. Az sem derül ki a közleményből, hogy az új sérülékenység ugyanarra a programhibára vezethető-e vissza, mint a CVE-2026-109619. A feltöltéskövetés közös érintettsége önmagában ezt nem bizonyítja. A PHP előzetes tájékoztatója
Az új hibát ezért érdemes önálló tételként követni: dokumentálni, hogy az alkalmazás vált-e munkamenet-formátumot, szükség esetén letiltani a feltöltéskövetést, ellenőrizni a futó folyamatok beállítását, majd nyomon követni a végleges javítást. Ettől külön feladat az október 21-i két javítás telepítésének igazolása és a korábbi támadási kísérletek vizsgálata. A leltárba a külső szállítók termékeibe csomagolt PHP-példányokat is be kell vonni; az ilyen függőségek azonosításához a CERT-EU a holland NCSC nyilvános nyilvántartását ajánlja kiindulópontként.
Eredeti cím: PHP Discloses Another Unpatched RCE Flaw Days After Emergency PHP2Shell Updates
