Cloudflare łata błąd ACME – czy omijanie WAF stało się możliwe?

Czy krótka, nudna ścieżka do certyfikatów może stać się objazdem wokół całej zapory? Okazuje się, że tak – jeśli logika na brzegu sieci skręci w zły zjazd.

Cloudflare załatał błąd w obsłudze ACME (HTTP-01) na swojej krawędzi, który pozwalał ominąć Web Application Firewall i dotrzeć prosto do serwerów origin. Firma mówi, że nie widzi śladów nadużyć, a poprawka trafiła w produkcję 27 października 2025 r. Mimo to przypadek jest pouczający: jeden „techniczny wyjątek” potrafi zmienić się w całkiem realny bypass.

ACME to protokół, który automatyzuje wystawianie i odnawianie certyfikatów SSL/TLS. Prawie każdy serwis ma więc gdzieś w zakamarkach adresu ścieżkę /.well-known/acme-challenge/{token}. Zwykle zaglądają tam tylko boty urzędów certyfikacji. Tym razem jednak „ścieżka serwisowa” na chwilę stała się kanałem omijającym ochronę.

Co poszło nie tak

Zacznijmy od mechaniki. Gdy weryfikacja domeny odbywa się metodą HTTP-01, urząd certyfikacji (CA) oczekuje na serwerze pliku z tokenem pod bardzo konkretnym adresem. Jeśli zamówieniem certyfikatu zarządza Cloudflare, to sama krawędź Cloudflare serwuje ten token. Jeśli nie – prośba trafia do origin klienta, bo ten może mieć własny proces walidacji.

