Kritikus PHP-sebezhetőségek (CVE-2026-109618 és CVE-2026-109619): mi történt és mit tegyen

2026. október 21-én a PHP projekt javításokat adott ki két kritikus hibához, a CERT-EU pedig ugyanazon a napon közzétette a 2026-018 számú figyelmeztetést. Mindkettő 9,2-es besorolást kapott, és mindkettőt hitelesítés nélküli távoli kódfuttatásként írják le. Ha WordPress-oldalt, webáruházat vagy bármilyen más PHP-alkalmazást üzemeltet, ez Önre is vonatkozik, a megoldás pedig frissítés, nem beállítás. A cikk elmagyarázza, mi ismert, hogyan jut be a támadás, és mit kell tenni. Állapot: 2026. október 22., a CERT-EU figyelmeztetés 1.1-es verziója alapján.

Mi történt

A PHP október 20-án biztonsági kiadást jelentett be, a javításokat pedig október 21-én 13:30-kor (UTC) tette közzé. A CERT-EU „Critical Vulnerabilities in PHP” címmel adta ki figyelmeztetését, és két CVE-azonosítót sorol fel: CVE-2026-109618 és CVE-2026-109619, mindkettő 9,2-es pontszámmal. A CERT-EU azt is írja, hogy a technikai részleteket már nyilvánosan tárgyalják, és az első proof-of-concept kód terjedni kezdett. A figyelmeztetés nem erősíti meg a valós támadásokat, de kimondja, hogy ettől valószínűbb, hogy a támadók már kihasználják a hibákat. Kezelje sürgősként.

Kiket érint

Érintett minden olyan PHP-kiadás, amely egy támogatott ágon a javított verziónál régebbi, valamint minden életciklusa végére ért ág.

A CERT-EU megnevezi a PHP-FPM-et, az Apache-ot mod_php-vel, a php-cgi-t, a FrankenPHP-t és a LiteSpeedet. A PHP csapata szerint a mod_php hordozza a legnagyobb kockázatot. Érintettek lehetnek a PHP-t beágyazó termékek is; a CERT-EU a holland NCSC listájára hivatkozik e cikk végén. Minden olyan telepítés számít, amely webes kéréseket szolgál ki, függetlenül attól, hogy van-e fájlfeltöltő űrlapja.

Hogyan jut el a támadó az első hibához

Senkinek sem kell bejelentkeznie. A CERT-EU szerint egy bemutatott kihasználó kód azt mutatja, hogy egyetlen hitelesítés nélküli kérés kiválthatja a támadást még azelőtt, hogy bármilyen alkalmazáskód lefutna. Ezt a legtöbben figyelmen kívül hagyják: nem számít, hogy a WordPress naprakész-e, a bővítmények javítottak-e, és az űrlap védett-e. A kérés először a PHP-motorhoz ér.

Az első hiba, a CVE-2026-109618, így működik:

1. Egy kérés megérkezik egy olyan címre, amelyet a PHP szolgál ki. Nincs bejelentkezés, nincs fiók.
2. A PHP elkezdi olvasni a kérés törzsét. A CERT-EU példaként az űrlapalapú fájlfeltöltések feldolgozását említi.
3. A PHP a memory_limit korlátot longjmp() segítségével érvényesíti. Ha a korlátot túllépik, kiugrik abból, amit éppen csinált, és befejezi a kérést.
4. Ha ez a kérés belső adatainak felépítése közben történik, ezek az adatok csak félig épülnek fel.
5. A későbbi takarítás az érvénytelen adatot érvényesnek tekinti, és olyan memóriát szabadít fel, amelyet sosem inicializáltak. Ez a memória még tartalmazhat korábbi foglalásokból származó, a támadó által irányított adatot.
6. Innen a figyelmeztetés távoli kódfuttatást ír le a kiszolgálón.

Szándékosan nem írjuk le, hogyan irányítja a támadó az utolsó lépést. Elég tudni, hogy a belépési pont nem az Ön alkalmazása, és éppen ezért az alkalmazáson belül semmi sem állíthatja meg.

A második hiba: az állapot, amely túléli a memóriáját

A CVE-2026-109619 más mechanizmus, de ugyanaz az eredmény. A PHP minden kéréshez belső állapotot tart nyilván. Bizonyos hibák után, például végzetes hiba esetén, ez az állapot megmaradhat, noha az alatta lévő memóriát már felszabadították. Az ugyanazon munkafolyamat által kezelt következő kérés ekkor felhasználhatja ezt az elavult állapotot, mielőtt azt a szokásos módon alaphelyzetbe állítanák. A támadónak két kérésre van szüksége, amelyek ugyanarra a munkafolyamatra kerülnek; a CERT-EU az eredményt ugyanúgy értékeli, mint az első hibánál: távoli kódfuttatás.

