Luka w Node.js i Brotli (Node2Shell): jak sprawdzić stronę

Stan na 1 listopada 2026 r. Projekt Node.js wydał 21 października poprawki bezpieczeństwa, a wśród nich poprawkę luki CVE-2026-111497, nazywanej Node2Shell. Błąd tkwi w Brotli, czyli bibliotece do rozpakowywania skompresowanych danych, którą Node.js ma w sobie. 27 października amerykańska agencja CISA dopisała tę lukę do katalogu luk wykorzystywanych w atakach.

Bez paniki: większość stron małych firm działa na WordPressie albo jako zwykłe pliki HTML i nie ma na serwerze Node.js. Jeśli jednak Twoja strona, sklep albo panel klienta działa na Next.js, Nuxt czy Express, sprawdź to jeszcze dziś. W tej poradzie pokazuję, jak w kilka minut ustalić, czy luka Cię dotyczy, które wersje mają poprawkę i co napisać do hostingu albo wykonawcy strony.

Co się stało

Brotli to sposób kompresji danych, trochę jak pakowanie plików do ZIP-a, opracowany przez Google i używany w całym internecie. W bibliotece Brotli w wersjach od 1.0.3 do 1.2.0 jest błąd: specjalnie przygotowane skompresowane dane mogą przy rozpakowaniu zapisać się poza miejscem w pamięci, które program na nie przeznaczył. Skutkiem może być awaria aplikacji, wyciek danych z pamięci serwera, a w najgorszym razie uruchomienie cudzego kodu z uprawnieniami Twojej aplikacji.

Najważniejsze daty:

• 21.10.2026: Node.js i Google wydały poprawki (Brotli 1.0.10, 1.1.1 i 1.2.1).
• 23–26.10.2026: poprawione pakiety biblioteki wydały Debian (DSA-6582-1) i Ubuntu (USN-8956-1), a 25 października Microsoft wydał poza zwykłym harmonogramem poprawki dla .NET.
• 27.10.2026: CISA dopisała lukę do katalogu Known Exploited Vulnerabilities, czyli luk wykorzystywanych w praktyce.

Co do początku ataków źródła się różnią. Według doniesień z 22 października nie było jeszcze znanych ataków. Firmy monitorujące ruch w sieci opisują skanowanie i pierwsze próby między 25 a 27 października, a CISA nie podała szczegółów. Część obserwowanych prób była nieudana, ale nawet nieudana próba może wyłączyć aplikację. Dlatego traktuj tę aktualizację jako pilną.

Kogo dotyczy luka w Node.js

Luka dotyczy programów, które rozpakowują dane Brotli otrzymane od kogoś obcego. W praktyce oznacza to:

• strony, sklepy i aplikacje działające na serwerze z Node.js: Next.js, Nuxt, Express i inne. Node.js ma Brotli wbudowane, więc liczy się wersja samego Node.js, a nie pakietów npm;
• aplikacje, które przyjmują skompresowane zapytania: na przykład Express 5 (przez body-parser 2.x) domyślnie rozpakowuje treść zapytań skompresowaną Brotli;
• aplikacje, które pobierają dane z cudzych serwerów: wbudowane fetch(), integracje, pobieranie zdjęć z innych adresów. Vercel wskazuje tu na przykład optymalizację obrazów w samodzielnie hostowanym Next.js;
• inne programy z biblioteką Brotli: .NET 8, 9 i 10 (Microsoft zaznacza, że rozpakowywanie Brotli nie jest tam domyślnie włączone), Bun, Envoy i systemowe pakiety libbrotli w Linuksie.

Kogo luka bezpośrednio nie dotyczy:

• stron statycznych, czyli gotowych plików HTML, na przykład z kreatora albo z Next.js wyeksportowanego do plików. Node.js działa wtedy tylko na komputerze, na którym strona jest budowana, a nie na serwerze;
• WordPressa i innych stron na PHP, bo nie działają na Node.js. Serwer może jednak mieć systemową bibliotekę Brotli, więc aktualizacja systemu i tak jest potrzebna. To zadanie hostingu.

Jedno wyjaśnienie, bo to częste pytanie: kompresja Brotli, którą serwer pakuje strony wysyłane do przeglądarek, to nie jest ta luka. Błąd dotyczy rozpakowywania danych od obcych. Nie wyłączaj kompresji, bo strona zwolni, a problemu to nie rozwiąże.

