A 2026. október 21-i PHP-sérülékenység után újra aktuális a kérdés, hogy kell-e minden oldalhoz CMS. A két kritikus hibát kijavították és kis túlzással a "fél internet leállt" vagy legalábbis ráparázott. A leállások többsége óvintézkedés volt, megerősített betörés nélkül. Baráti körben beszélgettünk kicsit a témáról és felmerült megint az a beszélgetés, hogy vajon kell-e minden kis oldal alá egy komoly(abb) CMS, a PHP, az admin felület stb.... A statikus oldal általában gyorsabb, és logikailag kisebb a támadási felülete, de nem mindenre jó. Döntés (újfent) nem született de abban egyetértettünk, hogy mindig azt az eszközt válaszd, amelyik a célodhoz illik.

Október 21-én, szerdán a PHP fejlesztői két kritikus sérülékenységet javítottak, és a sajtó percek alatt „php2shell” néven kezdte emlegetni őket. Ha PHP-n futó weboldalad van, a teendő egyszerű: frissíts. A PHP saját közleménye szerint nincs teljes áthidaló megoldás, a frissítés az egyetlen biztonságos választás. Ha ezt még nem tetted meg, ott a lista a következő szakaszban..

Mit javítottak, és mire frissíts?

A két hiba a CVE-2026-109618 és a CVE-2026-109619 azonosítót kapta, mindkettő 9.2-es CVSS v4.0 pontot (ez a sérülékenységek súlyosságát 0 és 10 között mérő skála). A PHP közleménye szerint hitelesítés nélküli, távoli kódfuttatásra adhatnak lehetőséget. Az egyik hibánál a memóriahatár elérése pont rossz pillanatban hagy hátra félig előkészített belső adatot, amit a PHP később érvényesnek vesz. A másiknál egy végzetes hiba után a belső állapot egy korábbi kérés memóriájára mutat.

Mi Adat Forrás
Javított verziók 8.5.12, 8.4.27, 8.3.36, 8.2.35 PHP.net, CISA
Ki érintett minden webes kérést kiszolgáló PHP-telepítés: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed PHP.net
Legnagyobb kockázat mod_php (az Apache webszerver PHP-modulja): itt mutattak be olyan kihasználást, ahol a támadás az alkalmazáskód előtt elindulhat PHP.net
Érintett verziók a The Hacker News szerint szinte minden, egészen a PHP 5.4-ig The Hacker News
Felfedezők a Wiz, a Calif és az OpenAI kutatói The Hacker News

A The Hacker News szerint egy kiszivárgás előrehozta a kiadást. A régi verziókról külön szó jár: a PHP 8.1 és régebbi ágak nem kapnak frissítést a PHP projekttől, a 8.2 támogatása pedig 2026. december 31-én véget ér.

Ha PHP-s oldalad van, ezt csináld meg ma:

  1. Nézd meg, melyik PHP-verzión fut az oldalad (a tárhely vezérlőpultjában vagy a szolgáltatódnál).
  2. Ha 8.5, 8.4, 8.3 vagy 8.2 fut, frissíts a javított kiadásra: 8.5.12, 8.4.27, 8.3.36 vagy 8.2.35.
  3. Ha 8.1 vagy régebbi fut, ahhoz a PHP projekt nem ad javítást. Kérdezd meg a tárhelyszolgáltatót, mit tesz, és számolj a verzióváltással.
  4. Ha a szolgáltatód kezeli a PHP-t, kérd tőle a frissítés időpontját, és ne az ígéretre hagyatkozz.

A régi verziók nem elméleti probléma. A W3Techs 2026. október 28-i adata szerint a PHP-s oldalak 65,7%-a PHP 8-on fut, a PHP 7, 5 és 4 sorok összege pedig 34,4% (az összeadás saját számítás).

Tényleg leállt a fél internet?

A leállások valódiak voltak. A holland kormány több oldalt vett le, köztük az Overheid.nl-t, a MijnOverheid.nl-t és a DigiD-et. A DutchNews szerint a flamand, a német, a francia és a finn kormány is levett oldalakat. Az általam olvasott források közül egyik sem ír megerősített betörésről. A holland kormány közleménye szerint nem volt jele aktív kihasználásnak, óvintézkedésből kapcsoltak le oldalakat, a The Hacker News pedig azt írta, hogy egyetlen konkrét szerveren sem erősítettek meg betörést.

