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

> A CVE-2026-109618 magyarázata: hogyan vezethet kódfuttatáshoz a PHP Out-of-Memory állapota, mely verziók javítottak, és mit tegyenek most az adminisztrátorok.

Forrás: https://phpsos.de/hu/php2shell/cve-2026-109618/  
Állapot: 2026. 10. 25.  
Szolgáltató: PHP SOS, PHP-vészhelyzeti segítség és szerverbiztonság. Azonnali segítség WhatsAppon: https://wa.me/491736494914?text=%C3%9Cdv%C3%B6zl%C3%B6m%2C%20PHP%20SOS%21%20Seg%C3%ADts%C3%A9gre%20van%20sz%C3%BCks%C3%A9g%C3%BCnk%20a%20PHP-szerver%C3%BCnkkel.%20C%C3%A9g%3A%20%E2%80%A6%20Weboldal%3A%20%E2%80%A6

**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](https://phpsos.de/hu/php2shell/cve-2026-109619/)-cel együtt alkotja azt, amit a média [PHP2Shell](https://phpsos.de/hu/php2shell/was-ist-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

| PHP-ág | Utolsó állapot a javítás előtt | Javítva ettől |
|---|---|---|
| 8.5 | 8.5.11 | 8.5.12 |
| 8.4 | 8.4.26 | 8.4.27 |
| 8.3 | 8.3.35 | 8.3.36 |
| 8.2 | 8.2.34 | 8.2.35 |
| 8.1 és régebbi | nincs hivatalos frissítés | csak minimális forráskód-backportok a 7.4, 8.0, 8.1 verzióhoz |

É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:

```bash
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](https://phpsos.de/hu/php2shell/php-fpm-neustart/) 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.

```ini
; 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](https://phpsos.de/hu/php2shell/sofortmassnahmen-ohne-patch/) oldalon van.

> **Fontos:**
> Ha sem a frissítés, sem az átmeneti intézkedések nem lehetségesek azonnal, a BSI azt ajánlja, hogy az érintett webszervereket átmenetileg vegyék le a hálózatról.

## Hogyan segít konkrétan a PHP SOS?

A [PHP-javítási szolgáltatásunkkal](https://phpsos.de/hu/leistungen/php-patch-service/) 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

**Mennyire kritikus a CVE-2026-109618?**  
A rést CVSS v4.0 9,2 értékkel minősítették, vagyis kritikus. Kártékony kód távoli futtatását teszi lehetővé bejelentkezés nélkül. A BSI (a német Szövetségi Információbiztonsági Hivatal) a PHP2Shell kapcsán a 3. riasztási szintet (narancs) hirdette ki.

**Elég a memory_limit megemelése?**  
Nem. A php.net a memory_limit=-1 értéket, a szerverkonfigurációban rögzítve, az egyik átmeneti intézkedésként nevezi meg. Kifejezetten nem teljes védelem, és konténeren vagy cgroupon keresztüli memóriahatárt igényel. A megoldás a frissítés marad.

**Melyik GHSA-azonosító tartozik a CVE-2026-109618-hoz?**  
A GitHub Security Advisoryben a rés GHSA-w8hw-w9fx-j79w alatt szerepel. A második PHP2Shell-rés, a CVE-2026-109619 azonosítója GHSA-6wmf-4rv5-p3rp.

## Források

- [php.net: biztonsági közlemények](https://www.php.net/)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [BSI: a német Szövetségi Információbiztonsági Hivatal](https://www.bsi.bund.de/)