Feltárták a PHP kritikus sebezhetőségeit, és közzétették a javítófrissítéseket.

Megjelent a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35 kijavító kiadása, valamint javítások a már nem támogatott PHP 7.4, PHP 8.0 és PHP 8.1 ágain, amelyekben két kritikus sérülékenységet javítottak:

  • CVE-2026-109618 — távoli kódfuttatás, amely a szabad memória kimerülésével kapcsolatos, mivel a memóriahiány-kezelő a longjmp() függvény végrehajtása során megszakíthatja a PHP-értelmezőt egy olyan állapotban, amikor csak a kérés feldolgozásához kapcsolódó belső struktúrák egy része van inicializálva. Következésképpen a kérés feldolgozásának befejezését végző függvény ezekhez a struktúrákhoz hivatkozik, mintha már inicializálva lettek volna, habár a számukra memória nem lett allokálva.

    A támadás fő irányvonala a multipart kérések manipulálása, hogy olyan körülményeket teremtsenek, amelyekből a folyamat rendelkezésre álló memória kimerül. A post_max_size korlát megkerülésére a Content-Length fejlécet nem adják meg, és egy hatalmas számú HTTP-fejlécet lehet átadni. Lehetséges célzott támadások végrehajtása is a PHP-alkalmazások egyes műveleteire, amelyek túlzottan sok memóriát használnak. Az exploit létezését a mod_php megerősítette, mivel ez a shutdown() függvényt hívja meg még hiba esetén is. A PHP-FPM hiba esetén befejezi a gyermekfolyamatot, ami nehezíti a támadás végrehajtását, de elméletileg nem zárja ki azt.

  • CVE-2026-109619 — távoli kódfuttatás, amely a memória felszabadítása utáni memóriahozzáférés miatt következik be, a kéréshez kapcsolódó globális állapot helytelen törlése miatt. Ha a kérést végzetes hiba, időtúllépés vagy memóriahiány szakítja meg, a globális állapotot nem lehet visszaállítani, és a mutatók aktívak maradhatnak, annak ellenére, hogy a memóriát, amelyre mutatnak, felszabadították. A következő kérés feldolgozása során ugyanabban a folyamatban a megmaradt mutatóval a régi globális állapothoz lehet hozzáférni.

    A memória kimerülésének a multipart kérések feldolgozása során történő jelzésére szolgáló feltételek létrehozása révén használható ki. Az elsődleges és megerősített támadási vektorként említik a fatal_error_backtraces kezelőt a PHP 8.5-ben, amely nem állítja vissza a nyomvonal állapotát a befejezéskor. Az első esetben a támadás lehetséges mod_php és PHP-FPM alatt, míg a második esetben csak mod_php alatt. Szintén megemlítik a még nem megerősített lehetőségét a támadás végrehajtásának olyan konfigurációkban, ahol a kérés korai feldolgozásának fázisában figyelmeztetéseket generáló irányelvek vannak.

Azt állítják, hogy a sebezhetőségek teljes blokkolása csak frissítés telepítésével lehetséges. Az alábbi intézkedések csökkenthetik a sikeres támadások kockázatát, de nem teszik a rendszert teljesen biztonságossá:

  • A php.ini paraméterének "memory_limit=-1" beállítása, amely megnehezíti a támadó számára a memória korlátok kimerülésének ellenőrzését.
  • A "post_max_size = 8M" paraméter beállítása, ha nincs szükség nagy fájlok feltöltésére. Az "upload_max_filesize" paraméter értékének kisebbnek kell lennie, mint a "post_max_size" értéke.
  • A rendszer szintjén megengedett memóriafogyasztási limit beállítása a cgroup memory.max vagy a konténer memóriafogyasztási paraméterein keresztül, de nem a rendszerlimitek RLIMIT_AS és RLIMIT_DATA által, amelyek csak a problematicus longjmp() hívást provokálják.
  • Ha a teljesítmény nem fontos, korlátozhatja az egy munkafolyamat által feldolgozott kérések számát a PHP-FPM pm.max_requests=1 és az Apache httpd MaxRequestsPerChild beállításával.
  • Beállítás php.ini vagy konfigurációs szinten a szerver (nem ini_set() vagy FPM .user.ini-n keresztül, mivel a paraméternek a kérés feldolgozása előtt kell érvényesülnie) a "session.upload_progress.enabled=0" paramétert.
  • A PHP 8.5 kiadásának használata során be kell állítani a "fatal_error_backtraces=0" paramétert.
  • A különböző kérésekhez kapcsolódó elavult vagy hibás beállítások eltávolítása (mint például assert.* és hibás open_basedir útvonalak), amelyek diagnosztikai üzeneteket generálnak az inicializálás előtt.
  • A PHP kódban azokat a helyzeteket kell megszüntetni, amelyek időtúllépésekhez és fatális hibákhoz vezetnek, például a callback-handler és a feltöltések feldolgozása során fellépő hibák miatt.
  • A régi PHP verziók kódjában az első sebezhetőség blokkolásához a longjmp() hívás helyett az _exit() használható a szabad memória kimerülésének kezelőjében.
  • Továbbá csökkenteni lehet a max_input_nesting_level paraméter értékét a php.ini fájlban, és blokkolni a multipart kéréseket, ahogy azt a korábbi bejelentésben bemutatták.

A sebezhetőségek elhárításának állapotát az alábbi oldalakon lehet értékelni: Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch,
Fedora, FreeBSD.

Kiegészítés 1: A sebezhetőségeket AI modellek, mint például a GPT‑5.6 és a Gemini 4 Argon révén tárták fel. Az OpenAI közzétette a php2shell-checker eszközt, amely a weboldalak és a helyi végrehajtható fájlok sebezhetőségének ellenőrzésére szolgál, de ez az eszköz csak a HTTP szerver által visszaadott PHP verzió számát, vagy a "php -v" parancs kimenetét ellenőrzi, részletes elemzés nélkül.

Kiegészítés 2: Az exploitet prototípusának szerzője, amely a memória duplaszabadítása (double-free) által okozott sebezhetőséget használja, arról számolt be, hogy a probléma továbbra is megoldatlan a PHP 8.5.12 kiadásában, és az exploit továbbra is működik. Korábban a PHP képviselői kijelentették, hogy ez a sebezhetőség nem kapcsolódik a tervezett javításokhoz, és nem valós probléma. Az exploit szerzője pedig azt állította, hogy egy teljesen más sebezhetőségről van szó.

Forrás: opennet.ru

Megbízható hosting vásárlása weboldalak számára, DDoS védelemmel, VPS VDS szerverek. 🔥 Megbízható webtárhely vásárlása DDoS védelemmel, VPS VDS szerverek | ProHoster