AZ 1,6 MILLIÁRD DOLLÁROS FÜGGVÉNYHÍVÁS
Hogyan bénította meg a világot egyetlen kódsor? Miért nem szabad feltételezésekre építeni kritikus infrastruktúrát? A Cloudflare-incidens technikai elemzése.
Ferenc Frész | Nov 20, 2025

https://www.cyberthreat.report/p/az-16-milliard-dollaros-fuggvenyhivas

2025. november 18-án, a globális digitális infrastruktúra egyik legsúlyosabb üzemzavara rázta meg az Internetet, amikor a Cloudflare, a világ vezető felhőszolgáltatója és kiberbiztonsági vállalata, kiterjedt szolgáltatáskiesést szenvedett el. Az incidens, amely magyar idő szerint a déli órákban kezdődött és több órán át tartott, alapjaiban rengette meg a modern web működésébe vetett bizalmat, elérhetetlenné téve a világháló legfontosabb szolgáltatásainak jelentős részét.

A leállás nem kímélte a kritikus pénzügyi rendszereket, a mesterséges intelligencia platformokat (köztük az OpenAI ChatGPT-jét), a közösségi média óriásait (X, Discord), valamint a magyarországi digitális ökoszisztéma kulcsszereplőit sem. Bár a kezdeti tünetek – a tömeges 5xx hibák és a hálózati timeoutok – egy koordinált kibertámadás képét vetítették előre, a mélyreható vizsgálatok egy sokkal prózaibb, ám mérnöki szempontból annál tanulságosabb okra derítettek fényt: egy belső, rutinjellegű adatbázis-konfigurációs hiba váltotta ki a katasztrófát.

A Cloudflare helye a digitális értékláncban

A 21. századi internet működése elképzelhetetlen olyan láthatatlan óriások nélkül, amelyek a háttérben biztosítják az adatforgalom gyorsaságát, biztonságát és megbízhatóságát. Ezen ökoszisztéma egyik legmeghatározóbb szereplője a Cloudflare.

Infrastrukturális kritikalitás és piaci kitettség

A Cloudflare nem csupán egy tartalomszolgáltató hálózat (CDN), hanem a web immunrendszere. A vállalat szolgáltatásai közé tartozik a weboldalak gyorsítótárazása, a DNS-feloldás, a DDoS-támadások elleni védelem, valamint a Zero Trust biztonsági megoldások. Piaci részesedése és befolyása óriási: becslések szerint a világ összes weboldalának mintegy 20%-a, a leglátogatottabb 10 000 webhelynek pedig közel egyharmada támaszkodik közvetlenül a Cloudflare infrastruktúrájára. Ez a fajta koncentráció, bár hatékonyságnövelő, komoly rendszerszintű kockázatot hordoz.

A vállalat hálózata globálisan elosztott, több mint 125 országban több száz adatközpontot üzemeltet. Ez az architektúra teszi lehetővé, hogy a felhasználói kéréseket a fizikai helyükhöz legközelebb eső szerverek szolgálják ki, minimalizálva a látenciát. Ugyanakkor ez a struktúra azt is jelenti, hogy egy központi konfigurációs hiba képes a fény sebességével terjedni a hálózaton, globális szintű digitális bénulást okozva. Amikor a Cloudflare eltüsszenti magát, az internet jelentős része megfázik. Jelen esetben azonban nem csupán megfázásról, hanem az életfunkciók átmeneti leállásáról beszélhetünk.

A Cloudflare szerepe különösen kritikus a kiberbiztonságban. A vállalat reverse proxy szolgáltatása elrejti az ügyfelek eredeti szervereinek IP-címét, így a támadók nem tudják közvetlenül célba venni azokat. Ez a védelmi réteg vált november 18-án áthatolhatatlan falból átjárhatatlan akadállyá: ahelyett, hogy a támadásokat szűrte volna, a legitim forgalmat is blokkolta.

Az incidens előzményei: A biztonság paradoxona

Ironikus módon az incidens gyökere egy biztonsági és megbízhatósági fejlesztésben keresendő. A Cloudflare mérnökei folyamatosan dolgoznak rendszereik ellenálló képességének növelésén. A kérdéses időszakban a ClickHouse adatbázis-fürtön végeztek karbantartást. A ClickHouse egy nagy teljesítményű, oszloporientált adatbázis-kezelő rendszer, amelyet a Cloudflare masszív mennyiségű logadat elemzésére és a Bot Management rendszer támogatására használ.

