Krytyczna luka w Node.js (CVE-2026-111497). Jak sprawdzić, czy Cię dotyczy

21 października zespół Node.js wydał poprawki bezpieczeństwa dla gałęzi 22.x, 24.x i 26.x. Najpoważniejsza z naprawionych luk, CVE-2026-111497, to błąd o wysokiej krytyczności w dekoderze Brotli, czyli w kodzie, którym Node.js rozpakowuje dane skompresowane tym algorytmem. Spreparowane dane mogą doprowadzić do wycieku pamięci procesu albo do wykonania dowolnych poleceń z uprawnieniami aplikacji. To samo wydanie łata dziewięć innych problemów, w tym dwa (również o wysokiej krytyczności) pozwalające obejść weryfikację nazwy hosta w TLS.

Co to właściwie jest

Brotli to popularny format kompresji, używany m.in. do przesyłania stron i odpowiedzi API (nagłówek Content-Encoding: br). Node.js ma wbudowany dekoder Brotli w module zlib. Błąd polega na tym, że źle sformowane dane wejściowe powodują zapis poza przydzielonym obszarem pamięci (out-of-bounds write). Badacze pokazali, że da się w ten sposób odczytać fragmenty pamięci procesu, a także uruchomić polecenie na serwerze.

Ważne zastrzeżenie: aplikacja jest narażona tylko wtedy, gdy ona sama albo któraś z jej bibliotek rozpakowuje dane Brotli, na które ma wpływ atakujący. W praktyce chodzi o dwie sytuacje:

• dane przychodzące - skompresowane ciało żądania wysłane do Twojego API,
• dane pobierane - odpowiedź z zewnętrznego serwera, którą Twoja aplikacja ściąga (np. obrazek, plik, odpowiedź innego API) i rozpakowuje.

Problem w tym, że rozpakowywanie często dzieje się „samo”, w bibliotece HTTP albo parserze żądań, a nie w kodzie, który ktoś w zespole świadomie napisał. Dlatego samo przeszukanie repozytorium nie daje pewności i rozsądniej jest założyć, że luka Cię dotyczy, dopóki nie zaktualizujesz.

Jak sprawdzić, czy Cię dotyczy

1. Ustal, gdzie działa Node.js

Na serwerze wystarczy:

node -v

Nie zapomnij o miejscach mniej oczywistych: obrazy Dockera (wersja Node.js siedzi w obrazie bazowym, nie na hoście), maszyny i runnery CI/CD, serwery z samodzielnie hostowanym Next.js, Nuxt czy innym frameworkiem, mikroserwisy postawione przez zewnętrznego wykonawcę, a także środowiska deweloperskie. W kontenerze wersję sprawdzisz tak:

docker run --rm --entrypoint node twoj-obraz:tag -v

2. Porównaj wersję z załatanymi

Bezpieczne wydania z 21 października:

• Node.js 26.12.1
• Node.js 24.22.1
• Node.js 22.23.4

Niższa wersja w danej gałęzi oznacza podatność. Node.js 20 i starsze nie są już wspierane i nie dostaną poprawki - jedyna droga to migracja na 22.x lub 24.x.

3. Zobacz, czy aplikacja przetwarza Brotli

Jako szybki trop przeszukaj kod pod kątem bezpośredniego użycia dekodera:

grep -rn "BrotliDecompress\|brotliDecompress" --include=*.js --include=*.ts . | grep -v node_modules

Brak wyników nie oznacza jednak bezpieczeństwa - jak wyżej, dekompresję może wykonywać klient HTTP lub middleware. Ten krok pomaga raczej ustalić priorytet niż zamknąć temat.

Co zrobić

1. Zaktualizuj Node.js do jednej z wersji wymienionych wyżej i zrestartuj aplikację. To jedyne pełne rozwiązanie.
2. Przebuduj obrazy kontenerów na załatanym obrazie bazowym (np. podbij tag node:24 do aktualnego wydania) i wdroż je ponownie. Stary, zbudowany wcześniej obraz pozostaje podatny, nawet jeśli host jest aktualny.
3. Zaktualizuj runnery CI i środowiska lokalne - to też procesy Node.js, które pobierają dane z internetu.
4. Jeśli korzystasz z Vercela: projekty na Node.js 22.x i 24.x dostaną poprawkę automatycznie, bo Vercel sam zarządza wersjami patchy. Projekty na Node.js 20.x trzeba przestawić na 22.x lub 24.x i wdrożyć ponownie. Vercel wdrożył też reguły WAF blokujące atak w ruchu przychodzącym, ale sam zaznacza, że nie chronią one odpowiedzi pobieranych przez Twoje funkcje z innych serwerów i nie zastępują aktualizacji.
5. Samodzielnie hostowany Next.js: zaktualizuj Node.js. Według Vercela optymalizacja obrazów w Next.js nie blokuje odpowiedzi skompresowanych Brotli, więc pobieranie zdalnych obrazów to potencjalna ścieżka ataku.
6. Backend za proxy lub CDN: poza aktualizacją ogranicz bezpośredni dostęp do serwera, tak żeby ruch docierał wyłącznie przez warstwę, która go filtruje.
7. Przejrzyj logi pod kątem nietypowych żądań ze skompresowanym ciałem i niespodziewanych awarii procesu. Przy podejrzeniu, że ktoś zdążył wykorzystać lukę, sama aktualizacja nie wystarczy.

Dlaczego warto nie odkładać tego na później

WAF-y i dostawcy chmurowi szybko reagują na takie luki, co łatwo uśpić czujność. Tymczasem ochrona na brzegu sieci obejmuje tylko ruch przychodzący, a ta podatność działa także w drugą stronę: wystarczy, że aplikacja pobierze spreparowaną odpowiedź z serwera kontrolowanego przez atakującego. Funkcje typu „podaj adres obrazka” czy integracje z zewnętrznymi API to dokładnie te miejsca, w których to się dzieje.

Druga lekcja dotyczy wersji poza wsparciem. Node.js 20 nie dostanie poprawki, więc każda aplikacja, która na nim została, od dziś ma znaną, niełataną lukę. Jeśli nie wiesz, na jakich wersjach działają Twoje usługi, to dobry moment, żeby to spisać.

Źródła

Opracowano na podstawie komunikatu Vercel (Node.js security advisory) oraz informacji o październikowym wydaniu bezpieczeństwa na nodejs.org. Szczegóły mogą być jeszcze aktualizowane.