18 listopada 2025 roku internet wstrzymał oddech. Jeśli tego dnia próbowałeś wejść na swoje ulubione serwisy i witały Cię błędy 502 lub „Cloudflare Error”, nie byłeś sam. To była największa awaria giganta CDN od 2019 roku.

Pierwsza myśl każdego admina? „To musi być gigantyczny atak DDoS”. Skala problemu była tak duża, że nawet inżynierowie Cloudflare początkowo podejrzewali atak wrogich grup. Prawda okazała się jednak zupełnie inna – i znacznie bardziej pouczająca dla każdego, kto zarządza infrastrukturą IT.
Oto anatomia katastrofy, która wydarzyła się 18 listopada.
To nie był cyberatak
Zacznijmy od najważniejszego: awaria nie została wywołana przez hakerów. Nie był to atak DDoS, ransomware ani sabotaż.
Przyczyną globalnego paraliżu była jedna zmiana w uprawnieniach bazy danych.
Techniczne „Mięso”: Co dokładnie się stało?
Cloudflare używa systemu do zarządzania botami (Bot Management), który ocenia, czy ruch na stronie jest „ludzki”. System ten opiera się na pliku konfiguracyjnym (tzw. feature file), który jest regularnie wysyłany do wszystkich serwerów w ich sieci.
O godzinie 11:05 UTC inżynierowie wprowadzili zmianę w uprawnieniach na klastrze bazy danych ClickHouse. Celem była poprawa bezpieczeństwa i zarządzania dostępem. Niestety, zmiana ta miała niezamierzony skutek uboczny.
- Błąd w zapytaniu: Nowe uprawnienia sprawiły, że zapytanie generujące plik konfiguracyjny zaczęło zwracać zduplikowane wiersze.
- Rozmiar pliku: W efekcie plik feature file, który normalnie ma stały, przewidywalny rozmiar, nagle urósł dwukrotnie.
- Propagacja: Ten „nadmuchany” plik został automatycznie rozesłany do tysięcy serwerów (proxy) Cloudflare na całym świecie.
Dlaczego serwery „spanikowały”?
Oprogramowanie proxy Cloudflare (napisane w języku Rust) miało zaszyty w kodzie sztywny limit wielkości tego pliku (memory allocation limit). Była to optymalizacja wydajnościowa – system rezerwował z góry określoną ilość pamięci.
Gdy serwery otrzymały plik przekraczający ten limit, kod nie był w stanie go obsłużyć. W języku Rust, w przypadku krytycznego błędu pamięci, następuje tzw. panic. Proces obsługujący ruch sieciowy po prostu „umarł”.
Komunikat błędu wyglądał tak: thread fl2_worker_thread panicked: called Result::unwrap() on an Err value
Efekt? Serwery przestały procesować ruch HTTP/HTTPS. Zamiast stron www, użytkownicy widzieli błędy 5xx.
Timeline Awarii
- 11:05 UTC: Wdrożenie zmiany w bazie ClickHouse.
- 11:20 UTC: Poczatek problemów. Ruch sieciowy zaczyna drastycznie spadać, pojawiają się błędy 5xx.
- 11:35 UTC: Cloudflare ogłasza incydent. Początkowo podejrzewają atak DDoS.
- 13:05 UTC: Inżynierowie identyfikują problem i wyłączają wadliwy system Bot Management.
- 14:30 UTC: Główny ruch wraca do normy po ręcznym wgraniu poprawnego pliku konfiguracyjnego.
- 17:06 UTC: Pełne przywrócenie wszystkich usług.

Lekcja dla nas
Ta awaria to doskonałe przypomnienie o „efekcie motyla” w IT. Jedna, z pozoru rutynowa zmiana w uprawnieniach bazy danych, doprowadziła do kaskadowej awarii globalnej infrastruktury.
Wnioski dla Twojej firmy:
- Walidacja danych wejściowych: Nawet wewnętrzne pliki konfiguracyjne powinny być walidowane przed użyciem. Gdyby system sprawdził rozmiar pliku przed próbą jego załadowania, awarii można by uniknąć.
- Stopniowe wdrażanie (Canary Deployments): Zmiany globalne powinny być wdrażane falami. Tutaj wadliwy plik trafił wszędzie niemal jednocześnie.
- Obsługa błędów: „Hard fail” (panic) w systemie krytycznym to ostateczność. Systemy powinny być projektowane tak, by w przypadku błędu konfiguracji cofały się do ostatniej znanej dobrej wersji (last known good configuration), zamiast przestawać działać.
Cloudflare przeprosiło i opublikowało szczegółowy raport. To lekcja pokory dla każdego administratora i programisty.
Bezpieczeństwo to proces, a nie produkt
Analiza przypadku Cloudflare pokazuje, jak skomplikowane zależności rządzą nowoczesnym IT. Błąd w jednym pliku konfiguracyjnym położył globalną sieć. W mniejszej skali – w Twojej firmie – podobny błąd konfiguracji routera czy serwera może otworzyć drzwi hakerom lub zatrzymać sprzedaż na wiele godzin.
Nie musisz znać się na bazach ClickHouse ani języku Rust, żeby spać spokojnie. Od tego masz nas.
🛠️ Martwisz się o stabilność swojej infrastruktury? [Skontaktuj się z nami] i umów na niezobowiązującą rozmowę o bezpieczeństwie Twojej firmy.