01 / PHP2SHELL

Először is: mi az a PHP, és miért érint ennyi weboldalt?

Amikor megnyitunk egy weboldalt, általában csak a kész felületet látjuk: képeket, szövegeket, termékeket, űrlapokat. A háttérben azonban egy program dolgozhat azon, hogy a megfelelő információ megjelenjen. Sok webhelyen ezt a munkát a PHP végzi.

A PHP-t használja például a WordPress is, amely blogoktól a vállalati honlapokon át a webáruházakig sokféle oldal alapja lehet. A lényeg: a PHP nem egy külön alkalmazás a látogató számítógépén, hanem jellemzően a weboldalt kiszolgáló szerveren fut.

Ezért a mostani ügy nem csupán egyetlen weboldalról vagy egy bizonyos WordPress-bővítményről szól. A probléma a háttérben működő technológia egyik alapvető részét érinti.

02 / PHP2SHELL

Mi történt? Egyszerűbben, technikai zsargon nélkül

Képzeljünk el egy irodát, ahol minden ügyfél érkezésekor elővesznek egy aktát, majd az ügyintézés végén eltárolják vagy megsemmisítik. A gond akkor kezdődik, ha az egyik ügyintéző később mégis egy már megsemmisített aktára hivatkozik, és a helyén időközben teljesen más adatok vannak.

A két PHP-hiba is a számítógép memóriájának kezelésével függ össze. A CVE-2026-109618 esetében a memória elfogyásakor megszakadó művelet után maradhat hibás állapot. A CVE-2026-109619 esetében egy korábbi webes kérésből visszamaradó hivatkozás mutathat már felszabadított memóriára. A pontos támadási lehetőség függ a PHP futtatási módjától, beállításaitól és az alkalmazástól. Bizonyos helyzetekben a rendszer olyan memóriaterületet használhat fel, amelyet már felszabadított, vagy hibásan kezelheti a korábban megkezdett műveletek maradványait. Egy támadó speciálisan összeállított webes kérésekkel megpróbálhatja ezt kihasználni.

A legsúlyosabb lehetséges következmény: a támadó saját kódot futtathat az érintett szerveren, akár anélkül is, hogy előtte bejelentkezne. Ez a biztonsági szaknyelvben távoli kódfuttatás, angol rövidítéssel RCE.

Fontos a pontosítás: ez nem azt jelenti, hogy minden PHP-alapú weboldalt automatikusan feltörtek. A sikeres támadáshoz sérülékeny verzió és megfelelő kihasználási feltételek szükségesek. A veszély ettől még valós és súlyos.

03 / PHP2SHELL

Mitől ennyire veszélyes?

Egy sikeres támadás következményei az adott szerver jogosultságaitól és a weboldal felépítésétől függenek. Elméletileg és bizonyított kihasználási forgatókönyvek alapján azonban többféle kár is bekövetkezhet:

• Adatokhoz való hozzáférés: a támadó olyan információkat érhet el, amelyekhez nem lenne jogosultsága.
• A weboldal tartalmának megváltoztatása: megjelenhet hamis információ, átirányítás vagy káros tartalom.
• Szolgáltatáskimaradás: az oldal lelassulhat vagy elérhetetlenné válhat.
• További támadások előkészítése: egy megszerzett szerverhozzáférés kiindulópont lehet más visszaélésekhez is.

A sérülékenységek CVSS v4.0 szerinti súlyossági pontszáma 9,2 a 10-ből. Két azonosítójuk: CVE-2026-109618 és CVE-2026-109619. Ezek a nemzetközi azonosítók abban segítenek, hogy a szakemberek pontosan ugyanarról a két hibáról beszéljenek.

04 / PHP2SHELL

És ebben hol jön a képbe a mesterséges intelligencia?

Ez az ügy azért kapott különösen nagy figyelmet, mert az AI nemcsak a hírek megírásában vagy az adatok összefoglalásában kapott szerepet. A hibák felfedezését és vizsgálatát is segítette.

Az OpenAI beszámolója szerint a Calif kutatói a GPT-5.6 Sol modellt használva tártak fel egy kritikus hibát, miközben a Wiz kutatói ettől függetlenül azonosították és jelentették mindkét sérülékenységet. A PHP fejlesztői, biztonsági kutatók és infrastruktúra-szolgáltatók ezt követően együtt dolgoztak a javításokon és a védekezés előkészítésén.

Érdemes tehát különválasztani a filmes forgatókönyvet a valóságtól. Nem arról van szó, hogy egy mesterséges intelligencia önállóan „feltörte az internetet”. Arról van szó, hogy a kutatók az AI segítségével olyan, mélyen rejtőző hibákat tudtak megtalálni és megérteni, amelyeknek a kézi feltárása rendkívül nehéz.

