A 2021. októberi PHP-biztonsági rés: mi történt, és hogyan áll jelenleg a helyzet
2026. október 21-én, szerdán két súlyos biztonsági rés vált ismertté a PHP-ben, abban a programozási nyelvben, amelyen a legtöbb weboldal fut, köztük a WordPress is. Ön is tapasztalhatta ennek hatását, hiszen a nap egy részében a nálunk üzemelő weboldalak nem voltak elérhetők. Ebben a cikkben összefoglaljuk, mi történt, hogyan jártunk el, és hogy áll jelenleg a helyzet.
Mi történt?
A biztonsági rések (CVE-2026-109618 és CVE-2026-109619) lehetővé tették jogosulatlan személyek számára, hogy kódot futtassanak egy webszerveren. Ez a legsúlyosabb típusú biztonsági rés közé tartozik: a támadónak nincs szüksége jelszóra, és gyakorlatilag az internet nagy részét érinti.
Hogyan jártunk el
- Ideiglenes intézkedés
Ekkor még csak annyi volt ismert, hogy két súlyos biztonsági rés található minden PHP-verzióban, 9,2-es CVE-pontszámmal. Részletek még nem voltak ismertek, és sikeres feltörésekről sem érkezett hír, bár például a Cloudflare egyre több kísérletet észlelt. Mivel a hiba részletei nem voltak ismertek, senki sem tudta pontosan, mi a helyzet, és mit lehet tenni a kockázat csökkentése érdekében. Egyre több mitigáció és lehetséges intézkedés vált ismertté a kockázat csökkentésére. Ezeket mindig azonnal bevezettük, például bizonyos PHP-funkciók letiltását és a tűzfal többszöri frissítését.
10:00 órától folyamatosan rendkívül szigorú kártevő-szkenneléseket is futtattunk, hogy azonnal észleljük, ha valahol szkriptet helyeznek el a szervereinken vagy ügyfeleink fiókjaiban. Ez nem történt meg. - Weboldalak nem elérhetők
Bár szervereinken nem észleltünk visszaélési kísérleteket, úgy döntöttünk, hogy a legbiztonságosabb megoldást választjuk: mindent leállítunk. Ennek fő oka az volt, hogy kétségeink voltak az interneten terjedő mitigációk (ideiglenes megoldások) hatékonyságával kapcsolatban, mivel senki sem tudta megerősíteni, hogy ezek megfelelő védelmet nyújtanak.
Egy ilyen sok bizonytalansággal és potenciálisan hatalmas következményekkel járó helyzetben néhány óra üzemkiesés vállalható, a kockázat vállalása azonban nem. - Hivatalos megoldás
A PHP fejlesztői kiadták a hivatalos frissítést, amely tartalmazta a javítást a 8.3, 8.4 és 8.5 verziókhoz. Ezt követően a CloudLinux, a szervereinken futó PHP-verziók szállítójának frissített csomagjaira kellett várni.
A frissítés megjelenésekor a biztonsági rések részletei is ismertté váltak, ami megerősítette sejtésünket: az ismert mitigációk és a kiegészítő tűzfalszabályok ugyan csökkentették a feltörés kockázatát, de ez nem volt elegendő a szerver védelméhez. - Ideiglenes megoldás
Sajnos jóval tovább tartott, mint reméltük és vártuk, mire a CloudLinux elkészült a frissítésekkel. Más szolgáltatókkal folytatott egyeztetésünkből kiderült, hogy nem mi voltunk az egyetlenek, akiket meglepetés ért. Mivel láttuk, hogy a CloudLinux már többször sem tartotta be a saját maga által kitűzött határidőket, ideiglenes megoldáson dolgoztunk.
Saját magunk telepítettük a 8.3.36-os PHP-verziót az összes szerverünkre, és minden ügyfelünket ideiglenesen erre a verzióra állítottuk át. A weboldalak 90%-a 19:00 és 20:30 között újra elérhetővé vált. Az egyetlen weboldalak, amelyek nem váltak elérhetővé, elavultak voltak, és nem tudtak megfelelően működni modern PHP-verzióval. - Frissítés
A frissítések elérhetővé váltak, és azonnal megkezdtük a telepítést és az ellenőrzést, szerverről szerverre haladva.
- Megoldva
Minden szerver frissítve lett, és minden weboldal ismét elérhetővé vált, azon a PHP-verzión, amelyet korábban is használt.
Teljes mértékben megértjük, hogy kellemetlen, ha egy délutánon és estén át nem érhető el a weboldal. Ez a kellemetlenség azonban nem mérhető a lehetséges következményekhez. Korábban még soha nem kellett döntenünk arról, hogy elővigyázatosságból mindent leállítunk, de ha ugyanilyen helyzet áll elő újra, pontosan ugyanígy járnánk el.
Hogy áll jelenleg a helyzet?
- Minden általunk kínált PHP-verzió, az 5.2-től a 8.5-ig, tartalmazza a biztonsági javításokat mindkét biztonsági résre.
- Azokat a weboldalakat, amelyek egy még régebbi, javítással nem rendelkező PHP-verzión futottak, javított verzióra állítottuk át.
- A biztonsági rés idején és azt követően ellenőriztük a szervereket a visszaélés nyomai után kutatva, például leálló PHP-folyamatok, gyanús folyamatok, feltöltött fájlok és az ismert támadáshoz illeszkedő kérések után. Nem találtunk arra utaló jelet, hogy a biztonsági rést a szervereinken kihasználták volna, és mielőtt leállítottuk a szolgáltatást, erre irányuló kísérleteket sem találtunk.
El van választva az én weboldalam a többiekétől?
Igen. Minden tárhelycsomag nálunk saját, elkülönített környezetben fut. A PHP az Ön csomagjának felhasználója alatt fut, adminisztrátori jogosultságok nélkül a szerveren, és nem férhet hozzá más ügyfelek fájljaihoz vagy adatbázisaihoz. A processzor- és memóriahasználat is csomagonként korlátozott. Biztonsági megoldásainkról további részleteket tudatosan nem osztunk meg nyilvánosan: minél kevesebbet tud egy támadó, annál jobb.
További cikkek

Áttérünk az Euro-Office-ra: az új irodai csomag az Ön Nextcloud-jában
Újdonság: MCP-szerver AI-hoz. Dolgozzon a saját AI-ja az Ön weboldalán
Az AI-ja mostantól közvetlenül dolgozhat a WebOké által üzemeltetett weboldalán: fájlokat módosíthat, hibákat kereshet, új dizájnt készíthet, vagy a WordPress-oldalt gyors statikus oldallá alakíthatja. Elmagyarázzuk, mi az az MCP-szerver, mit nyer vele, mely csomagokhoz érhető el, és mennyibe kerül (nincs többletköltség).

