Több kutató és több AI-eszköz állítja, hogy ugyanazokat a PHP-motor kritikus memóriabontási hibákat találta meg, amelyeket közösen PHP2Shell néven azonosítottak és a CVE-2026-109618 és CVE-2026-109619 jelöléssel láttak el. A nyilvános kommunikáció szerint az előkészítés és a javítás koordinációja körülbelül két hónapot vett igénybe, a nyilvánosságra hozatal 2026. október 20–21. körüli híradásokhoz kapcsolódik, így a felfedezések belső munkái nagyjából 2026 augusztusában kezdődtek.
Kik és milyen eszközökkel dolgoztak?
- OpenAI közölte, hogy a Daybreak hozzáférés és a „Patch the Planet” kezdeményezés keretében a Calif nevű biztonsági cég kutatója GPT-5.6 Sol modell használatával talált hibákat. OpenAI azt is közölte, hogy a munkába a PHP Foundation, karbantartók, további kutatók és kormányzati szervek is bevonódtak.
- Független jelentések szerint a Wiz (amelyet nemrég integráltak a Google Cloud-ba) szintén megtalálta ugyanazokat a hibákat, és a Wiz által hivatkozott felfedezéshez Gemini 4 Argon modellt, valamint saját eszközöket (Wiz Atlas) használták.
Fontos: ez egy többoldalú felfedezési történet, nem bizonyítéka annak, hogy egyetlen szereplő egyedül fedezte fel és javította a hibát.
Mit találtak a kutatók?
A hibák a nyilvános technikai ismertetők szerint a PHP belső hiba- és memóriakezelésében, azon belül szokatlanul kezelendő "out-of-memory" körülményekben és fatális hibák feldolgozásában gyökereznek — tehát maga a PHP-motor belsejében vannak, nem egyszerű alkalmazás- vagy bővítményhiba. A kutatók demonstráltak:
- előhitelesítés nélküli (pre-auth) távoli kódfuttatást (RCE) több népszerű CMS-en, köztük WordPress, Drupal és Joomla rendszereken; és
- „Heartbleed-stílusú” memóriakiszivárgást, amely általánosabb információszivárgást okozhat minden PHP-alkalmazásnál.
Ezek a demonstrációk kutatói eredmények; nem szabad automatikusan úgy értelmezni, hogy minden egyes PHP telepítésen azonos, azonnal kihasználható RCE-útvonal létezik.
Koordináció, ütemezés és előzetes védekezés
- OpenAI és résztvevők arról számoltak be, hogy a felfedezés és a védekezési terv kidolgozása körülbelül két hónapig tartott, beleértve javításfejlesztést, detektálók építését és egyeztetést kormányzati szereplőkkel. A résztvevő kutatók szerint a PHP Foundation is aktívan segített a patch támogatásában és megerősítésében.
- Cloudflare a javítás megjelenése előtt WAF-szabályokat telepített, amelyek a vállalat szerint a ismert vektorok egy részét lefedték; ezek a szabályok minden ügyfél számára elérhetővé váltak, beleértve az ingyenes csomagot is. A Cloudflare CTO ugyanakkor hangsúlyozta, hogy ezek ideiglenes megoldások (stopgap), és az üzemeltetőknek a patch alkalmazását javasolta 14:00 UTC időpontra.
- Az NSA publikus üzenetében sürgette az frissítések előkészítését, és azt javasolta, hogy ha az időben történő javítás nem lehetséges, akkor az érintett rendszereket ideiglenesen vegyék le a hálózatról.
Kronológia – összefoglaló lépések
- Privát felfedezés és két hónapos koordináció a kutatók, a PHP-ökoszisztéma és kormányzati szereplők között (kb. augusztus 2026–október 2026).
- Nyilvános figyelmeztetések és időablak: posztok japán nyelven operátorokat készítettek fel egy október 21. 23:00 JST / 14:00 UTC körüli kiadásra.
- Előzetes forgalom- és WAF-mitigációk telepítése; Cloudflare "korai támadásokról" számolt be, de a közzétett anyag nem részletezi sikeres kompromisszumok számát vagy kiterjedését.
- Kutatói technikai nyilvános közzététel, kormányzati figyelmeztetések és a javítás elérhetővé tétele; a nyilvánosan elérhető, hiteles PHP Foundation–advisory részletek a felsorolt anyagban nem jelennek meg, így pontos "frissíts X verzióra" utasítás nem rekonstruálható a rendelkezésre álló anyagból.
- Később megjelent állítások a részletek esetleges idő előtti kiszivárgásáról és érintett szerverek nagy számára; egy vírusvideó-összeállításban említették körülbelül 1,5 millió szervert Censys-adatként, valamint több szolgáltatás és intézmény részleges leállását. A rendelkezésre álló anyagok nem igazolják egyértelműen ezeket az egyedi állításokat vagy azt, hogy a megszakítások kompromisszumok vagy óvintézkedések voltak.
Az AI szerepe és a hitel megoszlása
- OpenAI és Calif azt állítják, hogy GPT-5.6 Sol segített a hibák megtalálásában; Wiz és Google Cloud oldaláról a Wiz beszámolója Gemini 4 Argon modellt és saját eszközöket említ. A felfedezés így több szereplő, modellek és emberi kutatók közös munkájának eredményének tűnik.
- OpenAI a történetet a „Defender’s Window” példájaként kommentálta: fejlett modellek képesek lehetnek felfedezni hibát a támadók előtt, így időt adva a védelemre — de vállaltan "to our knowledge" (tudomásuk szerint) megfogalmazást használnak, ami nem bizonyíték arra, hogy korábban senki sem tudott a hibákról.
- Google/Wiz által közzétett promóciós számok arról, hogy Gemini 4 Argon „több mint kétszer annyi sebezhetőséget” talált, nem tárják fel az összehasonlítás részleteit (adatkészlet, baseline modellek, költségvetés, hamis pozitív arányok), így ezek sem tekinthetők független összehasonlításnak.
Műveleti kérdések és kockázatok a javításnál
- A javítás és elosztás nehézségei elsősorban a tulajdonlás és a deploy-terjedelem problémáiból adódnak: PHP számos környezetben fut (managed hosting, konténerek, appliances, háttérfeladatok, régi alkalmazások), az érintett futtatók felkutatása és frissítése idő- és erőforrás-igényes.
- A WAF-szabályok csökkentik az azonnali expozíciót, de hamis biztonságérzetet is kelthetnek, ezért a proxyzott lefedettség, alternatív bejáratok és az eredeti szerver ellenőrzése szükséges.
- Az „automatikus RCE-vel minden szerver patchelése” javaslat jogi és operációs kockázatokat rejt (nem autorizált hozzáférés, szolgáltatáskimaradások, rossz javítások, bizonyítékok megsemmisülése), ezért az ilyen ötletek nem helyettesítik a hiteles, aláírt kiadványokat és ellenőrzött frissítési folyamatokat.
Nyilvános reakciók: óvatosság és túlzás elkerülése
A nyilvános beszélgetés két irány mentén bontakozott ki: egy rész az óvintézkedések sürgősségét hangsúlyozta (például mentések, ideiglenes lekapcsolás, előkészületek), míg mások a túlzó pánikkeltés ellen érveltek, kérve a konkrét bizonyítékokat (pontosan mely verziók érintettek, mennyi sikeres kompromisszum történt, milyen rendszerek álltak le és miért).
Mi hiányzik a teljes bizonyításhoz?
A rendelkezésre álló, összevont közösségi és vállalati bejegyzések több információt tartalmaznak, mint egyetlen forrás, de hiányzik az a primer, hivatalos PHP Foundation–advisory és a disztribúciók, csomagazonosítók precíz listája, amelyek alapján egységes "frissíts erre a verzióra" utasítást lehetne adni. További nyitott kérdések: pontos érintett/fix verziók, CVSS vektorok, telepítési feltételek, független felfedezési idővonal, mi szivárgott ki a megjelenés előtt, sikeres kihasználások száma, valódi expozíciós mérőszámok és a jelentett leállások okai.
Összegzés
PHP2Shell néven ismertté vált két kritikus PHP-motor hiba kutatói demonstrációi súlyos potenciális következményekre mutattak rá — előhitelesítés nélküli RCE és memória-kiszivárgás —, ugyanakkor a történet fő tanulsága a ritka mértékű, több hónapos, több szereplős koordináció. Az esemény jól példázza, hogy a kritikus infrastruktúrákat futtató szoftverek jelenleg valószínűleg a valaha volt legintenzívebb biztonsági audit alatt állnak: a felfedezések gyakoriak lesznek, de helyes reakció nem a hírnök hibáztatása, hanem a rendszerek gyors, hitelesített javítása és az expozíciók pontos feltérképezése.
Rövid megjegyzések a forrásokról
A cikk forrásai között szerepelnek kutatói bejegyzések és vállalati közlemények (OpenAI, Cloudflare, NSA), valamint különféle közösségi és elemző gyűjtemények, amelyek együttesen alkotják a nyilvános eseményképet. A rendelkezésre álló anyagok egy részéből nem vonható le független, teljes körű auditált idővonal vagy minden egyes állítás hitelesítése.
