PHP Radar HU EN
RIASZTÁS · 2026. OKTÓBER 21. · CVSS 9,2 · HITELESÍTÉS NÉLKÜLI TÁVOLI KÓDFUTTATÁS

PHP ARMAGEDDON

A webet működtető nyelvben két kritikus hiba nyílt. A támadónak nem kell jelszó és nem kell belépés ahhoz, hogy a szerveren kódot futtasson. Ez nem pánikkeltés: a PHP Alapítvány szava szerint most „azonnal frissíteni kell”.

69,3%a webhelyek ennyi része fut PHP-n (W3Techs, a Tenable idézi)
2 CVECVE-2026-109618 és CVE-2026-109619, mindkettő kritikus
9,2CVSS v4.0 súlyosság (a PHP biztonsági csapat szerint)
0 jelszóhitelesítés nélkül, távolról kihasználható (php.net advisory)

A kutatók szerint javítatlan PHP-n a nagy rendszerek is érintettek: WordPress, Drupal, Joomla, Magento, Laravel, Symfony, phpMyAdmin, Nextcloud, Roundcube, MediaWiki, WHMCS. Nem a rendszer hibája – a PHP-é alattuk.

Csak domainnév: betűk, számok, kötőjel, pont. Ékezetes (IDN) név is mehet.

Ingyenes, passzív vizsgálat: csak azt olvassuk, amit a szervered hitelesítés nélkül bárkinek kiszolgál (válaszfejlécek, főoldal). Nincs behatolás, nincs útvonal-találgatás, nincs semmilyen kihasználási kísérlet.

Mi történt 2026. október 20–21-én?

Ez nem egy újabb „frissítsd a WordPresst” hír. Maga a PHP futtatókörnyezet sérült, így minden PHP-alkalmazás érintett, a legegyszerűbb oldaltól a webshopig. A PHP Alapítvány a közleményében „imperative”-nek, kötelezőnek nevezi a frissítést.

  1. A Calif (Ryan Austin) és az OpenAI – egymástól függetlenül, ugyanazon a napon – bejelenti a PHP biztonsági csapatának az első hibát. Augusztus 24-én a Wiz, szeptember 18-án az OpenAI további érintett eseteket jelez.

    → PHP Foundation – a kiadás és a megerősítés háttere

  2. A CVE-azonosítók idő előtt kiszivárognak a Hacker Newsra és a közösségi médiába – hibás, 10,0-s CVSS-pontszámmal és rossz kiadási idővel. Technikai részlet ekkor még nem.

    → PHP Foundation – a kiadás és a megerősítés háttere

  3. A php.announce listán Jakub Zelenka közzéteszi az előzetest: „Upcoming Critical PHP Security Release” – két kritikus (CVSS v4.0 9,2) hiba, kiadás október 21-én 14:00 UTC-kor. Az eredeti dátum október 22. volt; a szivárgás miatt hozták előre.

    → php.net – előzetes bejelentés (php.announce #509)

  4. A Patchstack tárhely-partnerei az első gyanús forgalmat jelzik; a Cloudflare technológiai vezetője korai próbálkozásokról ír, és WAF-szabályokat ad ki minden ügyfélnek, az ingyenes csomagban is – de hangsúlyozza: ez csak átmeneti mankó, nem helyettesíti a frissítést.

    → Patchstack – élő helyzetkép és WordPress-tanácsok

  5. Megjelenik a PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35. A php.net advisory: „All PHP users are strongly encouraged to update immediately.” A már lejárt PHP 7.4, 8.0 és 8.1 ágakhoz csak minimális forrás-backport készül.

    → php.net – hivatalos biztonsági advisory (2026-10-21)

  6. A CERT-EU kiadja a 2026-018 riasztást (azonnali frissítés, vagy az internet felől elérhető rendszerek elkülönítése). Az NBSZ Nemzeti Kibervédelmi Intézet magyar nyelvű riasztást ad: „haladéktalanul frissítsenek”. Megelőzésből holland kormányzati szolgáltatások (DigiD, MijnOverheid) is átmenetileg lekapcsolnak.

    → NBSZ Nemzeti Kibervédelmi Intézet – magyar riasztás

  7. A watchTowr és a Huntress még nem erősít meg tömeges, sikeres kihasználást; a Rapid7 szerint működő nyilvános exploit „hamarosan” várható. A kutatók szerint a vizsgálat során működő kódfuttatás készült mind a mod_php, mind a PHP-FPM környezetben.

    → Rapid7 – elemzés és enyhítés

Mi ez a két hiba? – közérthetően

Nem adunk kihasználási receptet, és nem is kell. Elég annyit érteni, melyik két szélső helyzetet rontotta el a PHP, hogy lásd, miért nem véd meg önmagában a tűzfal vagy a jelszó. A támadó a te alkalmazásodon keresztül éri el a PHP-t, de a hiba a PHP-ben van.

CVSS v4.0 9,2 · kritikus

CVE-2026-109618 – memóriakezelési hiba (OOM)

Amikor a PHP-ből kifogy a memória egy kérés feldolgozása közben, félig kész belső adatszerkezet maradhat vissza. A kérés lezárásakor a PHP ezt érvényesnek veszi, és a megromlott memóriaállapotból a támadó a szerveren kódfuttatásig juthat. A PHP a mod_php (Apache-modul) esetét tartja a legveszélyesebbnek, mert ott mindez még az alkalmazás kódja előtt lejátszódhat.

→ GitHub Advisory – CVE-2026-109618 (GHSA-w8hw-w9fx-j79w)
CVSS v4.0 9,2 · kritikus

CVE-2026-109619 – bennragadt állapot (use-after-free)

A PHP-ben van olyan belső állapot (hiba-, munkamenet-, objektumadat), ami egy kérésé, de a feldolgozó folyamat megtartja. Ha ezt nem törlik időben, a következő, ugyanazon a munkafolyamaton futó kérés már felszabadított memóriára hivatkozhat. Ez memóriaszivárgáshoz (jelszavak, tokenek, kulcsok kiolvasásához) és kódfuttatáshoz vezethet.

→ GitHub Advisory – CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp)

