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-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 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:
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:
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 oldalon találja.
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? 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 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.