A beavatkozás célja az volt, hogy javítsák az elosztott lekérdezések biztonságát és megbízhatóságát azáltal, hogy szigorítják és explicitebbé teszik a hozzáférési jogosultságokat. Ez a fajta proaktív karbantartás elengedhetetlen egy ilyen léptékű rendszernél. A mérnöki csapat szándéka a rendszer robusztusságának növelése volt, nyilván nem annak destabilizálása. Ennek ellenére ebben az esetben a jogosultságok megváltoztatása egy olyan rejtett interakciót indított el az adatbázis-rétegek között, amelyre senki sem számított.

A hiba elemzése és a láncreakció

Az incidens technikai lefolyása a modern szoftvermérnöki katasztrófák iskolapéldája, ahol több, önmagában talán kezelhető tényező – egy adatbázis-konfiguráció, egy hiányzó validáció, és egy agresszív hibakezelési stratégia a kódban – együttállása vezetett a rendszerösszeomláshoz.

A nulladik beteg: A ClickHouse jogosultságmódosítás

A láncreakció UTC idő szerint 11:05-kor (közép-európai idő szerint 12:05) indult. A Cloudflare DevOps csapata egy rutinfrissítést telepített a ClickHouse klaszterre. A módosítás lényege az volt, hogy megváltoztatták, hogyan férhetnek hozzá a lekérdezések a különböző adatbázis-táblákhoz.

A probléma forrása az volt, hogy az új jogosultsági beállítások mellett egy bizonyos típusú, metaadatokat lekérdező query nemcsak a kívánt eredményeket adta vissza, hanem véletlenül hozzáférést kapott egy r0 jelölésű, alacsonyabb szintű replikációs táblához is. Ez a tábla az elosztott lekérdezések működéséhez szükséges alapadatokat tartalmazta.

Amikor a Bot Management rendszer lekérdezte a konfigurációs adatait, a módosított jogosultságok miatt a query eredményhalmaza szennyezetté vált. A rendszer minden egyes kért adatsort kétszer kapott meg: egyszer a normál táblából, egyszer pedig a replikációs táblából. Az adatbázis nem dobott hibát, a lekérdezés szintaktikailag helyes volt, és az eredmény is érvényesnek tűnt az adatbázis szemszögéből.

A kövér fájl jelenség: A méret a lényeg

A Cloudflare Bot Management rendszere gépi tanulási modelleket használ a bejövő forgalom elemzésére és a botok kiszűrésére. Ez a rendszer dinamikusan működik: a szabályokat és paramétereket rendszeresen frissítik. Ezeket a paramétereket egy konfigurációs fájlba írják ki, amelyet a ClickHouse-ból generálnak újra körülbelül 5 percenként.

Normál üzemmenetben ez a konfigurációs fájl körülbelül 60 különböző paramétert tartalmaz, amelyek alapján a rendszer pontozza a látogatókat. A duplikáció következtében azonban a generált fájl mérete hirtelen a duplájára nőtt. A paraméterek száma meghaladta a 200-at. A rendszerben nem volt olyan validációs lépés a fájlgenerálás után, amely ellenőrizte volna a kimeneti fájl méretét vagy a benne lévő elemek számát. A kövér fájl így akadálytalanul bekerült a terjesztési csatornába.

A Cloudflare infrastruktúrája rendkívül hatékony a tartalomterjesztésben. Amint a fájl elkészült, a belső mechanizmusok azonnal elkezdték replikálni azt a világ összes adatközpontjába. Percek alatt a hibás konfiguráció eljutott Tokiótól San Franciscóig, Londontól Budapestig minden szerverre.

Rust, memória-allokáció és az unwrap() pánik

A dráma következő felvonása a Cloudflare edge szerverein játszódott le, ahol az új generációs, FL2 névre keresztelt proxy motor futott. Az FL2-t Rust nyelven írták, amely az iparágban a memóriabiztonságáról és megbízhatóságáról híres. A Rust egyik alapelve, hogy fordítási időben kikényszeríti a memóriakezelési szabályokat, elvileg lehetetlenné téve az olyan klasszikus hibákat, mint a null pointer dereferencia vagy a buffer overflow.

