CVE-2026-109618: RCE Out-of-Memory állapot révén

Röviden: A CVE-2026-109618 a PHP2Shell mögötti két rés egyike. Egy Out-of-Memory állapot megszakíthatja a PHP-t, miközben a kérésadatok még csak részben vannak inicializálva; takarításkor ilyenkor érvénytelen adatok érvényesnek számíthatnak. Ez bejelentkezés nélküli kódfuttatást tesz lehetővé. A hibát a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 verzióban javították.

Mi a CVE-2026-109618?

A CVE-2026-109618 (GitHub-azonosítója GHSA-w8hw-w9fx-j79w) egy memóriahiba-rés a PHP magjában. CVSS v4.0 9,2 értékkel minősítették. A CVE-2026-109619-cel együtt alkotja azt, amit a média PHP2Shell néven emleget.

A hatás az úgynevezett unauthenticated Remote Code Execution: egy támadó távolról és felhasználói fiók nélkül futtathat kódot a webszerveren. Ezzel a rés a webszerverek legveszélyesebb sebezhetőség-osztályába tartozik.

Hogyan keletkezik a rés alapvetően

Amikor a PHP feldolgoz egy webes kérést, belsőleg adatstruktúrákat hoz létre ehhez a kéréshez, például a beküldött űrlapadatokhoz. Ha a PHP eközben eléri a memóriahatárát, Out-of-Memory állapottal megszakad. A php.net szerint ez akkor történhet meg, amikor a kérésadatok még csak részben vannak inicializálva.

Minden kérés végén a PHP takarít, és felszabadítja a memóriát. Éppen itt van a hiba: a takarítás az érvénytelen, csak félig létrehozott adatokat érvényesként kezelheti. Ebből a hibás viselkedésből bizonyos feltételek mellett kódfuttatás vezethető le.

Miért ennyire komoly egy ilyen hiba? A programozási nyelv memóriahibája az összes rajta futó alkalmazást érinti, függetlenül attól, milyen gondosan programozták őket. Egy gondozott, naprakész bővítményekkel rendelkező WordPress-telepítés éppúgy érintett, mint egy régi saját fejlesztés. Ezért itt nem az alkalmazás frissítése segít, hanem csak a PHP frissítése.

A kihasználás további műszaki részleteit tudatosan nem tesszük közzé. A védekezéshez nem szükségesek: az a döntő, hogy a szervere javított verziót használ-e, és hogy az új folyamatok ténylegesen futnak-e.

Érintett verziók és üzemmódok

Érintettek a PHP-FPM, az Apache mod_php-val, a php-cgi, a FrankenPHP és a LiteSpeed üzemmódok. A PHP-csapat a mod_php esetében értékeli a kockázatot a legmagasabbra. A disztribúciók és a tárhelyszolgáltatók részben backportokat telepítenek, így régebbi verziószám jelenik meg, noha a hiba javítva van. A csomagállapot és a szolgáltató megerősítése a mérvadó.

A nagyságrendhez: a Palo Alto Networks (Unit 42) több mint 22,6 millió kitett, potenciálisan sebezhető példányt számolt össze. A BSI a 3. riasztási szintet (narancs) hirdette ki, és gyors, nagy léptékű kihasználással számolt.

A CVE-2026-109618 elhárítása: frissítés és újraindítás

Az egyetlen teljes megoldás a frissítés. Először ellenőrizze a verziót és a csomagállapotot. A csomagnevek disztribúciónként eltérnek; a példák PHP 8.3-ból indulnak ki:

php -v
apt policy php8.3-fpm          # Debian/Ubuntu
dnf info php-fpm               # RHEL, AlmaLinux, Rocky, Fedora
rpm -q --changelog php-fpm | grep -i "CVE-2026-109618"

Ha a csomag changelogja megnevezi a CVE-számot, a backport telepítve van. Ha hiányzik, az nem jelenti automatikusan, hogy a csomag sebezhető; ilyenkor a verziótáblázattal való összevetés vagy a szolgáltatónál való rákérdezés segít.

A frissítés után az összes PHP-folyamatot újra kell indítani, például systemctl restart php8.3-fpm paranccsal, vagy mod_php esetén az Apache újraindításával. Hogyan győződhet meg róla, hogy nem fut már régi worker, azt a PHP-FPM és az összes worker újraindítása oldal mutatja.

Átmeneti intézkedések, ha a frissítés még nem megy

A php.net átmeneti intézkedéseket tett közzé a PHP2Shell ellen. Ezek mindkét résre közösen érvényesek, és kifejezetten nem teljes védelmet jelentenek. Az, hogy több közülük a memóriahatárokra vonatkozik, illeszkedik a CVE-2026-109618 Out-of-Memory kiváltójához; az egyes intézkedések egyes CVE-khez való hivatalos hozzárendelése azonban nincs.

; Példa FPM-pool, pl. /etc/php/8.3/fpm/pool.d/www.conf (az útvonal disztribúciónként eltérő)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M          ; 32M, ha szükség van feltöltésekre
php_admin_value[upload_max_filesize] = 6M    ; immer unter post_max_size
php_admin_flag[session.upload_progress.enabled] = off

Az értékeket úgy kell beállítani, hogy az alkalmazások ne írhassák felül őket, ezért php_admin_value. A memory_limit=-1 esetén a szolgáltatásnak kívülről, konténeren vagy cgroupon keresztül kell memóriahatár, nem az RLIMIT_AS vagy az RLIMIT_DATA révén. PHP 8.5-ön hozzájön a fatal_error_backtraces=0. Az összes részlet az Azonnali intézkedések, ha még nem tud javítani oldalon van.

Hogyan segít konkrétan a PHP SOS?

A PHP-javítási szolgáltatásunkkal strukturáltan zárjuk le a CVE-2026-109618-at:

• A jelenlegi állapot felmérése: PHP-ág, üzemmód, csomagforrás és backport-állapot szerverenként.
• Frissítés telepítése a megfelelő csomagforrásból, vagy ahol ez nem megy, az átmeneti intézkedések szabályos beállítása a pool- vagy szerverkonfigurációban.
• Az újraindítás ellenőrzése: Ellenőrizzük, hogy nem fut-e már régi PHP-folyamat.
• Igazolás: Dokumentációt kap a verziókkal és csomagállapotokkal a beavatkozás előtt és után, például a vezetésnek, a biztosítónak vagy az adatvédelemnek.

Gyakori kérdések

Források

• php.net: biztonsági közlemények
• PHP 8 ChangeLog
• BSI: a német Szövetségi Információbiztonsági Hivatal