Ennek van egy kellemetlen tanulsága is: ugyanazok az AI-képességek, amelyek a védekezést gyorsítják, a támadók dolgát is megkönnyíthetik. A kérdés egyre inkább az, ki ismeri fel és javítja ki előbb a sebezhetőségeket. A Wiz beszámolója szerint a kutatásban a Wiz Atlas, a Gemini 4 Argon és a GPT-5.6 Sol is szerepet kapott. A modellek a kódelemzést, a tesztelést és a javítások ellenőrzését is támogatták; a munkát kutatók és a PHP karbantartói fogták össze.

05 / PHP2SHELL

Akkor minden WordPress-oldal veszélyben van?

Nem szükségszerűen. A WordPress olyan szervereken lehet érintett, ahol sérülékeny PHP fut. De nem maga a WordPress az elsődleges hibaforrás, és egy WordPress-bővítmény frissítése önmagában nem oldja meg ezt a problémát.

A WordPress fejlesztői külön közleményben kérték az üzemeltetőket a PHP frissítésére. A helyes megoldás általában a tárhelyszolgáltató vagy a szerverüzemeltető által biztosított javított PHP-verzió telepítése.

A 2026. október 21-én kiadott javított verziók:

A PHP 8.1 és régebbi kiadásai már nem kapnak közvetlen biztonsági támogatást a PHP projekttől. Bizonyos Linux-szállítók és hosszú távú támogatást nyújtó szolgáltatók külön javított csomagot adhatnak ki. Az üzemeltetőknek ezért nem csak a verziószámot, hanem a ténylegesen telepített biztonsági javítást is ellenőrizniük kell.

06 / PHP2SHELL

Mit tehet most egy weboldal tulajdonosa?

Nem pánikra, hanem gyors, ellenőrizhető intézkedésekre van szükség.

1. Nézesse meg a PHP-verziót. WordPress esetén ez az Eszközök → Webhely egészség → Információ → Szerver menüpontban megtalálható. Ha nem rendelkezik ilyen hozzáféréssel, kérdezze meg a tárhelyszolgáltatóját.

2. Kérjen igazolást a biztonsági javításról. Nem elegendő az a válasz, hogy „nálunk minden naprakész”. A pontos PHP-verzióra vagy a szolgáltató által kiadott javítócsomagra érdemes rákérdezni.

3. Készüljön mentéssel, majd frissítsen. A PHP frissítése előtt szükség van használható biztonsági mentésre, utána pedig ellenőrizni kell az űrlapokat, a bejelentkezést, a keresőt és az üzletileg fontos funkciókat. Az üzemeltető a PHP-folyamatok újraindítását is ellenőrizze, hogy valóban a javított kód fusson.

4. Használjon kiegészítő védelmet. Egy megfelelően beállított webalkalmazás-tűzfal, azaz WAF segíthet a támadási kísérletek szűrésében. A Cloudflare például már a nyilvános bejelentés előtt telepített védelmi szabályokat. A WAF azonban nem helyettesíti a PHP javítását.

5. Kérjen célzott biztonsági ellenőrzést. Ha a rendszer huzamosabb ideig sérülékeny verzión futott, érdemes átnézni a szervernaplókat, a fájlmódosításokat és a gyanús tevékenységeket. Az, hogy a weboldal látszólag hibátlanul működik, nem bizonyítja, hogy semmilyen támadási kísérlet nem történt.

07 / PHP2SHELL

És aki csak látogatója egy weboldalnak?

A legtöbb látogatónak nem kell a saját számítógépén PHP-t frissítenie, mert ez a technológia jellemzően a weboldalt kiszolgáló szerveren működik. A javítás elsődlegesen a weboldalak tulajdonosainak és üzemeltetőinek feladata.

Ha azonban egy megszokott oldalon váratlan átirányítást, furcsa bejelentkezési kérést vagy szokatlan tartalmat tapasztal, legyen óvatos, és ne adjon meg érzékeny adatokat addig, amíg nem tisztázott a helyzet.

08 / PHP2SHELL

A történet igazi tanulsága

A PHP2Shell nem azt bizonyítja, hogy az internet egyik napról a másikra használhatatlanná vált. Inkább azt mutatja meg, hogy egy széles körben használt technológia mélyén is lapulhatnak olyan hibák, amelyek éveken át észrevétlenek maradnak.

A mesterséges intelligencia most a védekező oldalon segített felgyorsítani a felismerést. Az üzemeltetők számára viszont a tanulság nagyon is hagyományos: az informatikai biztonság nem egyszeri beruházás, hanem folyamatos karbantartás, ellenőrzés és felelős működtetés.

A weboldal attól még nem biztonságos, hogy szépen betölt. A valódi biztonság a háttérben kezdődik.

Felhasznált szakmai források

• PHP: CVE-2026-109618, memóriahiány utáni hibás állapot
• PHP: CVE-2026-109619, elavult globális állapot
• WordPress: Critical PHP Security Release, 2026. október 21.
• Wiz Research: PHP2Shell, AI által támogatott kutatás
• OpenAI: Patch the Planet, 2026. október 21.
• Cloudflare: PHP2Shell elleni WAF-védelem
• NHS England: Critical Vulnerabilities in PHP