Ugrás a tartalomhoz

Sütibeállítások

Típusonként válassza ki, mely sütiket engedélyezi. Választását bármikor módosíthatja a Sütibeállítások linken, amely minden oldal alján megtalálható. Adatvédelmi nyilatkozat

Szükséges

Mindig bekapcsolva

A bejelentkezéshez, a kosár megőrzéséhez és a választásai megjegyzéséhez szükségesek. Ezek mindig be vannak kapcsolva.

Milyen sütik?
  • weboke_sessie, weboke_klant, weboke_remember: a munkamenet és a bejelentkezve maradás
  • weboke_basket: a kosár
  • wkBtwIncl: az árak megjelenítése ÁFÁ-val vagy anélkül
  • wok_cookies: a sütiválasztás, 12 hónap

Méri, melyik hirdetés vezet látogatáshoz vagy rendeléshez, hogy ne fizessünk hatástalan hirdetésekért.

Milyen sütik?
  • Google Ads a Google Tag Manageren keresztül (_gcl_au, _gcl_aw), legfeljebb 90 napig
  • OpenAI Ads, hirdetések a ChatGPT-ben
  • wok_aff: melyik partnerünk ajánlására érkezett (partnerprogram), 60 nap

4,6

Ország és nyelv

Minden országnak saját oldala van, az adott ország áraival és ÁFA-jával.

Megtekintés
Vissza a cikkek áttekintéséhez

A 2021. októberi PHP-biztonsági rés: mi történt, és hogyan áll jelenleg a helyzet

WebOke Support

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

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

Egy pillanat…

Domainek beállítása

Állítsa be domainenként a névszervereket, a tárhelyhez való kapcsolást és azt, hogy ki legyen a tulajdonos.

Domainek betöltése…