Azonban a Rust sem véd meg a logikai hibáktól. Az FL2 motor Bot Management moduljának kódjában a fejlesztők egy hard limitet állítottak be a kezelhető konfigurációk számára. Ez a limit 200 volt. A döntés mögött teljesítményoptimalizálási okok álltak, a memóriát előre allokálták a gyorsabb működés érdekében, és mivel a gyakorlatban sosem használtak 60-nál több feature-t, a 200-as limit bőségesnek tűnt.

Amikor a proxy motor megpróbálta betölteni a kövér fájlt, amely immár több mint 200 elemet tartalmazott, a kód egy kritikus elágazáshoz ért. Ahelyett, hogy a program egy kezelt hibaüzenettel elutasította volna a fájlt és visszatért volna az előző verzióhoz, a kódban egy Result::unwrap() hívás szerepelt.

Az unwrap() szemantikája

A Rust nyelvben a hibakezelés a Result<T, E> típuson alapul, amely vagy egy sikeres értéket (Ok(T)), vagy egy hibát (Err(E)) tartalmaz. Az unwrap() metódus egy kényelmi funkció: ha az eredmény Ok, visszaadja az értéket. Ha viszont Err, a program azonnal pánikba esik (panic), és a futó szál (thread) leáll.

// Pszeudókód a hiba illusztrálására
let features = load_features_from_file(file);
// A fejlesztő feltételezése: “Ez sosem fog elromlani, a fájl mindig jó.”
let valid_features = features.unwrap(); // ITT TÖRTÉNT A BAJ

A jelentések szerint a fejlesztők explicit módon úgy döntöttek, hogy ezen a ponton a pánik a megfelelő viselkedés, vagy egyszerűen figyelmen kívül hagyták a hiba lehetőségét, bízva a bemeneti adatok integritásában. Amikor a limit túllépése miatt a függvény hibát dobott, az unwrap() aktiválódott, és az FL2 folyamat összeomlott.

A dominóhatás és a fűrészfog-mintázat

Mivel az FL2 proxy motor kezeli a bejövő HTTP kéréseket, annak összeomlása azt jelentette, hogy a szerverek nem tudták kiszolgálni a forgalmat. A látogatók 5xx (Internal Server Error) hibaüzeneteket kaptak.

A helyzetet súlyosbította a rendszer automatikus újraindulása és a konfigurációs fájl ciklikus frissítése.

1) A proxy összeomlott.

2) A felügyeleti rendszer (watchdog) észlelte a leállást és újraindította a folyamatot.

3) Az újraindult folyamat ismét megpróbálta betölteni a hibás fájlt, és újra összeomlott.

4) Közben, mivel a ClickHouse-ban a hiba az elosztott lekérdezések természetéből adódóan nem mindig jelentkezett minden egyes generálásnál (néha a lekérdezés olyan node-ra futott, ahol nem volt duplikáció), a rendszer néha jó fájlt kapott, és rövid időre helyreállt.

Ez a jelenség egy fűrészfogas mintázatot eredményezett a hibagörbén: a szolgáltatás elérhetősége drasztikusan ingadozott, hol teljesen leállt, hol rövid időre visszatért, ami még nehezebbé tette a diagnosztikát a külső megfigyelők és a mérnökök számára.

A leállás globális és lokális következményei

A technikai hiba pillanatok alatt vált globális krízissé. A leállás nem válogatott: érintette a szórakoztatóipart, a pénzügyi szektort, a kritikus infrastruktúrát és a mindennapi kommunikációt.

Globális szolgáltatások megbénulása: Amikor a digitális élet megáll

A leglátványosabb hatást a nagy felhasználói bázissal rendelkező platformok leállása jelentette.

*** Mesterséges Intelligencia: Az OpenAI ChatGPT-je, a Claude (Anthropic) és más AI-szolgáltatások teljesen elérhetetlenné váltak. A felhasználók világszerte Access Denied vagy timeout üzenetekkel szembesültek. Mivel az AI eszközök mára integrálódtak a munkafolyamatokba (kódolás, tartalomgyártás), a kiesés azonnali produktivitás-csökkenést okozott.

*** Közösségi Média: Az X (Twitter), a Discord, a Reddit és számos más közösségi platform működése akadozott. A képek nem töltődtek be, az üzenetek nem mentek át, a hírfolyamok nem frissültek.

