Wprowadzenie do problemu / definicja
Node2Shell to nazwa demonstracji ataku, która pokazuje, że błąd w dekoderze Brotli dołączanym do Node.js może prowadzić do zdalnego wykonania kodu. Podatność została opisana jako CVE-2026-111497 i dotyczy scenariuszy, w których proces Node.js dekompresuje niezaufane dane Brotli.
To istotny przypadek z perspektywy bezpieczeństwa aplikacji, ponieważ problem nie wynika z błędnej logiki biznesowej ani z pojedynczego frameworka, lecz z komponentu runtime’u. Oznacza to, że zagrożenie może dotyczyć zarówno aplikacji serwerowych, jak i usług pobierających skompresowane odpowiedzi z zewnętrznych systemów.
W skrócie
Badacze bezpieczeństwa pokazali działający proof-of-concept RCE przeciwko oficjalnemu buildowi Node.js 24.22.0 dla Linux arm64. Atak wykorzystywał specjalnie spreparowane dane Brotli dostarczane w odpowiedzi HTTP przetwarzanej przez wbudowane fetch() oraz w ciele żądania HTTP dekodowanym przez middleware aplikacyjne.
- Podatność oznaczono jako CVE-2026-111497.
- Źródłem problemu jest błąd out-of-bounds write w dekoderze Brotli.
- Poprawki opublikowano 21 października 2026 roku.
- Naprawione wersje to 22.23.4, 24.22.1 oraz 26.12.1.
- W chwili publikacji nie raportowano aktywnego wykorzystania w środowiskach produkcyjnych.
Kontekst / historia
Podatność dotyczy samego Node.js, a nie konkretnej biblioteki webowej. Praktyczna ekspozycja zależy jednak od tego, czy aplikacja doprowadza niezaufane dane do podatnego dekodera Brotli. W praktyce może się to wydarzyć zarówno po stronie klienta HTTP, jak i po stronie serwera przy obsłudze skompresowanych żądań.
Badania wskazały, że znaczenie operacyjne mają także popularne ścieżki wejściowe związane z middleware przetwarzającym ciała żądań. W testach pojawiały się między innymi stosy oparte o Express 5.x oraz body-parser 2.x, ale nie one były źródłem błędu. Problem znajdował się niżej, w natywnym komponencie odpowiedzialnym za dekompresję Brotli w runtime’ie Node.js.
Analiza techniczna
Sedno podatności polega na nieprawidłowej obsłudze niemożliwego stanu w strumieniu Brotli. Spreparowane dane prowadziły parser do przejścia, które z punktu widzenia formatu nie powinno wystąpić. Zamiast zakończyć przetwarzanie błędem, podatny dekoder kontynuował pracę tak, jakby oczekiwał kolejnych bajtów wejściowych.
W efekcie dochodziło do zapisu poza zakresem przewidzianego bufora, czyli klasycznego błędu out-of-bounds write. Taki stan mógł prowadzić do kilku skutków bezpieczeństwa: od awarii procesu, przez potencjalne ujawnienie fragmentów pamięci, aż po zdalne wykonanie kodu. Demonstracja badaczy potwierdziła, że w określonej konfiguracji możliwe było uruchomienie kodu dostarczonego wraz z danymi Brotli.
Istotne jest również to, że proof-of-concept działał na oficjalnym buildzie Node.js 24.22.0 dla Linux arm64, bez niestandardowej kompilacji. Atak został odtworzony zarówno przez odpowiedź HTTP konsumowaną przez fetch(), jak i przez przychodzące ciało żądania obsługiwane przez parsery raw() oraz json(). Choć exploit nie był w pełni deterministyczny i wymagał wielu prób, sama możliwość osiągnięcia RCE znacząco podnosi wagę incydentu.
Producent naprawił problem poprzez zaimportowanie poprawki upstream dla Brotli. Po wdrożeniu zmian dekoder przerywa przetwarzanie i zgłasza błąd formatu w miejscu, w którym wcześniej kontynuował pracę na nieprawidłowym stanie wewnętrznym.
Konsekwencje / ryzyko
Skala ryzyka zależy przede wszystkim od tego, czy organizacja korzysta z podatnych linii Node.js i czy jej aplikacje dekompresują niezaufane dane Brotli. Najbardziej narażone są backendy, API oraz usługi integracyjne, które komunikują się z systemami zewnętrznymi lub akceptują skompresowane ciała żądań.
- Ryzyko dotyczy ścieżek pobierających skompresowane odpowiedzi HTTP z zewnętrznych źródeł.
- Zagrożone są aplikacje przyjmujące żądania ze skompresowanym ciałem.
- Problem może pozostać niewidoczny przy standardowej inwentaryzacji zależności NPM.
- Podatny runtime może znajdować się w kontenerze, pipeline CI/CD lub zarządzanym środowisku uruchomieniowym.
Z obronnego punktu widzenia to szczególnie ważne, ponieważ problem występuje w warstwie runtime. Nawet organizacje, które nie wystawiają publicznych endpointów obsługujących Brotli, mogą pozostawać narażone przez odbiór złośliwie spreparowanej odpowiedzi z systemu zewnętrznego. Tym samym model zagrożenia wykracza poza klasyczny scenariusz ataku na publiczne API.
Rekomendacje
Najważniejszym działaniem jest jak najszybsza aktualizacja Node.js do wersji zawierających poprawkę. W praktyce oznacza to wdrożenie co najmniej wersji 22.23.4, 24.22.1 lub 26.12.1, ewentualnie nowszych wydań z odpowiedniej linii.
- Przeprowadzić przegląd środowisk uruchomieniowych, kontenerów i artefaktów zawierających binaria Node.js.
- Zidentyfikować aplikacje dekompresujące niezaufane dane Brotli po stronie klienta i serwera.
- Ograniczyć lub czasowo wyłączyć akceptację Brotli na najbardziej ryzykownych ścieżkach, jeśli aktualizacja nie jest możliwa natychmiast.
- Monitorować awarie procesu, błędy dekodera i anomalie związane z przetwarzaniem skompresowanych danych.
- Wdrożyć tymczasowe mechanizmy ochronne, takie jak reguły WAF lub wirtualne łatki, pamiętając, że nie zastępują one aktualizacji runtime’u.
- Zweryfikować obecność starszych, niewspieranych linii Node.js i zaplanować ich migrację.
Warto też uwzględnić ten przypadek w modelowaniu zagrożeń dla aplikacji Node.js. Kompresja HTTP często bywa traktowana jako detal transportowy, jednak ten incydent pokazuje, że implementacja dekodera może stać się bezpośrednim wektorem kompromitacji procesu aplikacyjnego.
Podsumowanie
Node2Shell to ważne ostrzeżenie dla zespołów rozwijających i utrzymujących aplikacje oparte na Node.js. CVE-2026-111497 pokazuje, że niskopoziomowy błąd w dekoderze kompresji może przełożyć się na realny scenariusz zdalnego wykonania kodu, jeśli aplikacja przetwarza niezaufane dane Brotli.
Dla organizacji kluczowe są trzy działania: szybka aktualizacja runtime’u, identyfikacja wszystkich ścieżek dekompresji oraz pełna inwentaryzacja artefaktów zawierających podatne wersje Node.js. To właśnie połączenie tych kroków pozwala skutecznie ograniczyć ryzyko związane z Node2Shell.
Źródła
- The Hacker News — Researchers Demonstrate Node2Shell RCE Exploit on Node.js Build Using Crafted Brotli Data — https://thehackernews.com/2026/10/researchers-demonstrate-node2shell-rce.html
- Node.js — Wednesday, October 21, 2026 Security Releases — https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
- Imperva — Node2Shell: From Brotli Data to Remote Code Execution — https://www.imperva.com/blog/node2shell-from-brotli-data-to-remote-code-execution/