Awaria Cloudflare z 18 listopada 2025 była globalnym incydentem spowodowanym błędną, automatycznie wygenerowaną konfiguracją w module Bot Management, która doprowadziła do lawiny błędów 5xx na usługach Cloudflare i setkach tysięcy serwisów na całym świecie. Trwała kilka godzin, dotykając m.in. X (Twitter), ChatGPT, Spotify, Canva, Amazon, duże sklepy i usługi SaaS, a Cloudflare określa ją jako najpoważniejszą od 2019 roku.
Co właściwie się stało?
Około 11:20 UTC nagle wzrosła liczba błędów HTTP 5xx. Użytkownicy zgłaszali braki odpowiedzi i liczne timeouty. Wiele firm potwierdziło zakłócenia w działaniu swoich usług. Problemy odczuły między innymi X, ChatGPT, Spotify, Canva, Amazon i duże sklepy e-commerce.
Sytuacja ustabilizowała się dopiero po godzinie 17:00 UTC, choć część serwisów działała wolniej.
Dlaczego doszło do awarii?
Powodem okazał się błąd w module Bot Management. System wygenerował niepoprawny plik konfiguracyjny. Plik rozrósł się i powodował przeciążenie elementów obsługujących ruch HTTP. Część instancji otrzymała dobrą konfigurację, lecz inne dostały błędną wersję. Dlatego usługi działały niestabilnie i przełączały się między trybem poprawnym i awaryjnym.
Cloudflare potwierdził, że nie był to atak cybernetyczny. Przyczyną była zmiana uprawnień w bazie danych oraz logiczny błąd, który ujawnił się dopiero w specyficznych warunkach.
Oś czasu incydentu
- 11:05 UTC – wdrożono zmianę kontroli dostępu w bazie danych.
- 11:20–11:30 UTC – pojawiły się pierwsze błędne pliki konfiguracyjne i wzrost błędów 5xx.
- 11:32–13:05 UTC – zespoły Cloudflare szukały przyczyny w Workers KV i usługach backendowych.
- 13:04–13:10 UTC – zastosowano obejście dla Workers KV, co częściowo ograniczyło efekt domina.
- 14:24–14:30 UTC – wstrzymano propagację wadliwych plików Bot Management i wdrożono poprawną wersję.
- do 17:06 UTC – stopniowo przywrócono normalne działanie usług CDN, Access, Workers, Turnstile i panelu.
Mimo usunięcia głównej przyczyny, przez część popołudnia utrzymywał się „długi ogon” restartów i podwyższonego obciążenia.
Skala wpływu na usługi i firmy
Awaria uderzyła w podstawowe funkcje Cloudflare, czyli CDN i elementy bezpieczeństwa. Wiele firm straciło dostęp do narzędzi potrzebnych do codziennej pracy. Użytkownicy zauważali wolniejsze działanie aplikacji, przerwy i brak odpowiedzi serwerów.
Wiele serwisów przestało działać, mimo że same nie miały żadnej awarii. Wystarczyło, że korzystały z Cloudflare pośrednio. Pokazuje to ogromną zależność biznesu od infrastruktury dostawców.
Cyberatak czy błąd wewnętrzny?
Wiele osób sądziło, że trwa atak DDoS. Symptomami były przeciążenia, błędy i brak odpowiedzi. Zespół Cloudflare też początkowo brał to pod uwagę. Analiza wykazała jednak wyłącznie błąd w konfiguracji. Cloudflare określił go jako „latent bug”, czyli błąd uśpiony. Taki błąd istnieje długo, lecz ujawnia się dopiero w specyficznych warunkach.
Jak zareagował Cloudflare?
Cloudflare publicznie przeprosił klientów i opublikował szczegółowy raport. Firma zapowiedziała wzmocnienie procesów związanych z danymi konfiguracyjnymi.
Plan obejmuje między innymi:
- dodatkowe mechanizmy wyłączające funkcje w razie problemów,
- ograniczenia dotyczące logów i raportów,
- przegląd obsługi błędów w modułach proxy,
- twardsze zasady przetwarzania wewnętrznych plików konfiguracyjnych.
Firma podkreśliła, że całkowite wyeliminowanie ryzyka nigdy nie będzie możliwe. Skala infrastruktury powoduje, że błędy konfiguracji mogą występować.
Co to oznacza dla klientów biznesowych?
Outsourcing bezpieczeństwa i CDN nie usuwa ryzyka. Zmienia je i przenosi na dostawcę. Dlatego firmy powinny przygotować się na podobne sytuacje. Warto rozważyć między innymi:
- multi-CDN,
- zapasowe DNS,
- alternatywne ścieżki dostępu,
- degradację funkcji w trybie awaryjnym,
- monitoring zewnętrzny i wewnętrzny.
Firmy powinny też ocenić własny poziom zależności od jednego dostawcy.
Dlaczego ta awaria dotknęła niemal każdego?
Wiele serwisów korzysta z Cloudflare, lecz nie informuje o tym. Dlatego problemy z dostępem występowały nawet w aplikacjach, które nie kojarzą się z tym dostawcą. Dla wielu użytkowników było to pierwsze spotkanie z efektami globalnej awarii jednego dostawcy infrastruktury.
Ciągłość działania, NIS2 i nadchodząca nowelizacja KSC
Awaria Cloudflare świetnie pokazuje, jak ważna staje się odporność usług. Nowa dyrektywa NIS2 zwiększa wymagania dotyczące bezpieczeństwa i ciągłości działania. Planowana zmiana KSC wprowadzi te obowiązki w Polsce. Organizacje będą musiały wykazać, że poradzą sobie nawet przy globalnej awarii dostawcy. Dlatego warto już teraz przygotować procedury BCP (Business Continuity Plan) oraz DR (Disaster Recovery) i przeanalizować zależności między dostawcami.
