Brotli CVE-2026-111497: podatny dekoder w Node.js, Envoy i aplikacjach webowych

Ujawniona podatność CVE-2026-111497 pokazuje, że mechanizm kompresji może stać się zdalną powierzchnią ataku. Błąd przepełnienia bufora znajduje się w dekoderze Brotli i dotyczy wersji biblioteki od 1.0.3 do 1.2.0. Odpowiednio przygotowany strumień może uszkodzić sąsiedni stan w pamięci, ujawnić jej zawartość, doprowadzić do odmowy usługi albo potencjalnie pozwolić na wykonanie kodu.

Problem nie ogranicza się do aplikacji, które jawnie instalują pakiet o nazwie Brotli. Podatny kod może być wbudowany w runtime, proxy, obraz kontenera albo samodzielne narzędzie. Node.js ocenił lukę jako wysoką i wydał naprawione wersje 22.23.4, 24.22.1 oraz 26.12.1. Envoy wskazał własne podatne wydania i poprawki. Microsoft opisał natomiast ochronę dla ruchu przychodzącego w Azure Web Application Firewall.

Wniosek Breachroad: firma powinna szukać nie tylko zależności w pliku projektu, ale również środowisk uruchomieniowych i gotowych obrazów. WAF może ograniczyć jedną drogę ataku, lecz nie naprawi procesu, który pobiera i rozpakowuje dane poza ruchem przechodzącym przez bramę.

Co dokładnie jest podatne

Opis CVE wskazuje na dekoder w c/dec/decode.c biblioteki Google Brotli na wszystkich platformach. Atakujący nie potrzebuje uwierzytelnienia, jeśli aplikacja przyjmuje z kontrolowanego przez niego źródła dane skompresowane Brotli i przekazuje je do podatnego dekodera.

Upstream rekomenduje przejście na odpowiednią poprawioną gałąź: 1.0.10, 1.1.1 albo 1.2.1. Wybór zależy od używanej linii i sposobu dostarczenia biblioteki. W Node.js naprawione są wymienione wydania 22.x, 24.x i 26.x.

Envoy potwierdził podatność wydań 1.39.2, 1.38.5, 1.37.7 i 1.36.11, jeżeli skonfigurowano dekompresor Brotli. Producent wskazuje jako poprawione 1.40.0, 1.39.3, 1.38.6, 1.37.8 i 1.36.12. To dobry przykład, dlaczego samo pytanie „czy używamy Brotli?” jest zbyt ogólne — znaczenie ma komponent, kierunek danych i aktywna konfiguracja.

Gdzie szukać ekspozycji

Pierwszym miejscem są usługi Node.js, zwłaszcza te, które przyjmują skompresowane żądania albo samodzielnie pobierają odpowiedzi HTTP i je rozpakowują. Następnie należy sprawdzić:

• reverse proxy i service mesh oparte na Envoy;
• funkcje serverless i obrazy kontenerowe z własnym runtime Node.js;
• narzędzia bezpieczeństwa, generatory SBOM i skanery uruchamiane na nieufnych repozytoriach;
• aplikacje w Pythonie lub innych językach, które zawierają własną kopię biblioteki;
• instalatory i samodzielne binaria, które nie korzystają z systemowego pakietu;
• usługi przyjmujące żądania z nagłówkiem Content-Encoding: br;
• procesy pobierające dane z adresu wskazanego przez użytkownika, webhook lub zawartość projektu.

Inwentaryzacja pakietów aplikacji może nie wykazać runtime’u zaszytego w obrazie. Trzeba więc połączyć SBOM, skanowanie obrazu, odczyt wersji uruchomieniowej i analizę rzeczywistego przepływu danych.

Co robi Azure WAF i gdzie kończy się jego ochrona

Microsoft podaje, że Azure WAF z DRS 2.2 na Application Gateway albo Azure Front Door Premium domyślnie używa reguły 920450, która obejmuje Content-Encoding. W trybie Prevention dopasowanie ma krytyczny wynik anomalii i blokuje analizowane żądanie.

Dla starszych zestawów reguł, wyłączonej reguły 920450 albo Azure Front Door Standard Microsoft proponuje regułę niestandardową blokującą przychodzące żądania, których Content-Encoding zawiera br. Przed przejściem z logowania do blokowania trzeba sprawdzić, czy legalni klienci nie przesyłają skompresowanych w ten sposób danych.

