Przekonaj się sam!
Pozostaw wiadomość, a skontaktuje się z Tobą nasz dedykowany doradca.
Wyślij nam wiadomość
0/10000
Pozostaw wiadomość, a skontaktuje się z Tobą nasz dedykowany doradca.
5 grudnia 2025 roku, o godzinie 08:47 UTC, znaczna część internetu wstrzymała oddech. Przez około 25 minut użytkownicy na całym świecie, próbujący dostać się do usług chronionych przez Cloudflare, witani byli błędami HTTP 500. Awaria dotknęła około 28% całego ruchu HTTP obsługiwanego przez giganta CDN. Jak relacjonowaliśmy wcześniej, to już kolejny poważny incydent Cloudflare w grudniu.
Co ciekawe, i co warto podkreślić na wstępie – to nie był cyberatak. Przyczyną była zmiana konfiguracyjna, która miała... zwiększyć bezpieczeństwo. Cloudflare ma długą historię spektakularnych awarii – warto przypomnieć listopadowy incydent, który pokazał kruchość współczesnej infrastruktury internetowej.
Wszystko zaczęło się od dobrych chęci. Cloudflare pracowało nad mitygacją krytycznej podatności w React Server Components (CVE-2025-55182), o której szerzej pisaliśmy w artykule o React2Shell. Aby skutecznie wykrywać złośliwe payloady związane z tą luką, inżynierowie musieli zwiększyć bufor analizy treści w swoim Web Application Firewall (WAF) z domyślnych 128KB do 1MB (limit zgodny z Next.js).
Zmiana rozmiaru bufora była wdrażana stopniowo ("gradual deployment"). W trakcie tego procesu zauważono jednak, że wewnętrzne narzędzie testowe WAF nie radzi sobie z większym buforem. Ponieważ narzędzie to nie było krytyczne dla ruchu klienckiego, podjęto decyzję o jego wyłączeniu.
Tu nastąpił moment krytyczny. Wyłączenie narzędzia testowego zostało zrealizowane przez system globalnej konfiguracji, który propaguje zmiany natychmiastowo do całej floty serwerów – w przeciwieństwie do powolnego wdrażania zmian w kodzie.
Zmiana dotarła do serwerów działających na starszej wersji proxy (FL1), opartej na NGINX i Lua. Wyłączenie reguły testowej (akcja "killswitch") spowodowało, że silnik reguł pominął wykonanie pewnej sekcji kodu, ale późniejsza logika wciąż próbowała odwołać się do jej wyników.
Doprowadziło to do klasycznego błędu:
[lua] ... attempt to index field 'execute' (a nil value)
W uproszczeniu: kod spodziewał się obiektu rule_result.execute, który nie istniał, ponieważ reguła została "zabita" przed wykonaniem. To nieobsłużone wywołanie na wartości nil (null) spowodowało sypanie błędami 500 dla wszystkich klientów korzystających z Managed Rulesets na proxy FL1.
Cloudflare szybko zidentyfikowało problem i wycofało zmianę o 09:12 UTC, przywracając pełną sprawność sieci.
Warto odnotować, że nowsza wersja proxy Cloudflare (FL2), napisana w języku Rust, była całkowicie odporna na ten błąd dzięki silnemu typowaniu, które uniemożliwiło wystąpienie takiej sytuacji na poziomie kompilacji. Firma zapowiedziała przyspieszenie migracji do Rusta oraz wdrożenie mechanizmów "Fail-Open" – tak, aby błąd konfiguracji powodował przepuszczenie ruchu (ewentualnie bez skanowania), a nie jego całkowite zablokowanie.
Ironia losu: próba ochrony przed jedną podatnością (React), wywołała globalny paraliż przez błąd w kodzie, który istniał niezauważony od lat.
Aleksander

Dyrektor ds. Technologii w SecurHub.pl
Doktorant z zakresu neuronauki poznawczej. Psycholog i ekspert IT specjalizujący się w cyberbezpieczeństwie.
Globalna awaria AWS, z epicentrum w US-EAST-1, sparaliżowała dziś tysiące usług. Od Slacka i Zooma po Fortnite i banki – internet wziął przymusowe wolne. Winny: DNS.
W poniedziałek doszło do ogólnopolskiej awarii terminali płatniczych firmy PayTel. Przez kilka godzin klienci w całej Polsce nie mogli płacić kartą, co wywołało chaos w handlu i usługach.
Wielu Polaków przeżyło cyfrowy detoks, gdy w miniony weekend padły terminale płatnicze w całym kraju. Oficjalnie to „problemy techniczne”, ale w kuluarach mówi się o cyberataku.
Ładowanie komentarzy...