Które wersje Node.js mają poprawkę

Stan na 1.11.2026 według komunikatu Node.js z 21 października i listy wydań Node.js:

Linie bez wsparcia są podatne i nie dostaną poprawki. Node.js pisze wprost, że wersje po końcu wsparcia są zawsze objęte lukami z kolejnych wydań bezpieczeństwa. Po 21 października wyszły już kolejne wydania: 24.22.2 (27 października) i 26.13.0 (28 października, od tej wersji linia 26.x ma status LTS). Zawierają one tę samą poprawkę, a przed aktualizacją i tak sprawdź najnowszą wersję na stronie nodejs.org.

To samo wydanie poprawia jeszcze dziewięć innych błędów, między innymi w sprawdzaniu certyfikatów TLS. Jedna aktualizacja załatwia wszystkie.

Jak sprawdzić, czy Twoja strona jest narażona

Bez programisty: 5 minut

1. Kod strony. Otwórz stronę w przeglądarce, wciśnij Ctrl+U (podgląd źródła), potem Ctrl+F i wpisz _next. Jeśli są wyniki, strona jest zbudowana w Next.js. Dla Nuxt szukaj _nuxt. To jeszcze nie przesądza, czy Node.js działa na serwerze, ale mówi, że warto pytać dalej.
2. Nagłówki. Wciśnij F12, przejdź do zakładki Sieć (Network), odśwież stronę i kliknij pierwszy wiersz. W nagłówkach odpowiedzi poszukaj x-powered-by. Wartość Next.js albo Express oznacza Node.js na serwerze. Brak tego nagłówka niczego nie dowodzi, bo wielu wykonawców go ukrywa.
3. Panel hostingu. Jeśli strona stoi na Vercelu, wersję Node.js widać w ustawieniach projektu. W panelach hostingowych z obsługą aplikacji Node.js wersja jest zwykle podana przy aplikacji.
4. Zapytaj wykonawcę. To najszybsze i najpewniejsze. Gotową wiadomość znajdziesz niżej.

Dla osoby, która wdraża

Sprawdź wersję wszędzie, gdzie działa kod: na serwerze, w każdym kontenerze, w środowisku testowym i w CI.

# wersja Node.js
node -v

# wersja Node.js w obrazie Dockera
docker run --rm <obraz> node -v

# Debian i Ubuntu: wersja systemowej biblioteki Brotli
dpkg -l | grep -i brotli

Trzy pułapki:

• Obrazy Dockera zbudowane przed 21.10 mają starą wersję, dopóki ich nie przebudujesz z nowego obrazu bazowego.
• Node.js z pakietów systemowych może korzystać z systemowej biblioteki libbrotli. Porównaj jej wersję z trackerem Debiana albo komunikatem Ubuntu USN-8956-1.
• Działający proces używa starej wersji, dopóki nie uruchomisz go ponownie.

Co zrobić dziś

1. Ustal, czy masz Node.js na serwerze (poprzednia sekcja). Jeśli nie, przejdź do punktu 6.
2. Zrób kopię zapasową kodu, bazy i konfiguracji. Jak zrobić ją porządnie, opisuję w poradzie o kopii zapasowej strony i zasadzie 3-2-1.
3. Zaktualizuj Node.js do wersji z tabeli w ramach tej samej linii. Taka aktualizacja zwykle nie wymaga zmian w kodzie.
4. Uruchom aplikację ponownie albo wdróż ją od nowa, a obrazy Dockera przebuduj. Na Vercelu przy projektach na 22.x i 24.x wystarczy ponowne wdrożenie.
5. Na Node.js 20.x albo innej linii bez wsparcia nie czekaj na poprawkę, bo jej nie będzie. Przejdź na 22.x, 24.x albo 26.x: najpierw na kopii testowej, potem na stronie, w najbliższych dniach.
6. Zapytaj hosting o aktualizację systemowych pakietów Brotli, także jeśli masz WordPressa.