A hibákat a Calif, az OpenAI és a Wiz jelentette; a kutatás összefoglaló neve „php2shell”. A Wiz emellett megmutatta, hogy kódfuttatás nélkül is ki lehet olvasni a PHP-folyamat memóriáját – ezért javasolt a szerveren tárolt jelszavak és kulcsok cseréje is, ha javítatlan verzió futott.

Verziónkénti helyzet – mi kapott javítást 2026. október 21-én?

A táblázat a PHP hivatalos adatai alapján készült (php.net/supported-versions, php.net/eol és a 2026-10-21-i advisory). A dátumok UTC szerintiek. Nem találgatunk: amelyik ág lejárt, oda nem jött hivatalos kiadás.

ÁgJavított kiadás (2026-10-21)Korábbi kiadásBiztonsági támogatás végeÁllapot
8.58.5.128.5.11 (2026-09-24)2029-12-31 Aktív ág. Frissíts 8.5.12-re.
8.48.4.278.4.26 (2026-09-24)2028-12-31 Aktív ág. Frissíts 8.4.27-re.
8.38.3.368.3.35 (2026-09-24)2027-12-31 Már csak biztonsági javításokat kap. Frissíts 8.3.36-ra.
8.28.2.358.2.34 (2026-09-24)2026-12-31 Megkapta a javítást (8.2.35), DE az ág 2026. december 31-én lejár. Tervezd a 8.3+ váltást.
8.1— (nincs hivatalos kiadás)8.1.34 (2025-12-18)2025-12-31 (lejárt) Lejárt. Csak minimális forrás-backport készült (saját fordítás). Váltás kell.
8.0— (nincs hivatalos kiadás)8.0.30 (2023-08-03)2023-11-26 (lejárt) Lejárt. Csak forrás-backport létezik. Sürgős váltás.
7.4— (nincs hivatalos kiadás)7.4.33 (2022-11-03)2022-11-28 (lejárt) Lejárt. Csak forrás-backport létezik. Sürgős váltás, kompatibilitás-vizsgálattal.
7.3 és régebbi— (nincs javítás)—rég lejárt Semmilyen javítás nincs, backport sincs. Cserélni kell.

A PHP 8.6-ot 2026. november 19-re tervezik (php.net wiki); ez a radar csak a mai, hivatalosan kiadott ágakról mond ítéletet, a jövőbeli verziókról nem találgat.

A PHP biztonsági csapata a 7.4, 8.0 és 8.1 ágakhoz minimális forrás-backportot adott ki (php.net advisory). Ez nem hivatalos kiadás: forrásból kell fordítani. Megbízható út a frissítés helyett a támogatott ágra váltás.

FIGYELEM – a verzióváltás önmagában összetörheti az oldaladat

Ez a legfontosabb mondat ezen az oldalon, ezért keretezzük be:

A PHP-verzió emelése egy dolog. De ha a weboldaladon futó kód (téma, bővítmény, egyedi fejlesztés) nem PHP 8.x-kompatibilis, akkor a frissítés pillanatában az oldal ÖSSZEOMLIK: fehér képernyő, 500-as hiba, elérhetetlen admin, néha adatvesztés.

