Awaria Cloudflare 18 listopada 2025

Awaria Cloudflare 18/11/2025 - Co się stało?#

18 listopada 2025 roku sieć Cloudflare przestała działać na ponad 3 godziny. Przyczyną nie był atak hakerski — winny okazał się błąd w konfiguracji wewnętrznej bazy danych, przez który jeden z plików systemowych urósł ponad dopuszczalny limit. Efekt? Błędy 5xx dla użytkowników na całym świecie.

Błąd konfiguracji, który położył internet#

Cloudflare chroni strony internetowe przed botami. Robi to za pomocą systemu, który analizuje każde żądanie i przypisuje mu punktację — im wyższa, tym większe prawdopodobieństwo, że to bot.

System korzysta z pliku konfiguracyjnego aktualizowanego co kilka minut. 18 listopada zmiana w uprawnieniach bazy danych spowodowała, że zapytanie generujące ten plik zaczęło zwracać zduplikowane dane. Plik podwoił swoją wielkość i przekroczył wewnętrzny limit bezpieczeństwa.

Uszkodzony plik został automatycznie rozesłany do wszystkich serwerów Cloudflare. Każdy serwer, który go wczytał, przestawał obsługiwać ruch.

Co przestało działać?#

Główne usługi CDN zwracały błędy HTTP 5xx. Turnstile (odpowiednik CAPTCHA) był całkowicie niedostępny. Panel administracyjny działał z przerwami — większość użytkowników nie mogła się zalogować. Workers KV i Cloudflare Access również zgłaszały masowe błędy.

Dlaczego diagnoza trwała tak długo?#

Zespół początkowo podejrzewał atak DDoS. System zachowywał się dziwnie — raz działał, raz nie. Okazało się, że plik był generowany co 5 minut, a błąd występował tylko gdy zapytanie trafiło na zaktualizowaną część klastra bazy danych. Losowość dawała złudzenie zewnętrznego ataku.

Dodatkowym zbiegiem okoliczności była awaria strony statusu Cloudflare — która jest hostowana całkowicie poza ich infrastrukturą. To jeszcze bardziej sugerowało skoordynowany atak.

Nawet giganci chmurowi mają słabe punkty. Jeśli krytyczna dostępność jest dla Ciebie priorytetem, warto rozważyć własny serwer domowy jako backup.

Mechanizm awarii od strony technicznej#

Cloudflare używa klastrów ClickHouse do przechowywania i przetwarzania danych. Architektura opiera się na tabelach rozproszonych — dane fizycznie znajdują się w bazie r0, ale dostęp do nich odbywa się przez tabele w bazie default.

Problemem było zapytanie pobierające metadane kolumn:

SELECT name, type
FROM system.columns
WHERE table = 'http_requests_features'
ORDER BY name;

Zapytanie nie zawierało filtra na nazwę bazy danych. Przed zmianą uprawnień zwracało tylko wyniki z default. Po zmianie — użytkownicy zaczęli widzieć również metadane z r0, co podwoiło liczbę wierszy.

Dlaczego to był problem?

Moduł Bot Management ma sztywny limit 200 wpisów w pliku konfiguracyjnym. Limit istnieje z powodów wydajnościowych — pamięć jest prealokowana przy starcie procesu. Normalnie plik zawiera około 60 wpisów. Po błędzie zawierał ponad 200, co powodowało panic w kodzie Rust i natychmiastowe zakończenie procesu.

Cloudflare równolegle migruje ruch na nową wersję swojego proxy. Stara wersja (FL) i nowa (FL2) reagowały na błąd inaczej — FL2 zwracał błędy 5xx, natomiast FL przypisywał wszystkim żądaniom zerową punktację botów, co powodowało false positives w regułach blokujących.

Jak naprawiono problem?#

Zespół zatrzymał automatyczne generowanie plików konfiguracyjnych, ręcznie wstawił poprzednią działającą wersję do kolejki dystrybucji i wymusił restart proxy na wszystkich węzłach. Główny ruch wrócił o 14:30 UTC, pełna funkcjonalność — o 17:06.

Cloudflare zapowiedział wdrożenie walidacji dla wewnętrznie generowanych plików (dotychczas walidowano tylko dane od użytkowników), dodanie globalnych wyłączników dla poszczególnych modułów oraz przegląd obsługi błędów we wszystkich komponentach proxy.

Wnioski#

To była największa awaria Cloudflare od 2019 roku. Ironia polega na tym, że przyczyną nie był zewnętrzny atak, lecz drobna zmiana uprawnień w bazie danych, która uruchomiła efekt domina.

Przeczytaj inne artykuły w kategorii cloudflare.

Pełna analiza techniczna na oficjalnym blogu Cloudflare →