Jeśli aktualizacja musi poczekać kilka dni, firmy zajmujące się bezpieczeństwem (m.in. Aikido i ELLIO) radzą tymczasowo odrzucać przychodzące zapytania skompresowane Brotli (nagłówek Content-Encoding: br) na serwerze proxy, zaporze albo w samej aplikacji. To zabezpieczenie tylko na chwilę: nie chroni przed danymi pobieranymi z cudzych serwerów i nie zastępuje aktualizacji. Vercel 21 października włączył dla wszystkich projektów reguły zapory przeciw tej luce, ale sam zaznacza, że nie zastępują one aktualizacji Node.js.

Po aktualizacji poproś o przejrzenie logów od 21 października: czy aplikacja nie restartowała się nietypowo często i czy nie pojawiły się nieznane pliki, procesy albo konta. Jeśli coś budzi wątpliwości, zgłoś incydent do CERT Polska.

Co zlecić hostingowi albo wykonawcy strony

Kto aktualizuje Node.js, zależy od tego, gdzie działa strona:

Gotowa wiadomość do skopiowania:

Dzień dobry, 21 października Node.js wydał poprawki bezpieczeństwa, w tym poprawkę luki CVE-2026-111497 (Node2Shell, Brotli). Proszę o informację:

1. Czy nasza strona lub aplikacja działa na serwerze z Node.js, a jeśli tak, w jakiej wersji?
2. Czy Node.js został zaktualizowany do wersji 22.23.4, 24.22.1, 26.12.1 lub nowszej i czy aplikację uruchomiono ponownie?
3. Czy na serwerze zaktualizowano systemowe pakiety Brotli?
4. Czy w logach od 21 października widać coś niepokojącego? Dziękuję i proszę o odpowiedź w ciągu 2 dni roboczych.

Jeśli wykonawca nie odpowiada albo strona nie ma nikogo, kto dba o aktualizacje, to sygnał, że trzeba to uporządkować. Mogę przejąć opiekę nad stroną, a jeśli wolisz, żeby działała na serwerze, którym zajmuję się sam, zapewnię też domenę i hosting (od 390 zł/rok netto, serwer w Polsce lub UE).

Wersje bez wsparcia: lekcja na przyszłość

Node.js 20.x nie dostał poprawki, bo jego wsparcie już się skończyło. To ten sam mechanizm co przy PHP: o końcu wsparcia PHP 8.2, który przypada 31.12.2026, pisałem niedawno. Wersja bez wsparcia działa normalnie aż do dnia, w którym pojawia się luka. Wtedy zamiast prostej aktualizacji czeka Cię przeprowadzka na nowszą wersję pod presją czasu.

Dlatego raz na kwartał sprawdź trzy rzeczy:

• na jakiej wersji Node.js albo PHP działa strona i do kiedy ta wersja ma wsparcie,
• kto ma w umowie obowiązek aktualizacji i w jakim czasie reaguje na pilne luki,
• czy kopię zapasową da się naprawdę przywrócić.

W najbliższych dniach w serii „Luki i podatności” opiszę między innymi październikowe poprawki w Next.js i React oraz to, kto odpowiada za aktualizacje: hosting, wykonawca czy właściciel firmy.

Podsumowanie

Node2Shell to poważna luka, ale dla większości firm naprawa jest prosta: aktualizacja Node.js do wersji 22.23.4, 24.22.1, 26.12.1 lub nowszej i ponowne uruchomienie aplikacji. Najwięcej pracy mają strony na Node.js 20.x i innych liniach bez wsparcia, bo tam trzeba przejść na nowszą linię. Jeśli nie wiesz, na czym działa Twoja strona, wyślij wykonawcy wiadomość z tej porady jeszcze dziś.

Jeśli nikt nie zajmuje się aktualizacjami Twojej strony, napisz do mnie. W ramach opieki technicznej monitoruję stronę, robię kopie zapasowe i instaluję aktualizacje bezpieczeństwa. Do wyboru są trzy pakiety: Czuwanie od 149 zł/mies. netto (pilne aktualizacje w 2 dni), Standard od 349 zł/mies. netto (reakcja w 1 dzień roboczy) i Pro od 749 zł/mies. netto (reakcja w 4 godziny). Audyt bezpieczeństwa (od 990 zł netto) pokaże, co jeszcze wymaga poprawy. Odpowiadam w 24 godziny, a nowi klienci dostają 20% rabatu na pierwsze zlecenie.