Ograniczenie jest ważne: Azure WAF widzi ruch przychodzący do aplikacji. Nie ochroni procesu, który sam pobiera odpowiedź Brotli z internetu, kolejki, repozytorium lub innego systemu. Nie zastąpi też aktualizacji biblioteki, runtime’u i obrazu.

Plan działania dla firmy

1. Zbuduj listę runtime’ów i produktów

Zbierz wersje Node.js z produkcji, testów, CI/CD, kontenerów i funkcji serverless. Osobno odszukaj Envoy, ingressy, service mesh, narzędzia skanujące i binaria zawierające własny runtime. Nie ograniczaj kontroli do repozytoriów aktywnie rozwijanych.

2. Potwierdź, czy dane są dekompresowane

Ustal, które komponenty przyjmują skompresowane ciała żądań, a które pobierają treść zewnętrzną. Własność i osiągalność są ważniejsze niż sama obecność pliku biblioteki: komponent nieosiągalny z nieufnych danych może mieć inny priorytet niż publiczne API.

3. Zaktualizuj źródło rzeczywistego runtime’u

Jeżeli aplikacja używa obrazu bazowego, nowy wpis w package.json nie wystarczy. Zbuduj obraz ponownie na poprawionej wersji i sprawdź ją już w uruchomionym artefakcie. Dla gotowego urządzenia lub usługi zarządzanej uzyskaj od dostawcy potwierdzenie wpływu i poprawione wydanie.

4. Wprowadź ochronę tymczasową

Jeżeli aktualizacja wymaga czasu, ogranicz przychodzące żądania Brotli na brzegu tam, gdzie aplikacja ich nie potrzebuje. Najpierw sprawdź logi, a po włączeniu blokowania obserwuj błędy klientów i próby obejścia. Traktuj regułę jako barierę przejściową z właścicielem i datą usunięcia.

5. Zweryfikuj procesy wychodzące

Przejrzyj webhooki, importy, skanowanie repozytoriów, generowanie SBOM i integracje pobierające pliki. Ogranicz dozwolone hosty i typy treści, a nieufne przetwarzanie izoluj. WAF przed publicznym API nie widzi tych przepływów.

6. Potwierdź naprawę dowodem

Zapisz wersję przed i po zmianie, identyfikator obrazu, wynik skanowania oraz test, że aplikacja nadal działa. Kontrola powinna obejmować wszystkie repliki i zadania okresowe, nie tylko jeden pod.

Jak rozmawiać z dostawcą

Zapytaj, czy produkt zawiera Brotli bezpośrednio, przez Node.js, Envoy albo inny komponent. Poproś o dokładną wersję poprawioną, datę wydania i informację, czy wymagane jest ponowne wdrożenie obrazu. Jeżeli dostawca twierdzi, że produkt nie jest podatny, potrzebna jest przyczyna: brak wadliwej wersji, wyłączony dekoder czy brak ścieżki od nieufnych danych.

Odpowiedź „mamy WAF” nie zamyka sprawy. Wymaga doprecyzowania wersji zestawu reguł, trybu Prevention, ewentualnych wyjątków i tego, czy komponent wykonuje połączenia wychodzące.

Fakty źródłowe i wnioski Breachroad

Opis CVE i advisory producentów potwierdzają podatne wersje Brotli, możliwe skutki, poprawione wydania Node.js i Envoy oraz warunek użycia dekodera. Microsoft opisuje domyślną ochronę DRS 2.2, możliwość użycia reguły niestandardowej i ograniczenie WAF do ruchu przychodzącego.

Priorytetyzacja przepływów, kontrola gotowych obrazów, pytania do dostawcy i wymagania dowodowe są rekomendacjami Breachroad. Włącz je do procesu zarządzania podatnościami i przeglądu bezpieczeństwa łańcucha dostaw oprogramowania. Zespoły mogą przećwiczyć wspólną reakcję podczas szkoleń cyberbezpieczeństwa dla organizacji, a rzeczywistą ekspozycję aplikacji sprawdzić w ramach audytu bezpieczeństwa IT.

Źródła pierwotne: GitHub Advisory Database — CVE-2026-111497, Node.js — October 2026 Security Releases, Envoy — Out-of-Bounds Write in Brotli Decompressor, Microsoft — ochrona Azure WAF.