A régi kód (sok PHP 5.x / 7.x kori téma és bővítmény) olyan nyelvi elemekre épül, amiket a PHP 8 eltávolított vagy megszigorított. Ami 7.4-en „figyelmeztetés” volt, az 8.x-en végzetes hiba.

Egy elhagyott, évek óta nem frissített bővítmény a leggyakoribb robbanópont. A frissítés előtt fel kell mérni mindet.

Ezért a helyes sorrend: 1) biztonsági mentés, 2) másolat (staging) készítése, 3) a kód kompatibilitás-vizsgálata, 4) a hibák javítása a másolaton, 5) csak ezután az éles verzióváltás. Élesben, vakon frissíteni felelőtlenség.

Ne bízd a szerencsére. Egy rossz kattintás a frissítés gombra, és napokig állhat az oldal. Bízd szakemberre.

Szakértést kérek →

Mit tegyél MOST? – gyakorlati sorrend

  1. 1

    Derítsd ki, milyen PHP-verzió fut

    Használd a fenti radart, vagy nézd meg a tárhely-panelben. A pontos javítószint (pl. 8.3.36) a lényeg, nem csak az ág.

  2. 2

    Készíts teljes mentést

    Fájlok és adatbázis együtt, még a frissítés ELŐTT. Ha valami elromlik, ez a visszaút.

  3. 3

    Frissíts a javított kiadásra

    A saját ágad javított kiadására (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35). Lejárt ágon: váltás támogatott ágra.

  4. 4

    Előbb másolaton (staging) próbáld

    Nézd meg, hogy a téma, a bővítmények és az egyedi kód elviselik-e az új PHP-t. Csak működő másolat után élesíts.

  5. 5

    Cseréld a titkokat

    Ha javítatlan verzió futott, a memória kiolvasható volt. Jelszó, API-kulcs, munkamenet – mindet cseréld.

  6. 6

    Ha nem tudod megoldani időt vesztve

    Ideiglenes mankók léteznek (a php.net ezeket felsorolja), de egyik sem teljes védelem. A biztos megoldás a frissítés – ha kell, szakértővel.

Átmeneti enyhítés, ha most nem tudsz frissíteni (a php.net szerint – NEM teljes védelem):
  • CVE-2026-109618 ellen: memory_limit=-1 úgy beállítva, hogy az alkalmazás ne írhassa felül (pl. php_admin_value az FPM-poolban vagy az Apache-konfigban); a post_max_size legyen alacsony (8M feltöltés nélkül, 32M feltöltéssel).
  • CVE-2026-109619 ellen: session.upload_progress.enabled=0 a php.ini-ben / FPM-poolban (NEM ini_set() vagy .user.ini), majd minden munkafolyamat újraindítása; PHP 8.5-ön ráadásul fatal_error_backtraces=0.
  • A hibák elrejtése (error_reporting, display_errors, @) NEM véd. Konténer/cgroup memórialimit segíthet elérhetőségi korlátként, de nem teljes megoldás; RLIMIT_AS / RLIMIT_DATA viszont kifejezetten kerülendő.

A tesztet Vidovics Gábor végzi

Biztonsági incidens szakértő · weboldal-biztonság (WordPress / PHP) · senior full-stack fejlesztő

Közel harminc éve dolgozom informatikával, több mint húsz évet fejlesztőként és műszaki vezetőként. Ma feltört, lelassult vagy gyanúsan viselkedő weboldalak kivizsgálásával és helyreállításával foglalkozom, és azzal, hogy a rendbe tett oldalakon utána se történjen baj.

Mérek, nem tippelek; karanténozok, nem törlök – az adataid a vizsgálat alatt is megmaradnak, minden lépés visszafordítható. Nem ígérek százszázalékos védelmet: azt tudom megmondani, aki bejut, meddig jut el, és ezt a távolságot meg tudom növelni.

A natív PHP-től a nagy keretrendszerekig sokféle kódon dolgoztam, ezért a PHP-verzióváltásban, és az „ehhez már senki nem mer hozzányúlni” oldalakban is van gyakorlatom. A verzióemelés előtti kompatibilitás-vizsgálat és a biztonságos élesítés nálam egy folyamat része.

  • 21 dokumentált, anonimizált incidenseset
  • Egy ügyben 164 457 átvizsgált naplósor
  • 0 törölt fájl – minden karanténba, bizonyítékmegőrzéssel
  • Saját eszközök: DomainCheck, domain-analizátor, incidens-elemző
