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