Kritikus PHP-sebezhetőségek: a javítás könnyű, a megtalálás nehéz
Két kritikus, hitelesítés nélkül kihasználható távoli kódfuttatási hibát javított a PHP. A Sourcegraph szerint a frissítés mellett az összes érintett futtatókörnyezet megtalálása is komoly feladat lehet.
- A PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 javítja a két hibát.
- A CVE-2026-109618 és CVE-2026-109619 CVSS v4 besorolása 9,2.
- A PHP 8.1 és korábbi verziók már nem támogatottak.
- A Sourcegraph szerint az érintett futtatókörnyezetek felderítése a javítás egyik legnehezebb része.
- A frissítés után a PHP-munkafolyamatokat is újra kell indítani.
Négy PHP-kiadás kapott javítást
A PHP 2026. október 21-én kiadta a 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verziókat. A frissítések a CVE-2026-109618 és CVE-2026-109619 azonosítójú hibákat javítják, amelyek mindegyike 9,2-es CVSS v4 besorolást kapott.
A Sourcegraph beszámolója szerint mindkét sérülékenység memóriabiztonsági hiba a kérések feldolgozási életciklusában. A mod_php használata esetén a hibák még az alkalmazáskód futása előtt elérhetők lehetnek. A támadási lánc elindításához egy speciálisan kialakított, több részből álló POST-kérés is elegendő lehet.
A hibák kutatói a php2shell nevet használják. A PHP a javításokkal együtt biztonsági figyelmeztetést és két GitHub biztonsági közleményt is közzétett, GHSA-w8hw-w9fx-j79w és GHSA-6wmf-4rv5-p3rp azonosítóval. A projekt saját útmutatója szerint „nincsenek teljes körű enyhítő intézkedések, a frissítés az egyetlen biztonságos választás”.
A veszélyes PHP-t nem mindig könnyű megtalálni
A sérülékeny kód a PHP értelmezőjében található, ezért minden olyan hely számít, ahol egy projekt PHP-futtatókörnyezetet húz be. Ilyenek lehetnek a Dockerfile-ok, a PHP-alapú lemezképek, az operációs rendszer csomagtelepítései, a Kubernetes- és Helm-konfigurációk, a Composerrel dolgozó CI-környezetek, valamint a WordPresshez, Matomóhoz vagy más kész alkalmazásokhoz használt beállítások.
A verziók különböző helyeken lehetnek rögzítve. Egy szervezet használhat például hivatalos php:* alapképet, apt-get vagy más csomagkezelő által telepített PHP-t, illetve olyan belső alapképet, amely eredetileg egy régi PHP-verzióból épült. A Sourcegraph szerint egy hagyományos sebezhetőségvizsgáló megmutathatja, mi fut jelenleg, de nem feltétlenül derül ki belőle, melyik kódtár építi az adott környezetet, ki felel érte, vagy honnan kerül vissza egy régi verzió a következő build során.
A vállalat a Deep Search használatát javasolja az érintett Dockerfile-ok, Helm-chartok és CI-munkafolyamatok feltérképezésére. A szolgáltatás természetes nyelvű kérdés alapján keres a kódban és navigál benne, majd linkeket ad az eredményeket alátámasztó fájlokhoz.
A frissítés után a futó példányokat is újra kell indítani
A javított verziókra történő átállás után a munkafolyamatokat is újra kell indítani, mert az új csomag nem frissíti automatikusan a memóriában már futó régi PHP-binit. A Sourcegraph szerint elsőként az internet felől elérhető mod_php példányokat kell kezelni, majd az FPM, a FrankenPHP és az LSAPI környezeteket.
Ha egy internetre kitett gép sérülékeny verziót futtatott, a vállalat szerint azt lehetséges kompromittálódott rendszerként kell kezelni. Ilyenkor a webes felhasználó által olvasható adatokat, köztük adatbázis-jelszavakat, API-kulcsokat és felhő-hitelesítő adatokat is érintettnek kell tekinteni. A Sourcegraph teljes körű vizsgálatot, a naplók mentését és a gép újraépítés előtti pillanatfelvételét javasolja.
A PHP 8.1 és az annál korábbi kiadások már nem támogatottak a projekt szerint, ezért ezekhez a verziókhoz nem érkezik javítás. Az ilyen rendszereket a Sourcegraph szerint el kell szigetelni vagy támogatott ágra kell migrálni. A vállalat Agentic Batch Changes eszközével több kódtár módosítása is összehangolható, például a PHP 8.2 és 8.5 közötti alapképek és csomagrögzítések frissítése.
Sourcegraph: php2shell: patching PHP is easy, finding it is the hard part