Elérhetőség
Telefon
+36 30 9688 854
Helyszín
Szentes, Magyarország · távmunka / hibrid
LinkedIn
linkedin.com/in/vidovicsgabor

A jelentkezést az alábbi űrlapon keresztül fogadom. Akut helyzetben (a Google jelzett, a tárhely szólt, vagy valami furcsát látsz az oldalon) az üzenetbe írd oda: SÜRGŐS.

Szakértést kérek a verzióváltáshoz

A radar ingyenes. Ha a weboldalad sérülékeny verzión van, vagy nem derül ki kívülről, és nem akarod a szerencsére bízni a frissítést, írj – munkanapokon válaszolok, akut esetben soron kívül.

Biztonsági kód (CAPTCHA kép)

Saját, külső szolgáltatás nélküli ellenőrzés – nincs Google, nincs süti.

Az adataidat kizárólag a megkeresésed megválaszolására használom. Az üzenet hitelesített SMTP-vel, titkosított csatornán megy ki.

Gyors tények

A legfontosabb, önállóan is idézhető tények a 2026. október 21-i PHP-biztonsági kiadásról.

  • A két kritikus PHP-hiba azonosítója CVE-2026-109618 és CVE-2026-109619, mindkettő CVSS v4.0 9,2 (kritikus).
  • A javítás 2026. október 21-én jelent meg: PHP 8.5.12, 8.4.27, 8.3.36 és 8.2.35.
  • A hibák hitelesítés nélkül, távolról kihasználhatók, és minden webet kiszolgáló PHP-telepítést érintenek (mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed).
  • A PHP 8.1 és régebbi ágakhoz nincs hivatalos javítás, csak minimális forrás-backport – támogatott ágra kell váltani.
  • A PHP-verzió emelése önmagában nem elég biztonságos: ha a kód nem PHP 8.x-kompatibilis, az oldal összeomolhat, ezért előbb mentés, másolat és kompatibilitás-vizsgálat kell.
  • Az ingyenes PHP Radar (dinorr.hu/php-radar) megmutatja, milyen PHP-verzió látszik egy domainen, és a verziószám alapján érintett-e.
  • A tesztet Vidovics Gábor biztonsági incidens szakértő végzi; a radar ingyenes, az első válasz díjmentes.

Gyakori kérdések

Pontosan mit csinál ez a radar?

Megnézi, milyen PHP-verzióra utaló jelet ad ki a szervered kívülről (HTTP-válaszfejlécek, a főoldal tartalma), és a php.net hivatalos adatai alapján besorolja: javított, sérülékeny, lejárt ág vagy rejtett. Passzív vizsgálat: semmit nem próbál kihasználni, útvonalat nem találgat, csak a nyilvánosan kiszolgált választ olvassa.

Megbízható az eredmény?

Amit a szerver kiír, azt mérjük. Sok szerver biztonságból elrejti a verziót (ez helyes), vagy a disztribúció a verziószám emelése nélkül javít – ilyenkor kívülről nem lehet biztosat mondani, és ezt a radar őszintén jelzi is. A pontos állapot a szerveren belül, egyetlen paranccsal derül ki.

Ingyenes? Mi a csúnya trükk?

A radar tényleg ingyenes, és nincs trükk. A szakértői verzióváltás (felmérés, staging, kompatibilitás-javítás, biztonságos élesítés) a fizetős szolgáltatás – de csak akkor, ha kéred.

Elég csak a PHP-t frissíteni?

A biztonsági hiba ellen igen, az a teljes megoldás. DE ha a kódod nem PHP 8.x-kompatibilis, a frissítés összetörheti az oldalt. Ezért kell előbb mentés, másolat és kompatibilitás-vizsgálat.

A tárhelyem azt mondja, ő „kezeli”. Akkor nyugodt lehetek?

Sok tárhely tényleg frissít vagy visszaportol – de ezt érdemes leellenőrizni, nem feltételezni. A radar „rejtett” vagy „disztribúciós” eredménye épp ezt jelzi: kívülről nem látszik, belülről kell megnézni.

Mi az a CVE-2026-109618 és 109619?

A két hiba hivatalos azonosítója. Mindkettő kritikus (CVSS v4.0 9,2), hitelesítés nélkül, távolról kihasználható, és a PHP 2026. október 21-i biztonsági kiadása javítja. Részletek a GitHub tanácsadókban és a php.net advisoryban – lásd a Források szekciót.

Források

Minden állítás ezeken a nyilvános, hivatkozható forrásokon alapul. Ez az oldal tájékoztató; a mérvadó mindig a php.net hivatalos közleménye.