Két kritikus PHP-hiba: megjelentek a biztonsági javítások
# Két kritikus PHP-hiba: megjelentek a biztonsági javítások
Szerző: Egri Zoltán | 2026. október 20. | Frissítve: 2026. október 21.
A PHP fejlesztői 2026. október 21-én rendkívüli biztonsági frissítéseket adtak ki két kritikus sérülékenység javítására. A CVE-2026-109618 és a CVE-2026-109619 azonosítójú hibák egyaránt 9,2-es súlyossági besorolást kaptak a CVSS 4.0 rendszerben. A hivatalos tájékoztatás szerint megfelelő körülmények között hitelesítés nélküli távoli kódfuttatást is lehetővé tehetnek.
A biztonsági kiadás az előző napon közzétett figyelmeztetést követően jelent meg. A javításokat a PHP 8.2.35, 8.3.36, 8.4.27 és 8.5.12 verziók tartalmazzák. A régebbi PHP-ágak esetében a rendszergazdáknak az adott disztribúció vagy hosszú távú támogatást biztosító szolgáltató biztonsági csomagjait kell ellenőrizniük.
A frissítés sürgős, mert egyik sérülékenységre sem ismert olyan általános konfigurációs védekezés, amely teljes biztonságot garantálna.
Megjelentek a rendkívüli PHP-frissítések
A PHP Security Team október 20-án figyelmeztette az üzemeltetőket két kritikus sérülékenységre, amelyek technikai részleteit a javítások megjelenéséig nem hozták teljes egészében nyilvánosságra.
A biztonsági kiadás 2026. október 21-én megjelent, és ezzel az érintett komponensek, a támadási lehetőségek, valamint a javított PHP-verziók is ismertté váltak.
A sebezhetőségek nem egy adott tartalomkezelő rendszerben, WordPress-bővítményben vagy tárhelyadminisztrációs felületen találhatók, hanem magában a PHP futtatókörnyezetében. Ez azért különösen jelentős, mert a PHP-t számos webalkalmazás és szerverkonfiguráció használja.
A kitettség nem korlátozódik az Apache egyik futtatási módjára. A PHP-FPM, a CGI-alapú környezetek, a LiteSpeed és más PHP-integrációk is érintettek lehetnek. A PHP fejlesztői az Apache mod_php használatánál különösen magas kockázatot jeleztek.
Mit tesz lehetővé a két sérülékenység?
A CVE-2026-109618 sérülékenység a PHP memóriahiányos állapotának kezeléséhez kapcsolódik. Speciálisan kialakított HTTP-kérések feldolgozásakor előfordulhat, hogy a futtatókörnyezet egy belső adatstruktúrát csak részlegesen inicializál, majd a hibakezelés során érvényes adatként próbálja feldolgozni.
Ez memóriasérüléshez vezethet, és megfelelő feltételek mellett távoli kódfuttatást eredményezhet.
A CVE-2026-109619 egy másik memóriakezelési problémát érint. Bizonyos belső állapotadatok megmaradhatnak azután is, hogy a hozzájuk tartozó memória felszabadult. Egy ugyanabban a PHP-folyamatban feldolgozott későbbi kérés így olyan adatra hivatkozhat, amely már nem érvényes.
A PHP fejlesztői mindkét sérülékenységet kritikusnak minősítették. A veszélyt tovább növeli, hogy bizonyos támadási útvonalak nem igényelnek felhasználói bejelentkezést, és akár az alkalmazás saját PHP-kódjának végrehajtása előtt is működésbe léphetnek.
Ez nem jelenti azt, hogy minden PHP-alapú weboldal azonos módon támadható, de azt igen, hogy kizárólag az alkalmazáskód vagy a tartalomkezelő rendszer frissítése nem tekinthető megfelelő javításnak.
Mely PHP-verziókhoz jelent meg javítás?
A PHP-projekt 2026. október 21-én négy támogatott verzióághoz publikált biztonsági kiadást.
| PHP-verzióág | Javított kiadás | |---|---| | PHP 8.2 | 8.2.35 | | PHP 8.3 | 8.3.36 | | PHP 8.4 | 8.4.27 | | PHP 8.5 | 8.5.12 |
A PHP 8.1 és korábbi verziói már nem kapnak közvetlen biztonsági frissítéseket a PHP-projekttől. Ez azonban nem feltétlenül jelenti azt, hogy egy vállalati Linux-disztribúció vagy hosszú távú támogatást biztosító szolgáltató sem tud hozzájuk javítást nyújtani.
A CloudLinux HardenedPHP és más kiterjesztett támogatási rendszerek a régebbi PHP-ágakhoz visszaportolt javításokat is biztosíthatnak. Ilyenkor a biztonságos csomag verziószáma eltérhet a PHP hivatalos kiadási számozásától.
Ezért a PHP-verziószám önmagában nem elegendő bizonyíték a biztonsági javítás meglétére. Az RPM-csomag pontos kiadását és a csomagszállító biztonsági közleményét is ellenőrizni kell.
cPanel és CloudLinux: külön ellenőrizendő PHP-környezetek
A cPanel & WHM biztonsági csapata külön értesítést küldött a két sérülékenységről. A közlemény hangsúlyozza, hogy a hibák a PHP-ben találhatók, nem a cPanel saját programkódjában.
A cPanel a 110-es, 134-es, 136-os és 138-as kiadási ágakhoz is tervez javításokat. Az értesítésben szereplő 110.0.152, 134.0.65, 136.0.49 és 138.0.17 azonosítók cPanel-verziók, nem pedig a javított PHP-csomagok verziószámai.
Egy modern cPanel-szerveren több PHP-változat is működhet egymás mellett. Az EasyApache 4 rendszer EA-PHP csomagokat használ, CloudLinux környezetben pedig ezek mellett ALT-PHP csomagok is jelen lehetnek.
A két rendszer külön frissítési csatornákat és kiadási ütemezést használhat. Ezért a cPanel kezelőfelületének sikeres frissítése önmagában nem bizonyítja, hogy valamennyi weboldal már javított PHP-futtatókörnyezetben működik.
A CloudLinux október 21-i közleménye szerint a javított ALT-PHP csomagok előkészítése megkezdődött, míg az EA-PHP csomagok javítását az EasyApache 4 25.91-es kiadásához ütemezték. Az aktuális elérhetőséget mindig a gyártó frissítési tájékoztatójából vagy a szerver tényleges csomagtárolóiból kell megállapítani.
Mit nyújt az Imunify360 WAF-védelme?
A CloudLinux az Imunify360 rendszerhez is kiadott védelmi szabályokat. A 8.83-as ModSecurity-szabálykészlet már tartalmaz blokkoló szabályt az egyik nyilvánosan ismert támadási mintára, valamint egy kapcsolódó megfigyelési szabályt.
A megfelelően konfigurált, aktív ModSecurityvel és Imunify360 WAF-védelemmel rendelkező kiszolgálókon ezek a szabályok csökkenthetik a kitettséget.
Ez azonban csak átmeneti védelem. A két sérülékenység több támadási útvonalon is kihasználható lehet, így a WAF nem helyettesíti a javított PHP-csomagok telepítését.
Ugyanez igaz az olyan ideiglenes konfigurációs óvintézkedésekre, mint a session.upload_progress.enabled = Off. Ez az egyik dokumentált támadási útvonalat korlátozhatja, de a sérülékenységeket önmagában nem szünteti meg.
Hogyan ellenőrizzük a szerverek PHP-környezetét?
A több PHP-verziót futtató tárhelyszervereken először azt kell azonosítani, hogy mely csomagok vannak ténylegesen telepítve, illetve az egyes weboldalak melyik PHP-verziót használják.
RPM-alapú Linux-rendszerekben a telepített EA-PHP és ALT-PHP csomagok például az alábbi paranccsal listázhatók:
rpm -qa | grep -E '^(alt-php|ea-php)' | sort -V
Ez csak a telepített csomagokat jeleníti meg, semmit nem módosít a szerveren.
A parancssori php -v eredménye nem feltétlenül egyezik meg a weboldalak tényleges PHP-verziójával. CloudLinux esetében a PHP Selector, cPanel alatt pedig a MultiPHP Manager és az egyes domainek futtatási beállításai is befolyásolják a használatban lévő verziót.
A biztonsági javítások telepítése után ellenőrizni kell a csomagok kiadási számát, a PHP-FPM vagy LSAPI folyamatok újraindulását, az Apache működését és az alkalmazások hibanaplóit. A javított csomag akkor nyújt tényleges védelmet, ha már a futó szolgáltatások is az új kódot használják.
Mi a teendő, ha még nem érhető el a javítás?
Az október 21-i biztonsági kiadás megjelenése nem jelenti azt, hogy valamennyi Linux-disztribúció és tárhelyszolgáltatói csomagtároló azonnal tartalmazza a frissített PHP-változatokat.
A köztes időszakban indokolt a szükségtelenül elérhető alkalmazások korlátozása, a WAF-védelem és annak blokkoló üzemmódjának ellenőrzése, valamint a gyanús HTTP-kérések figyelése.
A PHP-projekt külön technikai útmutatót tett közzé a kockázatot mérséklő ideiglenes beállításokról. Ezek a rendelkezésre álló támadási útvonalak egy részét csökkenthetik, de nem biztosítanak teljes védelmet.
Az üzemeltetőknek ezért nem érdemes pusztán a WAF vagy egyetlen PHP-konfigurációs kapcsoló alapján biztonságosnak minősíteniük a rendszert.
Amennyiben egy érintett, internet felől elérhető környezet nem javítható, a szolgáltatás ideiglenes korlátozását vagy elkülönítését is mérlegelni kell.
A következő lépés a javítások ellenőrzött telepítése
Az október 20-i előzetes figyelmeztetés után a helyzet október 21-én egyértelművé vált: a két kritikus PHP-sérülékenység valós, a javítások hivatalosan megjelentek, és az érintett rendszerek haladéktalan frissítése indokolt.
Az üzemeltetők számára most a legfontosabb feladat a ténylegesen futó PHP-környezetek felmérése, a megfelelő gyártói csomagok beszerzése, majd azok ellenőrzött telepítése.
Külön figyelmet igényelnek a többverziós cPanel- és CloudLinux-szerverek, illetve azok az alkalmazások, amelyek kompatibilitási okokból régebbi PHP-ágakra támaszkodnak.
A sikeres biztonsági frissítés mércéje nem az, hogy lefutott egy frissítőparancs, hanem az, hogy valamennyi érintett PHP-környezetben igazoltan telepítve van a szükséges javítás, és azt a futó szolgáltatások valóban használják.
*Frissítve: 2026. október 21. Az eredeti cikk 2026. október 20-án, a PHP Security Team előzetes figyelmeztetése alapján jelent meg. A frissítés a hivatalosan kiadott javításokkal, a CVE-azonosítókkal és az új technikai információkkal egészíti ki az eredeti tájékoztatást.*