Mindenki azt mondta, hogy a fél internet leállt. A számok szerint a StatusGator 11 000-nél több figyelt szolgáltatásából 213 jelzett legalább egy PHP-vel kapcsolatos állapotfrissítést (2026. október 22., 00:30 UTC-ig). Október 21-én 1790 szolgáltatás jelzett valamilyen zavart, egy átlagos hétköznapon az elmúlt két hétben nagyjából 1100. A StatusGator mérése szerint a zavarok többségét az okozta, hogy a szolgáltatók védték magukat, támadók bejutásáról nem szól az adat. Ez egy mintán mért szám, nem a teljes internet.

Kísérlet viszont volt. A watchTowr október 21-én 14:19 UTC-kor aktív kihasználási kísérleteket jelzett. A Cloudflare szerint a próbálkozások a bejelentés utáni 45 percben tízezres, október 22. elejére milliós nagyságrendűre nőttek. Az Amazon szerint a honeypotjuk (egy csapdának kitett, megfigyelt szerver) már október 17-én rögzített egy kísérletet, négy nappal a nyilvánosságra hozatal előtt. A The Hacker News október 23-i cikke szerint ezek eddig kudarcot vallottak, a Wordfence és más cégek nem láttak megerősített kódfuttatást. A CISA október 26-án mégis felvette a két hibát a kihasznált sérülékenységek katalógusába. A források itt nem teljesen egyeznek: a Palo Alto Networks Unit 42 csapata október 23-i jelzését két nappal később vissza is vonta, mert nem tudta megerősíteni a kapcsolatot a két hibával.

Állítás Mit mutatnak a források
„Leállt a fél internet.” Túlzás: a StatusGator 11 000+ szolgáltatásából 213 jelzett PHP-s állapotot.
„Betörtek az oldalakba.” Megerősített betörésről a források nem írnak, a leállások többsége óvintézkedés volt.
„Komoly hiba.” Igen: 9.2-es CVSS, hitelesítés nélküli távoli kódfuttatás.
„Mindenki PHP-n fut.” Ahol ismert a szerveroldali nyelv, ott az oldalak 69,2%-án (W3Techs, 2026. október 28.).

Ez az utolsó szám magyarázza, miért volt akkora a riadó: a PHP szinte mindenhol ott van, ezért egy kritikus hibája sok helyen számít. A 69,2% azokra az oldalakra vonatkozik, amelyeknél a szerveroldali nyelv ismert, nem az összes weboldalra.

Van egy külön, harmadik hiba is, a CVE-2026-115560. A The Hacker News szerint csak szokatlanul beállított webalkalmazásokat érint, a PHP kis kockázatúnak tartja, és nem ad ki hozzá sürgős javítást. Hogy mely verziókat érint, azt a projekt október 23-án még nem közölte.

Mit tud ebből a statikus oldal?

A statikus oldalnál a HTML-fájlok előre elkészülnek, a szerver pedig csak kiszolgálja őket. Nincs adatbázis-lekérdezés és nincs sablonfuttatás minden egyes látogatásnál.

A gyorsaságra két forrás is utal. A web.dev (a Google fejlesztői útmutatója) szerint az előre legenerált oldal következetesen gyors TTFB-t (az első bájt beérkezéséig tartó időt) ad, mert a HTML-t nem kell a szerveren menet közben összerakni, és több CDN-re (a fájlokat a látogatóhoz közel kiszolgáló hálózatra) is kitelepíthető. Neked ez azt jelenti, hogy a látogatód hamarabb kapja meg az oldalt, mert a szervernek nem kell minden megtekintésnél összeraknia. A Cloudflare két tanulóoldala eltérő erővel fogalmaz: az egyik szerint a statikus oldalgenerátorral készült oldalak kissé gyorsabban töltődnek be, a másik szerint a CDN-ről kiszolgált statikus fájlok a leggyorsabb módja a tartalom kézbesítésének. Ezredmásodperces mérést egyik sem közöl.

A biztonságot logikai érvként írom, nem mért adatként. Ahol kéréskor nem fut szerveroldali kód, ott nincs mit kihasználni abban a kódban. A Jamstack közösségi oldala szerint kevesebb szervert és rendszert kell védeni, az előre generált fájlokat pedig csak olvasható tárhelyről is ki lehet szolgálni. Ez a szállítói oldal véleménye, nem független vizsgálat. Olyan mért összehasonlítást, amely százalékban megmondaná, mennyivel kevesebb a sérülékenység, nem találtam, ezért számot sem írok.

