PHP2Shell: mi történt a PHP-val, és mit tanulhatunk belőle
Múlt héten egy PHP-hiba körül forgott szinte minden fejlesztői és üzemeltetői hír, és nem véletlenül, hiszen a PHP-n fut a weboldalak nagy része, köztük minden WordPress-oldal. A hibát PHP2Shellnek nevezték el, és a hét közepére engem is több ügyfél hívott, hogy érinti-e őket. Ebben a cikkben leírom, mi történt, miért lett belőle ekkora pánik, kik vannak még most is veszélyben, és mit vonok le belőle a saját munkámra.
Mi volt a PHP2Shell?
A PHP2Shell két, egymástól független hiba a PHP magjában (CVE-2026-109618 és CVE-2026-109619), és mindkettő 9,2-es súlyossági pontszámot kapott a 10-es skálán. Mindkettő bejelentkezés nélküli távoli kódfuttatást enged, vagyis egy idegen a saját kódját futtathatja a szervereden anélkül, hogy bármilyen jelszót ismerne. Ez nagyjából a legrosszabb kategória, ami egy webes rendszerrel előfordulhat, mert innen a támadó hozzáfér a fájlokhoz és az adatbázishoz, és hátsó ajtót is hagyhat magának.
Mivel a hiba magában a PHP-ban van, a WordPress vagy a bővítmények frissítése nem segít rajta, és a PHP csapata szerint beállítással sem lehet teljesen kivédeni. Egy megoldás van: a szerveren futó PHP-t kell frissíteni. A javított verziók a 8.5.12, a 8.4.27, a 8.3.36 és a 8.2.35, és a frissítés után a PHP-folyamatokat újra kell indítani, hogy a javítás érvénybe lépjen.
Miért lett ennyire felkapott?
Több dolog jött össze egyszerre. Az első a méret, mert a hiba a 2012-es PHP 5.4-től kezdve minden kiadást érint, és a becslések szerint milliós nagyságrendű, internetről elérhető szerveren fut érintett PHP.
A második az időzítés. A hibát még nyáron találták meg, a hírek szerint AI-eszközök segítségével, és a nyilvánosságra hozatalt október 22-ére tervezték, de a részletek október 20-án kiszivárogtak. A PHP csapata ezért előrehozta a javítást, és október 21-én kiadta, a támadások pedig szinte azonnal elindultak: a watchTowr biztonsági cég már aznap kihasználási kísérleteket látott a csapdaként üzemeltetett szerverein.
A harmadik a reakció. Az amerikai kiberbiztonsági hivatal (CISA) azonnali frissítést sürgetett, több ország állami szerve is figyelmeztetést adott ki, és volt, ahol azt tanácsolták, hogy aki nem tud azonnal frissíteni, inkább vegye le az oldalát. Ez a hír már a laikus sajtóba is átjutott, és innen indult a pánik.
Mi történt valójában a támogatott verziókon?
A nagy szolgáltatók gyorsan reagáltak. A Linux-disztribúciók már a kiadás előtt megkapták a javítást, a cPanel, a CloudLinux és a Plesk javított csomagokat adott ki, a Cloudflare pedig ideiglenes tűzfalszabályokat élesített. Ebből joggal feltételezem, hogy a tárhelycégek a támogatott PHP-verziókon gyorsan és szakszerűen frissítettek, és a felügyelt szervereken ez egy nagyobb figyelemmel kísért, de egyébként átlagos frissítés volt.
Ennek ellenére mindenhol égtek a vonalak. Engem is több ügyfél hívott, hogy most ez őket is érinti-e, és mindenkit meg tudtam nyugtatni, mert amint kijött a frissítés, azonnal megcsináltam a szervereken.
A pánik szerintem részben a tájékoztatás miatt lett ekkora. A szakmai posztok és cikkek jó szándékúak voltak, de szinte mindenki csak a hibáról, a súlyosságáról és arról beszélt, hogy a világ weboldalainak nagy részét érinti. Arról viszont alig esett szó, hogy a javított verziókra valószínűleg mindenhol hamar átálltak, így elsősorban nem azok voltak veszélyben, akiknek a szerverére valaki felügyel. Egy cégvezető, aki csak annyit olvas, hogy a világ weboldalainak többsége veszélyben van, érthetően megijed, pedig lehet, hogy nála már rendben volt minden, mire a cikket elolvasta.
Kik vannak tényleg veszélyben?
Ahol van felügyelet, ott a PHP2Shell lényegében lezárult. Van viszont három csoport, ahol nem.
Akik régi PHP-n maradtak
A PHP kész, telepíthető javítást csak a támogatott ágakra, a 8.2-esre és az újabbakra adott ki. A 7.4-es, a 8.0-s és a 8.1-es ághoz csak magát a kódmódosítást tette közzé, amiből valakinek még el kell készítenie a telepíthető PHP-t, és ezt egy tárhelyfiókon az ügyfél nem tudja megcsinálni. A 7.3 és a régebbi verziók semmit nem kaptak. Ez nem kis kör, mert a cikk írásakor elérhető becslések szerint a PHP-s szervereknek több mint a fele ilyen javítás nélküli ágon fut, és a WordPress-oldalak jelentős része is már nem támogatott PHP-n van. A biztos megoldás ezeken az, ha a projekt átáll egy támogatott verzióra. Addig az segíthet, ha a tárhelyszolgáltató vagy a szerver rendszerének gyártója (például a CloudLinux vagy a cPanel) beépítette a javítást a saját régi PHP-csomagjaiba. Ilyenkor a verziószám maradhat 7.4, a PHP mégis javított, ezért érdemes megkérdezni a szolgáltatót, hogy nálad ez megtörtént-e.
Én is sokszor találkozom régi PHP-n futó WordPress-oldalakkal, és ennek általában két oka van. Az egyik, hogy az oldal öt vagy több éve készült, és azóta senki nem tartja karban. A másik, hogy nem tudnak PHP-t váltani, mert olyan sablon vagy bővítmény fut az oldalon, amihez a fejlesztője már nem ad ki frissítést, és ez sajnos gyakori, főleg az olcsón vásárolt ThemeForestes sablonok és bővítmények körében, amelyek egy idő után fejlesztő nélkül maradnak.
Amikor ilyen oldal érkezik hozzám gondozásra, általában az elsők között javaslom az újraépítést, mert egy öt vagy több éves oldalt foltozgatni nincs értelme, még ha tudom is, hogy költségvetési okokból ez sokszor nehezen megy át.
A nagy, régi PHP-projektek
A régi verziónak sokszor oka van. Egy nagy, évek óta fejlesztett PHP-rendszernél a verzióváltás hetekig tartó munka, mert a kód egy része az új verzión már nem fut, és a használt csomagok egy részének nincs is újabb kiadása. Ezeknél a projekteknél a frissítés halogatása most visszaütött, és a gyors javítás helyett marad a szolgáltató javított régi csomagja, a szerver elérhetőségének szűkítése, és közben a verzióváltás megtervezése.
Az AI-val telepített, felügyelet nélküli szerverek
Mostanában gyakran látok videókat arról, hogy az AI teszi fel egy VPS-re (bérelt virtuális szerverre) a WordPresst, a Laravelt vagy más PHP-s projektet, nagyrészt laikus vibe coderek kezében. Ez gyors és látványos, és sokszor jól is működik, csak utána nem biztos, hogy valaki karbantartja a szervert, vagy figyel a csomagok frissességére. Egy saját VPS-en nincs tárhelycég, amely helyetted frissít, így a PHP2Shell javítása sem települ magától, és aki nem tudja, hogy PHP fut a szerverén, az azt sem fogja tudni, hogy frissítenie kellene.
Aki ezt olvassa, azt gondolhatja, hogy őt ez nem érinti, hiszen nem dolgozik PHP-val. A vibe coderek többnyire Reacttel kezdenek fejleszteni, és tavaly decemberben a Reactben és a rá épülő Next.js-ben is volt egy hasonlóan súlyos hiba (erről lent írok bővebben). Szerintem a jövőben egyre gyakrabban találnak majd ilyen hibákat, főleg a nyílt forrású csomagokban, és ezeket a támadók ugyanígy megpróbálják majd kihasználni.
Nem egyedi eset
Az elmúlt egy évben több hasonló hiba is volt. 2025 decemberében a React2Shell a React Server Componentset és rajta keresztül a Next.js-t érintette, 10-es pontszámmal, és két napon belül nyilvános támadókód jelent meg hozzá. 2026 júliusában a wp2shell a WordPress magjában volt (a 6.9-es és a 7.0-s ágban), és élesben is kihasználták. A PHP2Shell-lel egy héten pedig a Node.js-ben is javítottak egy hasonló, Node2Shellnek elnevezett hibát.
A mintázat mindegyiknél ugyanaz: egy széles körben használt alaprétegben van a hiba, bejelentkezés nélkül kihasználható, és a javítás megjelenése után napokon belül megindulnak a támadások. Mivel a hibakeresés az AI-eszközökkel sokkal gyorsabb lett, szerintem erre a ritmusra kell berendezkedni.
A tanulság: tudatos üzemeltetés
AI-val ma nagyon gyorsan el lehet jutni egy működő, élesben futó projektig, és én is így dolgozom. Attól a naptól kezdve viszont, hogy a projekt élesben fut, a szerver és minden, ami rajta van, valakinek a felelőssége, akkor is, ha az AI tette fel. A folyamatosan bedobott új funkciók mellett ezért az üzemeltetést is meg kell tervezni, és három szinten kell figyelni a biztonságra: a projektben használt csomagokra (npm, Composer), a WordPress-oldal bővítményeire, és a futtatókörnyezetre, vagyis a PHP-ra, a Node.js-re és magára a szerverre. A PHP2Shell a harmadikat mutatta meg, amire a legkevesebben gondolnak.
Hogy ki figyel, az a cégen múlik. Lehet maga a tulajdonos, lehet egy ember a cégen belül, vagy egy külső üzemeltető, de valakinek mindenképp figyelnie kell ezekre. A gyakorlatban ez nem bonyolult: tudd, mi hol fut és milyen verzión, legyen rendszeres frissítési ritmus, kapj értesítést, ha egy használt eszközben sérülékenységet találnak, legyen működő mentés, és a verzióváltást még azelőtt tervezd meg, hogy a régi ág kifut a támogatásból. Ahol ez megvolt, ott a PHP2Shell egy frissítés és pár megnyugtató telefon volt.
Mit nézz meg most?
Ha WordPress-oldalad vagy más PHP-s projekted van, két dolgot nézz meg: milyen PHP-verzió fut alatta, és megkapta-e ez a verzió a javítást. WordPressben az Eszközök → Webhely egészség → Információ → Szerver résznél látod a verziót. Ha 8.2-es vagy újabb verziód van egy tárhelycégnél, nagy valószínűséggel már rendben vagy, de egy rövid kérdés a szolgáltatónak nem árt. Ha 8.2 alatti a verzió, vagy saját VPS-en fut az oldal, akkor érdemes most foglalkozni vele.
Ha nem tudod, milyen PHP fut az oldalad alatt, vagy nincs, aki figyelné, írj nekem. A WordPress karbantartás és a rendszerüzemeltetés pontosan erről szól.
Források: CISA · watchTowr · Unit42 · CybelAngel
Kapcsolódó: Mi az a WordPress karbantartás? · Mi az a vibe coding? · Feltörték a WordPress oldalam: mit tegyek?