I tu krył się błąd. Cloudflare przyznaje, że pewne żądania do /.well-known/acme-challenge/* uruchamiały specjalną ścieżkę logiczną: krawędź wyłączała część funkcji WAF (by nie przeszkadzać w walidacji), ale jednocześnie przepuszczała żądanie dalej – na origin – nawet wtedy, gdy token nie odpowiadał aktywnemu wyzwaniu ACME dla danej nazwy hosta. Innymi słowy: kontrola, czy „to na pewno tu i teraz”, była zbyt luźna. Efekt? Atakujący mógł wysyłać arbitralne żądania pod ścieżkę ACME i omijać reguły WAF. [5][4]

Badacze z FearsOff, którzy zgłosili problem 9 października 2025 r. przez program bug bounty, zreplikowali zjawisko w kontrolowanych środowiskach (m.in. PHP, Spring/Tomcat, Next.js). Standardowe requesty blokował WAF. Te same, ale skierowane pod ścieżkę ACME, lądowały już na originie, który odzywał się frameworkowym 404 albo – jeśli aplikacja miała swoje grzeszki – czymś poważniejszym. W jednym z opisów czytamy, że taka luka w inspekcji ułatwiała rozpoznanie środowiska i dostęp do wrażliwych zasobów na serwerze.

Dlaczego to ma znaczenie

WAF w środowiskach chmurowych ma chronić origin. Klienci często zakładają, że na brzegu zostanie odfiltrowane to, co nie powinno przejść. Wyjątki – nawet uzasadnione, jak w przypadku ACME – muszą być precyzyjnie ograniczone. Inaczej powstaje ukryty kanał ruchu.

Tu mowa o oknie ograniczonym do konkretnej ścieżki, ale szeroko obecnej na wielu hostach. I choć Cloudflare podkreśla, że nie odnotowano nadużyć, sam wektor (ruch, który nie przechodzi pełnej inspekcji WAF) jest atrakcyjny dla atakującego: od rekonesansu po selektywne próby pod znanymi wrażliwościami aplikacji. To nie katastrofa od ręki, ale wymaga uwagi.

Co dokładnie zmienił Cloudflare

Po walidacji zgłoszenia (13-14 października) i krótkim dochodzeniu, 27 października 2025 r. Cloudflare wdrożył poprawkę: wyłączenie funkcji WAF przy ACME następuje tylko wtedy, gdy żądanie zawiera ważny token ACME HTTP-01 dla danego hosta i Cloudflare ma gotową odpowiedź do podania. Brzmi jak drobiazg, ale to właśnie brak tej restrykcji stworzył problem. Firma podkreśla też, że klienci nie muszą nic robić – patch jest po stronie krawędzi i już działa. [1][6]

Warto dodać, że mechanizm ograniczania inspekcji podczas walidacji ACME ma sens operacyjny. Gdy CA łączy się z serwisem, nie chcemy, by dodatkowe warstwy bezpieczeństwa zakłócały proces. Taki wyjątek musi jednak mieć twarde warunki brzegowe, pełny kontekst (token+hostname) i jasny powrót do głównej ścieżki inspekcji, jeśli warunki nie zachodzą.

Szerzej: lekcja dla wszystkich, nie tylko dla Cloudflare

Incydent wpisuje się w szerszy trend: automatyzacja infrastruktury – certyfikaty, boty, health-checki – dostaje specjalne traktowanie. Z punktu widzenia operacji to rozsądne. Z punktu widzenia bezpieczeństwa wymaga dyscypliny. Im bardziej rozbudowany edge i większa liczba wyjątków, tym ważniejsze stają się negatywne testy (np. „co jeśli token jest prawidłowy, ale nie dla tego hosta?”), spójność ścieżek (każdy request powinien trafić na WAF, chyba że mamy twardy dowód, że nie musi) i zasada najmniejszych uprawnień dla wyjątków.

Badacze z FearsOff zrobili to, co społeczność powinna robić: wyłapali subtelny stan przejściowy i pokazali, że nie dotyczy on pojedynczej konfiguracji, tylko całej klasy ruchu. Cloudflare zareagował sprawnie i transparentnie opisał problem. To nie tylko „incydent załatany”, ale też użyteczne studium tego, jak drobna optymalizacja może rozluźnić właściwy tor kontroli.

Komentarz z dystansem

Nie każde „zero-day” to koniec świata, ale niemal każde przypomina, że Internet stoi na wyjątkach. Tu wyjątek dla ACME urósł ponad miarę. Dobrze, że poprawkę wdrożono szybko. Lepiej, żeby następnym razem testy jednostkowe i chaos engineering zapaliły lampkę wcześniej.

Podsumowanie

Błąd w obsłudze ACME na brzegu Cloudflare pozwalał na ominięcie WAF na specyficznej ścieżce i dotarcie do originów. Poprawka już działa, śladów nadużyć brak. Morał? Automatyzacja i „drobne” wyjątki są świetne, dopóki są precyzyjnie ograniczone. Gdy w grę wchodzą ścieżki obecne na każdym serwerze, margines błędu powinien wynosić dokładnie zero.

FAQ

Czy klienci Cloudflare muszą zrobić cokolwiek po tej poprawce?

Nie. Cloudflare wdrożył patch po swojej stronie i nie wymaga działań klientów.

Kiedy Cloudflare naprawił błąd ACME/WAF?

27 października 2025 r. – po zgłoszeniu 9 października i walidacji w dniach 13-14 października.

Czy są dowody, że podatność była wykorzystywana?

Nie. Cloudflare deklaruje, że nie ma dowodów na złośliwe wykorzystanie tej podatności.

Jak sprawdzić, czy mój origin był trafiany przez żądania na ścieżkę ACME?

Sprawdź logi originów pod kątem żądań do /.well-known/acme-challenge/ w okresie przed 27 października 2025 r.; nietypowe wzorce, nagłówki lub częstotliwość to sygnały do analizy.

Czy powinienem blokować ścieżkę /.well-known/acme-challenge/ na firewallu aplikacji?

Nie, blokada może złamać automatyczne wystawianie/odnawianie certyfikatów. Jeśli masz kontrolę nad ruchem, rozważ ścisłe allowlisty dla znanych adresów CA lub serwowanie tokenów z brzegu po stronie dostawcy CDN.

Źródła

• [1] https://thehackernews.com/2026/01/cloudflare-fixes-acme-validation-bug.html
• [2] https://blog.cloudflare.com/acme-path-vulnerability/
• [3] https://linkedin.com/pulse/cloudflare-fixes-zero-day-flaw-allowed-attackers-kiahe
• [4] https://gbhackers.com/cloudflare-zero-day-flaw-bypass-security/
• [5] https://cybersecuritynews.com/cloudflare-zero-day-vulnerability/
• [6] https://el-balad.com/6827011
• [7] https://filmogaz.com/107217
• [8] https://arstechnica.com/tech-policy/2025/11/cloudflare-broke-much-of-the-internet-with-a-corrupted-bot-management-file/