A holland esetből is csak ennyi olvasható ki: a kormány közleménye szerint a Rijksoverheid.nl és több más oldal nem használ PHP-t, ezért rájuk a hiba nem vonatkozott. A Binnenlands Bestuur szerint a legtöbb kormányzati oldal ezért maradt elérhető. Ez nem a statikus oldalak mérése, annyit mutat, hogy ahol nem fut PHP, ott a PHP-hiba nem számít.

A statikus oldalnak is van szervere, tárhelye és üzemeltetője. Eggyel kevesebb alkatrész fut rajta, de nem nulla.

Mikor nem jó a statikus oldal?

Az alábbi táblázat az én összegzésem, nem forrásból származik.

Mire van szükséged Statikus oldal CMS vagy dinamikus rendszer
Ritkán változó tartalom (útmutatók, bemutatkozás, receptek) jó választás gyakran túlzás
Több szerkesztő, napi publikálás kényelmetlen lehet jó választás
Felhasználói fiók, kosár, fizetés önmagában nem elég jó választás, vagy kész szolgáltatás
Űrlap, komment, hírlevél külső szolgáltatás vagy kis szerveroldali rész kell beépítve
Keresés előre legenerált keresési indexszel megoldható beépítve

Ha kalapácsod van, mindent szögnek nézel

Sokan vagyunk így a CMS-ekkel, a nyílt forrásúakkal és a saját fejlesztésűekkel egyaránt. Ha egyszer megvan az adminfelület, az adatbázis és a bővítményrendszer, minden új oldal ide kerül, mert ez a szokott út. Pedig ezek mind olyan alkatrészek, amelyeket frissíteni kell, és amelyek hibázhatnak. Ha az oldalnak nincs szüksége rájuk, csak üzemeltetési teher.

Érdemes másik kérdéssel indítani: hányszor változik az oldal tartalma, és ki változtatja? Négy kérdés segít eldönteni:

  • Hetente vagy ritkábban változik a tartalom?
  • Egy-két ember szerkeszti?
  • Kell hozzá felhasználói fiók, fizetés vagy komment?
  • Az űrlap és a hírlevél megoldható külső szolgáltatással?

Ha az első kettőre igen a válasz, a harmadikra nem, a negyedikre pedig igen, a statikus oldal jó eséllyel elég.

Egy saját példa: az air-fryer.hu

Én is így döntöttem az egyik saját oldalamnál. Az air-fryer.hu független magyar oldal forrólevegős sütőkről: gépleírások, receptek és vásárlási útmutatók vannak rajta, a tartalom szöveges fájlokból épül, és egy statikus oldalgenerátor előre legenerálja belőle az oldalakat. Október 28-án 159 gép, 14 márka és 77 recept szerepel rajta, és olyan útmutatók, mint a Melyik air fryert vegyem 2026-ban?.

Ennek a tartalomnak nincs szüksége adatbázisra. Hetente-havonta változik, egy ember írja, nincs rajta felhasználói fiók és komment. A tartalmi oldalakban nincs szerveroldali kód, egyedül a kapcsolatfelvételi űrlap fut külön, egy kis PHP-s résszel. A statikus oldal tehát attól statikus, hogy a tartalmat nem kell kéréskor összerakni, a szerveroldali kód pedig csak ott marad, ahol tényleg kell. Ugyanezért az űrlap miatt az én tárhelyemen is számít a PHP frissítése, és ugyanaz a lista vonatkozik rám, mint rád.

Ha hasonló oldalt tervezel, először írd össze, mi az, amit tényleg szerkesztened kell, és mi az, ami hónapokig ugyanaz marad. A második listához nem kell CMS.

A hibát kijavították. Az oldalad igényei viszont ugyanazok, mint előtte. Ma a PHP-verziót ellenőrizd, a következő oldalnál pedig azt, hogy valójában mire van szükséged. Elég egy statikus oldal vagy kell a dinamikus?

Források
Hugyecz György

Hugyecz György

Hugyecz György keresőmarketing tanácsadó. Weboldal-építéssel, keresőoptimalizálással (SEO) és az AI-keresőkben való láthatósággal (GEO) foglalkozik, emellett tartalomfejlesztést és tanácsadást vállal. A tutorial.hu-n gyakorlati útmutatókat ír weboldalakról, SEO-ról és AI-eszközökről.

Profil

Kapcsolódó cikkek

WCAG és webes akadálymentesítés

Tovább

Baselinks: így lesz weboldal az Obsidian vault-odból

Tovább