Mit tegyen ma

1. Derítse ki, melyik PHP-verzió szolgálja ki valójában az oldalát. A parancssori php -v a parancssori verziót mutatja, amely eltérhet attól, amelyet a webkiszolgáló használ. Ellenőrizze a php-fpm -v kimenetét, a tárhelypanelt vagy egy phpinfo()-t hívó oldalt. Megosztott tárhelyen kérdezze meg a szolgáltatóját.
2. Frissítsen javított verzióra: 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35. A disztribúciók gyakran a verziószám módosítása nélkül portolják vissza a javításokat, ezért a szállító biztonsági közleményében a CVE-számokat keresse. Konténerekben építse újra a képfájlt egy frissített alapképből. A PHP csapata megjegyzi, hogy a rpms.remirepo.net a kiadás napján nem tartalmazott frissítést, és a disztribúciós csomagokat vagy a forrásból való fordítást ajánlja.
3. Indítsa újra az összes PHP-munkafolyamatot. A lemezen végzett frissítés nem változtatja meg a már futó folyamatokat. Indítsa újra a PHP-FPM-et vagy a webkiszolgálót, majd ellenőrizze újra a futó verziót.
4. Ha ma nem tud frissíteni, különítse el a kiszolgálót a nyilvános hálózatoktól, amíg a javítás fel nem kerül és ellenőrzésre nem kerül. A CERT-EU egyértelműen kimondja, hogy ezeket a hibákat csak a frissítés hárítja el teljesen.
5. Ha PHP 8.1-et vagy régebbit használ, kérje el a szállítójától a visszaportolt javítást, vagy térjen át egy támogatott ágra. Ezek a verziók nem kapnak rendszeres frissítést.

Kerülőmegoldások, amelyek csökkentik a kockázatot, de nem javítják a hibát

A CERT-EU olyan intézkedéseket sorol fel, amelyek megnehezítik a támadást. Egyértelműen kimondja, hogy ezek nem teszik biztonságossá a telepítést. Használja őket a frissítés előkészítése alatt, ne a frissítés helyett.

• A CVE-2026-109618 ellen: állítsa be a memory_limit=-1 értéket úgy, hogy az alkalmazások ne írhassák felül, például a php_admin_value segítségével az FPM-készletben, és ellenőrizze, hogy egyetlen készlet, könyvtár vagy alkalmazásbejegyzés sem állít be újra véges korlátot. Állítson be alacsony post_max_size értéket (8M feltöltés nélkül, 32M feltöltéssel), és tartsa az upload_max_filesize értékét ez alatt. Korlátozza a kérés méretét, a mezők számát, a multipart részek számát, a fejlécek számát és a beágyazási mélységet a webkiszolgálón vagy a proxyn. A konténer vagy a cgroup memóriakorlátját rendelkezésre állási határként használja, de ne az RLIMIT_AS vagy RLIMIT_DATA értéket, mert ezek kiválthatják a sebezhető foglalási hibát.
• A CVE-2026-109619 ellen: állítsa be a session.upload_progress.enabled=0 értéket a php.ini fájlban, az FPM-készletben vagy olyan kiszolgálóbeállításban, amely a kérés feldolgozása előtt érvényesül (nem ini_set() vagy .user.ini segítségével), és indítsa újra az összes munkafolyamatot. PHP 8.5-ön állítsa be a fatal_error_backtraces=0 értéket is. Távolítsa el az érvénytelen vagy elavult, kérésenkénti beállításokat, amelyek az inicializálás előtt diagnosztikát írnak ki, és javítsa a támadó által elérhető végzetes hibákat és végrehajtási időtúllépéseket.

Mit tehet itt a SilentShield, és mit nem

Ez nem botprobléma, és inkább kimondjuk, mintsem hagyjuk, hogy egy termékoldal mást sugalljon. A támadás a PHP-motort éri, mielőtt a kérést bármi a mi megoldásunkból, vagy bármilyen CAPTCHA, bővítmény vagy tűzfalszabály az alkalmazásán belül látná. Az űrlapon lévő botvédelem ezt nem állítja meg, és senki ne mondja Önnek, hogy megállítja. Az egyetlen teljes megoldás a PHP frissítése.

A SilentShield API-ja és irányítópultja nem PHP-ban készült. A WordPress-bővítmény és a PHP SDK az Ön saját PHP-jén belül fut, ezért ezeknél a frissítést az Ön kiszolgálóján kell elvégezni. A frissítés után a szokásos védelem a botok és az űrlapspam ellen ugyanolyan hasznos, mint korábban; csak ez sosem volt a válasz erre.

Források

• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• A PHP közleménye, 2026. október 20.
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: a PHP-t beágyazó termékek