# CVE-2026-109619: RCE elavult globális állapot révén

> A CVE-2026-109619 érthetően: miért válik veszélyessé a kérések között megmaradó belső állapot, mely PHP-verziók javítottak, és hogyan biztosíthat.

Forrás: https://phpsos.de/hu/php2shell/cve-2026-109619/  
Á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-109619 a PHP2Shell mögötti második rés. Egy kéréshez tartozó belső állapot a memória felszabadítása után megmaradhat; egy későbbi kérés ugyanabban a workerben felhasználhatja, mielőtt visszaállítanák. A következmény bejelentkezés nélküli kódfuttatás. Megoldás: frissítés a PHP 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35 verzióra, és az összes worker újraindítása.

## Mi a CVE-2026-109619?

A CVE-2026-109619 (GitHub-azonosítója GHSA-6wmf-4rv5-p3rp) CVSS v4.0 9,2 értékű. A [CVE-2026-109618](https://phpsos.de/hu/php2shell/cve-2026-109618/)-cal együtt alkotja a PHP2Shell-t. Mindkét rés magában a PHP-ban van, nem egy alkalmazásban.

A hatás ugyanaz, mint a testvérrésnél: egy támadó távolról, jelszó és felhasználói fiók nélkül futtathat kódot a szerveren. Az ok azonban más.

## Miért veszélyes az elavult állapot a workerben

Egy PHP-webszerver nem indít új folyamatot minden kéréshez. A PHP-FPM, az Apache mod_php-val, a LiteSpeed vagy a FrankenPHP esetében egy worker egymás után sok kérést dolgoz fel. Két kérés között a PHP visszaállítja a belső állapotát, hogy az A kérésből semmi se kerüljön a B kérésbe.

A CVE-2026-109619 esetében ez a visszaállítás nem sikerül teljesen. A php.net szerint a kéréshez tartozó belső állapot a memória felszabadítása után megmaradhat. Egy későbbi kérés ugyanabban a workerben felhasználhatja ezt az elavult állapotot, mielőtt visszaállítanák. Leegyszerűsítve: valamit tovább használnak, ami valójában már nem érvényes.

Az üzemeltetés szempontjából ez figyelemre méltó. A workerek újrafelhasználása szándékos, mert gyorssá teszi a webszervert: egy workernek nem kell minden kéréshez újraindulnia, bővítményeket betöltenie és memóriát lefoglalnia. A rés tehát olyan tulajdonságot érint, amellyel gyakorlatilag minden éles PHP-telepítés rendelkezik. A php.net nem nevez meg olyan konfigurációt, amely a problémát teljesen elkerüli; ezért az út a frissítésen át vezet.

A kihasználás részleteit nem tesszük közzé. Az üzemeltetők számára az számít: minden olyan üzemmódot szemmel kell tartani, amelyben a workerek több kérést szolgálnak ki, és éppen ezek a szokásos üzemmódok.

## A két PHP2Shell-rés összehasonlítása

| Jellemző | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| GitHub-azonosító | GHSA-w8hw-w9fx-j79w | GHSA-6wmf-4rv5-p3rp |
| Minősítés | CVSS v4.0 9,2 | CVSS v4.0 9,2 |
| Kiváltó ok | Out-of-Memory a kérésadatok inicializálása közben | A belső állapot a felszabadítás után megmarad |
| Hatás | Kódfuttatás bejelentkezés nélkül | Kódfuttatás bejelentkezés nélkül |
| Javítva ebben | 8.5.12, 8.4.27, 8.3.36, 8.2.35 | 8.5.12, 8.4.27, 8.3.36, 8.2.35 |

Érintettek a PHP-FPM, az Apache mod_php-val, a php-cgi, a FrankenPHP és a LiteSpeed. A legmagasabb kockázatot a PHP-csapat a mod_php esetében látja; hogy miért, azt a [Miért a mod_php viseli a legnagyobb kockázatot](https://phpsos.de/hu/php2shell/mod-php-risiko/) magyarázza.

## A CVE-2026-109619 lezárása: frissítés, majd az összes worker újraindítása

Éppen ennél a résnél az újraindítás a döntő. Amíg a régi workerek a memóriában futnak, a szerver tovább dolgozik a hibás kóddal, még ha az új fájlok már rég a lemezen vannak.

Ellenőrizze a verziót és a csomagállapotot. A csomagnevek disztribúciónként és tárhelyszolgáltatói felületenként eltérnek:

```bash
php -v
php-fpm8.3 -v                  # az FPM-binárisnak más verziója lehet, mint a CLI-nek
apt policy php8.3-fpm          # Debian/Ubuntu
dnf info php-fpm               # RHEL-család
rpm -q --changelog php-fpm | grep -i "CVE-2026-109619"
```

Ezután indítsa újra az összes érintett szolgáltatást:

```bash
sudo systemctl restart php8.3-fpm     # minden telepített PHP-verzióhoz
sudo systemctl restart apache2        # mod_php esetén; RHEL-en a szolgáltatás neve httpd
```

Ha a disztribúciója vagy a tárhelyszolgáltatója backportot telepít, a kijelzett verziószám valószínűleg ugyanaz marad. Ilyenkor a csomag changelogja és a szolgáltató írásos megerősítése számít. A lépésenkénti ellenőrzést a [PHP-FPM és az összes worker újraindítása](https://phpsos.de/hu/php2shell/php-fpm-neustart/) oldalon találja.

> **Tipp:**
> Jegyezze fel az újraindítás dátumát és időpontját. A későbbi értékeléshez, hogy a támadás a javítás előtt vagy után történt-e, ez az időpont a legfontosabb vonatkoztatási pont.

## Mi marad a javítás után még teendő

A javítás nem bizonyítja, hogy korábban nem történt semmi. Médiabeszámolók szerint egy első támadási kísérletet október 17-én figyeltek meg, négy nappal a javítások előtt. Őrizze meg a szervernaplókat október 20-tól, ahogy a szakmai sajtó ajánlja, és ellenőrizze a szervert feltűnő jelek szempontjából. Tudnivalókat a [Már feltörték a rendszeremet?](https://phpsos.de/hu/php2shell/bin-ich-gehackt-anzeichen/) oldal ad.

Gondoljon közben a hatókörre: sikeres kódfuttatásnál a támadó a PHP-folyamat jogaival rendelkezik. Olvashatja azt, amit az alkalmazás olvashat, például az adatbázis-hozzáféréseket vagy API-kulcsokat tartalmazó konfigurációs fájlokat. Ha egy incidens beigazolódik, ezeket a hozzáférési adatokat a tisztítás után meg kell újítani.

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

A [PHP-javítási szolgáltatással](https://phpsos.de/hu/leistungen/php-patch-service/) követhetően hajtjuk végre a javítást:

- **Felmérés:** Mely PHP-verziók és üzemmódok futnak melyik szerveren, és melyik csomagforrás szállítja őket?
- **Javítás:** Frissítés a megfelelő forrásból, vagy a php.net szerinti átmeneti intézkedések, ahol a frissítés még akadályba ütközik.
- **Az újraindítás ellenőrzése:** Folyamatról folyamatra ellenőrizzük, hogy már csak a javított verzió fut.
- **Dokumentálás:** Verziók, csomagállapotok és újraindítási időpontok, hogy igazolni tudja az állapotot.


## Gyakori kérdések

**Miben különbözik a CVE-2026-109619 a CVE-2026-109618-tól?**  
A CVE-2026-109618 akkor keletkezik, ha egy Out-of-Memory állapot a kérést az inicializálás közben megszakítja. A CVE-2026-109619 azt az állapotot érinti, amely egy kérés vége után a workerben megmarad. Mindkettő bejelentkezés nélküli kódfuttatáshoz vezet, és ugyanazokban a PHP-verziókban javították őket.

**Segít, ha a PHP-FPM workereket gyakrabban újraindítom?**  
A frissítés pótlására nem alkalmas. A php.net a gyakoribb worker-újraindításokat nem nevezi meg átmeneti intézkedésként. A workereket viszont a frissítés után újra kell indítani, hogy a javított verzió egyáltalán fusson.

**Véd a CMS-frissítés a CVE-2026-109619 ellen?**  
Nem. A rés a PHP-ban van, nem a WordPressben, a Shopware-ben, a TYPO3-ban vagy más rendszerben. Csak egy PHP-frissítés vagy a szolgáltató megerősített backportja zárja le.

**Vannak ismert nyomai a CVE-2026-109619-en keresztüli támadásnak?**  
Megerősített Indicators of Compromise-t eddig nem tettek közzé. A felismerés viselkedéselemzésen alapul, például új PHP-fájlokon, szokatlan kimenő kapcsolatokon vagy ismeretlen cron-feladatokon.

## 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/)