*** SaaS és E-kereskedelem: A Shopify, a Canva, a Salesforce és más üzleti alkalmazások leállása közvetlen bevételkiesést jelentett a vállalkozásoknak. A felhasználók nem tudtak fizetni, számlázni vagy hozzáférni az adataikhoz.

A pénzügyi szektor veszteségei: Milliárdos károk

A pénzügyi piacokon az idő pénz, a másodperc tört része alatt bekövetkező késés vagy leállás pedig dollármilliókba kerülhet. A Finance Magnates részletes elemzése sokkoló számokat tárt fel.

A jelentések szerint a háromórás kiesés alatt a Forex és CFD brókerek (pl. Monaxa, Skilling, Xtrade) kereskedési volumene drasztikusan visszaesett. A becsült 1,58 milliárd dolláros kiesés a havi kereskedési volumen mintegy 1%-át tette ki, ami közvetlenül megjelenik a bevételek csökkenésében is. A kisebb brókerek 360 millió, a nagyobbak akár 3 milliárd dolláros forgalomkiesést is elszenvedhettek. A brókerek weboldalai Internal Server Error üzenettel fogadták a pánikba esett befektetőket, akik nem tudták zárni a pozícióikat egy volatilis piacon.

A kriptovaluta-piacon a központosított tőzsdék (Coinbase, BitMEX) és a blokklánc-felfedezők (Arbiscan) leállása újraélesztette a vitát a decentralizáció fontosságáról. Vitalik Buterin, az Ethereum társalapítója által korábban megfogalmazott Trustless Manifesto elvei új értelmet nyertek: amíg a decentralizált protokollok (DeFi) működéséhez központosított közvetítők (Cloudflare) szükségesek a frontend kiszolgálásához, addig a valódi decentralizáció csak illúzió marad.

A leállás magyarországi vonatkozásai

Magyarország sem maradhatott ki a globális összeomlásból. A hazai digitális tér jelentős szereplői használják a Cloudflare szolgáltatásait, így a hatások azonnal érezhetőek voltak.

*** Média és Tájékoztatás: A vezető online hírportálok, mint a Telex, a 444.hu és a Népszava, Mandiner elérhetetlenné váltak. Az olvasók nem tudták elérni a híreket, ami egy információs vákuumot hozott létre a déli órákban. A szerkesztőségek számára ez nemcsak presztízsveszteség, hanem konkrét hirdetési bevételkiesés is volt.

*** Kritikus Infrastruktúra: Bár a magyar bankrendszer, telekommunikációs rendszer magja zárt hálózatokon fut, a publikus internet felé nyitott felületek (netbanki belépőoldalak, tájékoztató site-ok, külső szolgáltatások) némelyike lassulást vagy elérhetetlenséget produkált.

*** Felhasználói Élmény: A magyar internetezők tömegesen tapasztalták, hogy kedvenc oldalaik nem töltődnek be. A Downdetector magyar szekciója is elérhetetlen volt egy ideig, ami ironikus helyzetet teremtett: nem volt hol megnézni, hogy miért nincs internet.

A helyreállítás krónikája és az incidenskezelés

A Cloudflare reakcióideje és a transzparenciája példaértékű volt, még ha maga a hiba elkerülhető is lett volna. Az alábbi idővonal (UTC idő szerint) bemutatja a kármentés lépéseit.

11:05: A végzetes ClickHouse frissítés végrehajtása.

11:20: A Bot Management rendszer legenerálja az első hibás, túlméretezett konfigurációs fájlt.

11:28: A Cloudflare monitoring rendszerei (és a mérnökök telefonjai) felrobbannak: tömeges 5xx hibák a hálózaton.

11:30: Külső monitoring cégek (Cisco ThousandEyes) észlelik a globális kiesést. A Twitter (X) megtelik panaszokkal.

11:48: A Cloudflare hivatalosan elismeri a problémát a státuszoldalán.

