# PHP2Shell: két kritikus PHP hiba, egy kiszivárgott embargó és ami valójában ismert a kihasználásról Published: 2026-10-22 A PHP sürgősségi javításokat adott ki két kritikus, távoli kódfuttatási hibára, a CVE-2026-109618 és a CVE-2026-109619 jelzésű, úgynevezett PHP2Shell hibákra. A kiadás 2026. október 21-én történt. Az epizód közérthetően elmagyarázza a két memóriahibát, miért várt a javításra egy 2024-es auditból származó nyom, hogyan szivárgott ki az embargó, és mely források mit mondanak a kihasználásról. Kiterjed a GitLab aznapi kritikus javítócsomagjára és egy 25 milliárd dolláros Meta bírságra Új-Mexikóban. Canonical: https://thedailydiff.dev/hu/video/2026-10-22-php2shell/ ## Amit ez a videó tartalmaz - Mindkét hibát 9.2-es CVSS v4.0 értékeléssel látta el a PHP csapat. A javított kiadások a PHP 8.2.35, 8.3.36, 8.4.27 és 8.5.12; a PHP 7.4, 8.0 és 8.1 csak forráskód-javításokat kapott. A PHP szerint a frissítés az egyetlen teljes körű enyhítés. - Az első hiba abból adódik, hogy a PHP félig elkészült állapotban hagy egy kérést, amikor rossz pillanatban kifogy a memóriából. A második hiba egy megmaradt mutatóból adódik, amely egy korábbi kérés memóriájára mutat, és amelyet ugyanabban a munkafolyamatban egy későbbi kérés felhasználhat. Apache mod\_php esetén az első útvonal az alkalmazás kódja előtt fut. - Egy PHP alapfejlesztő 2024-es audit során találta meg a memóriaprobléma első jeleit. A PHP Alapítvány szerint a versengő javítások kompromisszumokkal jártak, és a konszenzuson alapuló biztonsági csapat nehezen tudott választani, amit strukturális hibának nevez. - Az Alapítvány szerint a CVE azonosítók október 20-án kiszivárogtak, a Calif tévedésből közzétett egy proof-of-concept videót, és a Chainguard több mint hat órával a kiadás előtt közzétette a javítást tartalmazó összeállított képeket. A Chainguard vezérigazgatója szerint az embereket már érintették, és ő maga is függetlenül találta meg a hibákat. - A források eltérően vélekednek a kihasználásról. Az Amazon október 17-én naplózott egy kísérletet, majd később azt mondta, hogy a PHP2Shell széles körben kihasznált. A watchTowr jelentett kihasználást "in the wild" (a való életben). A CISA a közzétételkor nem észlelt kihasználást, és a PHP csapat a kiadáskor nem talált működő exploitot. Sok nyilvános proof-of-concept szkriptről számoltak be, hogy nem működnek. - Ellenőrizze az összes helyet, ahol a PHP fut, beleértve a más szoftverekben rejtőző másolatokat is, frissítsen, indítsa újra a munkafolyamatokat, és tekintse át a naplókat egészen október 17-ig. ## Kérdések és válaszok ### Mik a két PHP2Shell sebezhetőség? A PHP2Shell két kritikus PHP hibát nevez meg, a CVE-2026-109618 és CVE-2026-109619 azonosítójúakat, amelyeket a PHP csapat 9.2-re értékelt. Az első félig elkészült állapotban hagy egy kérést, amikor a PHP rossz pillanatban kifogy a memóriából, és a takarítási lépés ezután megbízik benne. A második egy mutatót hagy egy kérés memóriájára, amelyet ugyanabban a munkafolyamatban egy későbbi kérés felhasználhat. Mindkettő kódfuttatáshoz vezethet bejelentkezés nélkül. ### Mely PHP verziók kaptak javítást a PHP2Shell-hez, és mi a helyzet a nem támogatott verziókkal? A PHP projekt 2026. október 21-én adta ki a javításokat a 8.2.35, 8.3.36, 8.4.27 és 8.5.12 verziókban. A 7.4, 8.0 és 8.1 verziókhoz csak forráskód-javításokat tettek közzé, és a BleepingComputer jelentése szerint a disztribútorok és a hosszú távú támogatást nyújtó gyártók szállíthatnak visszafelé kompatibilis javításokat. A PHP szerint nincs teljes körű megoldás, így a frissítés vagy a gyártótól kért javított csomag az egyetlen biztonságos választás. ### Miért tartott 2026 októberéig egy ismert PHP memóriahiba kijavítása? A PHP Alapítvány szerint egy alapfejlesztő 2024-es biztonsági audit során találta meg a memóriaprobléma első jeleit, de nem volt ismert exploit útvonal, és minden jelölt javítás kompromisszumokkal járt, például kompatibilitási törésekkel. A biztonsági csapat konszenzussal dönt, és nehezen tudott választani, amit az Alapítvány strukturális hibának nevezett, amelyet a döntéshozatali folyamata és az erőforrások hiánya okozott. ### Kihasználják-e a PHP2Shell-t, és mennyire könnyű kihasználni? A források eltérően vélekednek. Az Amazon október 17-én naplózott egy kihasználási kísérletet, majd később azt mondta, hogy a PHP2Shell széles körben ki van használva, és a watchTowr jelentett kihasználást "in the wild" (a való életben). A CISA a közzétételkor nem észlelt kihasználást, és a PHP csapat a kiadáskor nem látott működő exploitot. A watchTowr szerint a legtöbb nyilvános exploit szkript összeomlik vagy nem csinál semmit, és a VulnCheck szerint a kódvégrehajtás csak bizonyos beállításokban működik. ### Mi volt a The Daily Diff ítélete a PHP2Shell-ről? A The Daily Diff ítélete SHIP IT volt: küldje el a PHP frissítést ma este, mert az új verzió az egyetlen teljes javítás. A CISA szerint fel kell mérni az összes PHP-t futtató rendszert, beleértve a más szoftverekben rejtőző másolatokat is, alkalmazni kell a javítást, és offline állapotba kell helyezni a PHP rendszereket, ha nem frissíthetők. Az Amazon azt tanácsolja, hogy tekintse át a naplókat egészen október 17-ig, amikor az első kísérletet látták. ## Fejezetek - 0:00 Ki próbálta ki a PHP2Shell-t négy nappal korábban? - 0:41 Mik a két PHP2Shell hiba? - 1:37 Miért várt egy ismert hiba két évet a javításra? - 1:54 Ki találta meg a PHP2Shell-t, és hogyan? - 2:20 Hogyan szivárgott ki a PHP2Shell embargó? - 2:50 Kihasználják-e a PHP2Shell-t, és kik? - 3:43 Mit kapcsoltak le a kormányok? - 4:11 Mely PHP verziók kapnak javítást? - 4:30 Mit tegyen ma este a PHP2Shell ellen? - 4:45 Mi más adott ki ma kritikus RCE javítást? - 5:01 Miért kapott a Meta 25 milliárd dolláros büntetést? - 5:18 Mi a Chainguard védelme a korai javításra? - 5:38 Mi kapja a SHIP IT pecsétet? ## Lefordított átirat Az eredeti angol narrációból fordítva. A rendelkezésre álló hangot és feliratokat a YouTube vezérli. ### Ki próbálta ki a PHP2Shell-t négy nappal korábban? 0:00 Egy biztonsági embargónak elvileg csendben kell tartania egy hibát, amíg a javítás meg nem jelenik. Az Amazon négy nappal korábban naplózott egy kísérletet a PHP kritikus hibája ellen. Ebben a videóban ki találta meg? Hogyan szivárgott ki az embargó? És valójában mennyire rossz a helyzet? És a kiszivárgásért felelős vállalatnak van egy olyan védekezése, amire nem számítottam. Rátérek. Csütörtök van, október huszonkettedike, és ez a The Daily Diff. 0:21 A PHP egy szkriptnyelv, amely webszájtoldalakat épít a szerveren, közvetlenül mielőtt elérnek önhöz. Több mint harminc éves, és az egyik becslés szerint a weboldalak mintegy hetven százalékát futtatja, beleértve a WordPress-t és a Wikipédia mögötti szoftvert. A fejlesztők szeretik kigúnyolni, általában egy olyan oldalról, amit a PHP szolgáltat nekik. Karbantartását egy nonprofit szervezet végzi, mintegy tizenhárom mérnökkel. ### Mik a két PHP2Shell hiba? 0:41 Szerdán a PHP sürgősségi javításokat adott ki két kritikus hibára, amelyek lehetővé teszik egy idegen számára, hogy bejelentkezés nélkül kódot futtasson egy szerveren. Ezeket együtt PHP2Shell-nek hívják, és egészen a PHP öt pont négyes verziójáig nyúlnak vissza. Íme az első hiba közérthetően. A PHP minden kérésnek ad egy memóriakeretet. Ha egy kérés pontosan rossz pillanatban éri el ezt a határt, a PHP sietve leáll, és félig elkészült állapotban hagyja a kérést. Ezután a takarítási lépés megbízik a félig elkészült dologban. 1:07 A második hiba egy maradék. Egy végzetes hiba hagyhat egy jegyzetet, ami az utolsó kéréshez tartozó memóriára mutat. Ugyanez a dolgozó kezeli a következő kérést, és követi a jegyzetet. Addigra már valaki más lakik azon a címen. Apache mod PHP-vel a kár azelőtt megtörténik, hogy a saját kódja futna, így a bejelentkezési oldala soha nem kap szavazati jogot. A Wiz szerint még egy hello world szkript is ki van téve a támadásnak. A javítás eltávolítja a PHP sürgősségi kilépési pontját a memóriahiány esetén. 1:32 A kérés közbeni leállás helyett a PHP most udvariasan leáll a következő biztonságos pontnál. A furcsa rész az, hogy milyen régi az első nyom. ### Miért várt egy ismert hiba két évet a javításra? 1:39 2024-ben egy külső biztonsági audit vezetett egy PHP alapfejlesztőt a memóriaprobléma első jeleihez. Nem volt ismert exploit, és minden javítás elrontott valamit. Egy konszenzussal döntő csapat nem tudott választani, így a hiba várt. Aztán augusztusban, napokon belül megérkeztek a felfedezők. ### Ki találta meg a PHP2Shell-t, és hogyan? 1:56 A Calif kutatója, Ryan Austin augusztus elsején találta meg, az OpenAI Patch the Planet programján keresztül dolgozva. Az OpenAI függetlenül jelentette ugyanazt a kiváltó okot. A Wiz néhány héttel később a Gemini és GPT modellekkel talált variánsokat. Austin szerint olyan modelleket használt, amelyek mindenki számára elérhetők, plusz egy elméletet arról, hogy hol rejtőznek a PHP régi hibái. Az OpenAI szerint a "frontier AI" volt a kulcs. A hiba több mint egy évtizedig rejtőzött. A kiadást csütörtökre tervezték. ### Hogyan szivárgott ki a PHP2Shell embargó? 2:21 Kedden a két CVE szám elkezdett terjedni online, rossz megjelenési idővel és téves tízes pontszámmal. A PHP egy nappal előrébb hozta a kiadást. Azon az estén a Calif véletlenül közzétette proof of concept videóját működés közben, és a másolatok túlélték a törlést. Szerda reggel, több mint hat órával a kiadás előtt, a Chainguard kiadta a javítást tartalmazó összeállított képeket. A PHP szerint bármely támadó tanulmányozhatta volna ezt a javítást, amíg mindenki más várt. 2:46 Egy patch egyben diff is, és a támadók olvassák a diffeket. ### Kihasználják-e a PHP2Shell-t, és kik? 2:50 Tehát kiket is érint valójában a támadás? Az Amazon honeypotja október tizenhetedikén naplózott egy kísérletet, majd később azt mondta, hogy a PHP2Shell széles körben ki van használva. A watchTowr jelentett kihasználást "in the wild" (a való életben). A Cisa szerint a közzétételkor nem észleltek ilyet, és a PHP csapata nem látott működő exploitot a kiadáskor. A Cloudflare vezérigazgatója szerint több ezer kísérletet láttak a bejelentés előtti tíz órában, és több milliót csütörtök reggelre. 3:13 Az Amazon egy ponton óvatos. Nem tudja, hogy a legkorábbi kísérletei működtek volna-e egy valódi rendszeren. Egy kísérlet csak egy kopogtatás az ajtón. Szóval mennyire rossz a helyzet valójában? A watchTowr szerint a nyilvánosan keringő exploitok többnyire összeomlanak vagy nem csinálnak semmit. A VulnCheck szerint a kódvégrehajtás bizonyos beállításokban működik, és a nyilvánosak közül egyik sem győzi le a memóriavéletlenszerűsítést a standard x86 szervereken. Elias Taylor kutató szerint közel sem olyan könnyű, mint a Log4Shell. 3:40 Mindenki továbbra is azt mondja, hogy javítani kell. A kormányok nem vártak az ítéletre. ### Mit kapcsoltak le a kormányok? 3:44 Az NSA azt mondta azoknak a szervezeteknek, amelyek nem tudtak javítani, hogy vegyék le a PHP rendszereket offline állapotba, és az Egyesült Királyság Nemzeti Kiberbiztonsági Központja hasonló tanácsot adott. Holland oldalak, beleértve a nemzeti digitális identitásszolgáltatást is, sötétségbe borultak, valamint egy párizsi rendőrségi oldal. A Wikimedia óvintézkedésként több rendszert is leállított. A Palo Alto Networks több mint huszonkét millió sebezhető példányt számolt össze. És egy ausztrál professzor tette a legélesebb megjegyzést. Azok az oldalak aggasztóak, amelyek ma nincsenek leállítva. ### Mely PHP verziók kapnak javítást? 4:11 Javítások léteznek a PHP nyolc pont kettő és nyolc pont ötös verzióihoz. A hét pont négyes, nyolc pont nullás és nyolc pont egyes verziókhoz a PHP csak forráskód-javításokat tett közzé. A régebbi verziók semmit sem kapnak a PHP projekttől, ezért kérdezze meg a disztribútorát. A kerülőutak csökkentik az esélyeket, de a PHP szerint a frissítés az egyetlen teljes javítás. Ez ugyanaz a lecke, mint a tegnapi eMudhra epizódban, ### Mit tegyen ma este a PHP2Shell ellen? 4:32 mert egy létező javítás nem ugyanaz, mint ha a futó folyamat rendelkezne vele. Keresse meg az összes PHP-t a veremben, még a más szoftverekben rejtőző másolatokat is. Frissítsen, indítsa újra a munkafolyamatokat, és ellenőrizze a naplókat egészen október tizenhetedikéig. Ugyanezen a napon a GitLab kiadott egy kritikus javítást, ### Mi más adott ki ma kritikus RCE javítást? 4:47 tizenkilenc pont öt pont egyest. Egy egész túlcsordulás a reguláris kifejezés fordítójában lehetővé teszi egy nem hitelesített felhasználó számára, hogy kódot futtasson a szerveren, és tízes pontszámot kapott. A GitLab.com már javítva van. Az önállóan kezelt telepítéseknek szükségük van a frissítésre. ### Miért kapott a Meta 25 milliárd dolláros büntetést? 5:01 Eközben Új-Mexikóban egy bíró elrendelte, hogy a Meta fizessen huszonöt milliárd dollárt büntetésként a Cambridge Analytica ügyében. Az esküdtszék több mint negyvenhárom millió jogsértést számolt, akár ötezer dolláros tételeket, ami körülbelül kétszázhúsz milliárd dollárt tett ki, mielőtt a bíró csökkentette. A Meta azt mondja, fellebbezésben nyer majd. Most az ígért védekezés. ### Mi a Chainguard védelme a korai javításra? 5:19 A Chainguard vezérigazgatója azt mondta a The Registernek, hogy ő maga is megtalálta ugyanazokat a hibákat egy péntek esten, miután megtudta, hogy valami jön a PHP-ban, egy alapvető felszólítással a rossz sebezhetőségek megtalálására. Azt mondja, azért adta ki korán, mert az embereket már támadták. Ha inkább olvasná ezt, mint hallaná tőlem, a "diff" minden reggel ingyen érkezik a postaládájába a thedailydiff.dev címen, link lent. Szóval a mai ítélet: SHIP IT. ### Mi kapja a SHIP IT pecsétet? 5:39 Adja ki a PHP frissítést ma este, mert az új verziószám az egyetlen teljes javítás. És ez a mai "diff". Én Niko vagyok az Axrisiből. Felelősségteljesen egyesítse. ## Források - [Today's PHP Security Release, and How We're Strengthening PHP Security](https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/) — The PHP Foundation - [RCE via OOM corruption (GHSA-w8hw-w9fx-j79w)](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) — PHP security advisory - [RCE via stale global state (GHSA-6wmf-4rv5-p3rp)](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) — PHP security advisory - [Upcoming Critical PHP Security Release](https://www.php.net/archive/2026.php) — php.net - [php2shell](https://calif.io/php2shell/) — Calif - [PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet](https://www.wiz.io/blog/php2shell-php-rce) — Wiz Research - [Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot](https://aws.amazon.com/blogs/security/amazon-threat-intelligence-identifies-php2shell-exploitation-prior-to-public-disclosure-in-madpot/) — AWS Security Blog - [Critical Vulnerabilities in PHP Require Immediate Patching](https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching) — CISA - [Flaw in PHP computer language leads to shutdown of websites around world](https://www.theguardian.com/technology/2026/oct/21/flaw-in-php-computer-language-leads-to-shutdown-of-websites-around-world) — The Guardian - [What is PHP, and how bad is the computer language flaw causing website shutdowns globally?](https://www.theguardian.com/technology/2026/oct/22/what-is-php-computer-language-flaw-causing-global-website-shutdowns) — The Guardian - [PHP2Shell Exploitation Started Days Before Patches](https://www.securityweek.com/php2shell-exploitation-started-days-before-patches/) — SecurityWeek - [PHP2Shell: Responding to CVE-2026-109618 and CVE-2026-109619](https://www.tanium.com/blog/php2shell-responding-to-cve-2026-109618-and-cve-2026-109619) — Tanium - [There isn't an easy exploit for this PHP vulnerability](https://eliastaylor.com/noexploit/) — Elias Taylor - [PHP blames supply chain security biz Chainguard for putting entire web at risk](https://www.theregister.com/security/2026/10/22/php-blames-supply-chain-security-biz-chainguard-for-putting-entire-web-at-risk/5304611) — The Register - [PHP2Shell: 22M exposed servers at risk as emergency patches released](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released) — TechTarget - [PHP ships emergency patches for critical PHP2Shell flaws](https://www.bleepingcomputer.com/news/security/php-ships-emergency-patches-for-critical-php2shell-flaws/) — BleepingComputer - [GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/) — GitLab - [Meta ordered to pay $25 billion penalty in New Mexico Cambridge Analytica case](https://www.cnbc.com/2026/10/21/meta-new-mexico-cambridge-analytica-penalty.html) — CNBC - [Tell HN: 2x PHP RCE CVEs with CVSS 10.0 Incoming](https://news.ycombinator.com/item?id=50167754) — Hacker News