13:05: A mérnökök (megkerülő megoldásokat alkalmaznak: bizonyos kritikus szolgáltatásokat (Workers KV, Access) átirányítanak, vagy kikapcsolják a hibás modulokat, hogy legalább részlegesen helyreálljon a forgalom. Ez javulást hoz, de nem oldja meg teljesen a problémát.

14:24: A jó fájl generálása helyett a mérnökök manuálisan leállítják a konfigurációs frissítések terjesztését, megakadályozva a hiba újratermelődését.

14:30: Sikeresen visszaállítanak egy korábbi, ismert jó állapotú konfigurációs fájlt a rendszerbe. A proxy motorok stabilizálódnak, a forgalom visszatér.

17:06: Minden rendszer, beleértve a háttérszolgáltatásokat és a naplózást is, teljes kapacitással, hibamentesen üzemel. Az incidens hivatalosan lezárva.

A vállalat vezérigazgatója, Matthew Prince, még aznap este részletes blogbejegyzésben kért bocsánatot, és vállalta a felelősséget. “Tudjuk, hogy ma cserbenhagytuk önöket” – írta, hangsúlyozva, hogy a hiba fájdalmas volt a csapat minden tagja számára.

A centralizáció dilemmája

Az incidens újra fókuszba helyezte az egypontos hiba (Single Point of Failure - SPOF) problémáját. Amikor a Cloudflare, az AWS vagy az Azure leáll, velük együtt dől a dominó.

A Cloudflare gyors helyreállítása és transzparenciája dicséretes, de a közel 1,6 milliárd dolláros kár és a globális bizalomvesztés intő jel. A technológia fejlődésével a rendszerek komplexitása nő, és ezzel együtt a hasonló események valószínűsége is. A november 18-i leállás emlékeztető arra, hogy az internet, bár robusztusnak tűnik, valójában egy törékeny egyensúlyon alapul, amelyet egyetlen rossz konfigurációs sor is felboríthat.

Előzmény

Válasz

Hiba csúszott a gépezetbe a Cloudflare-nél, rögtön le is állt a fél internet | 2025. november 18.

... a Cloudflare szervereivel volt probléma. A leállás elég kiterjedt volt, egyebek mellett az X, az OpenAI és a magyar hírportálok jelentős része is érintett volt,

-- és ironikus módon még az a Downdetector is akadozott, ahol általában követni lehet a leállásokat.

A Cloudflare először magyar idő szerint délután egy óra körül számolt be arról, hogy problémákat észleltek, amik hatással lehetnek a szolgáltatásaikra is. Hozzátették, már dolgoznak a megoldáson, és a továbbiakban is tájékoztatni fognak erről. A cég bő egy órával később azt írta, megtalálták a hiba okát, magyar idő szerint 15:42-kor pedig azt írták, sikerült kijavítaniuk a problémát. Így az incidenst lezárnak tekintik, de továbbra is követik az eseményeket, hogy meggyőződjenek arról, minden visszatér a rendes kerékvágásba.

A Cloudflare szóvivője korábban a CNBC-nek azt nyilatkozta, a leállás kezdetekor szokatlanul nagy forgalmat észleltek, ez állhatott az egész hátterében. Azt nem tudták megmondani, hogy ezt mi okozhatta, de a Guardiannek egy kiberbiztonsági szakértő azt mondta, valószínűleg nem kibertámadás áll a háttérben, mert egy ilyen kiterjedt szolgáltatást nem lehet egyetlen pont támadásával térdre kényszeríteni. A Cloudflare-nél egyébként nem ez volt idén az első nagyobb leállás, júniusban egy hasonló esetnél is számos cég szolgáltatásai váltak elérhetetlenné.

Ilyenkor egyébként jól látszik, hogy bár nem szoktak róla sokat beszélni, a főleg a terheléses támadások ellen védelmet nyújtó szolgáltatásáról ismerhető Cloudflare tényleg az internet egyik legfontosabb szereplője. A cég saját bevallása szerint a teljes forgalom 20 százalékának felgyorsításában vagy védelmében vállal szerepet, és átlagban 78 millió lekérést fogad másodpercenként, és mint az most is kiderült, ha valamiért leáll, akkor a fél internetet magával tudja rántani.

Ebben amúgy nincs is egyedül: az elmúlt években kiderült, hogy a Facebook, az AWS vagy az Azure leállása, egy feltörekvő kiberbiztonsági cég elbaltázott frissítése vagy egy több nagy repteret kiszolgáló cég elleni kibertámadás is globális, sok mindenre kiható problémákat tud okozni.

https://telex.hu/techtud/2025/11/18/hiba-csuszott-gepezet-cloudflare-leallt-fel-internet

Válasz

Intermezzo #01 Mi van velünk? (élő most)
Egy kis bejelentkezés, Linux Mind Zoli, Stradus és velem (Fodor Sándor), gyertek dumálni.
https://www.youtube.com/watch?v=XJmKaWv2TPs

Válasz