Node.js opublikował 21 października 2026 roku nowe wydania bezpieczeństwa dla trzech wspieranych linii: 22.x, 24.x i 26.x. Aktualizacje usuwają łącznie 10 podatności, w tym poważny błąd w dekoderze Brotli, który według projektu może umożliwić zdalne wykonanie kodu na podatnym systemie. Poprawki obejmują również weryfikację certyfikatów TLS, obsługę zapytań DNS, mechanizmy kryptograficzne oraz model uprawnień, enguide.pl podaje, powołując się nа thehackernews.com.
- Node.js 22.23.4, 24.22.1 i 26.12.1 naprawiają 10 podatności
- Luka Brotli w Node.js może prowadzić do zdalnego wykonania kodu
- Publiczny proof of concept nie potwierdził RCE na standardowej kompilacji
- Pozostałe podatności dotyczą TLS, DNS i kryptografii
- Node.js blokuje również skompromitowane certyfikaty eMudhra
- Zaktualizowano Undici, OpenSSL, c-ares i SQLite
- Jak zabezpieczyć aplikację Node.js?
Dostępne wersje naprawione to 22.23.4, 24.22.1 i 26.12.1. Administratorzy oraz programiści korzystający ze starszych wydań powinni sprawdzić środowiska produkcyjne, kontenery i procesy uruchomione na serwerach. Szczególnej uwagi wymagają aplikacje, które przetwarzają skompresowane dane pochodzące od użytkowników lub z zewnętrznych usług.
Node.js 22.23.4, 24.22.1 i 26.12.1 naprawiają 10 podatności
Zespół Node.js przygotował poprawki dla wszystkich trzech aktualnie wspieranych linii rozwojowych. Dwie z nich, 22.x i 24.x, należą do kanału długoterminowego wsparcia LTS, natomiast 26.x jest linią Current.
| Linia Node.js | Poprawiona wersja | Status |
|---|---|---|
| 22.x | 22.23.4 | LTS |
| 24.x | 24.22.1 | LTS |
| 26.x | 26.12.1 | Current |
Najpoważniejsza z naprawionych luk otrzymała oznaczenie CVE-2026-111497. Projekt sklasyfikował ją jako podatność o wysokim poziomie zagrożenia, wskazując możliwość zdalnego wykonania kodu. Trzy pozostałe luki również oceniono jako poważne, natomiast inne problemy otrzymały klasyfikację średnią lub niską.
„The highest severity issue fixed in this release is HIGH”.
Komunikat projektu wskazuje, że najwyższy poziom zagrożenia w tym zestawie aktualizacji to wysoki, a nie krytyczny. Nie oznacza to jednak, że problem można zignorować, szczególnie w aplikacjach przetwarzających niezaufane dane.
Aktualizacja środowiska uruchomieniowego jest podstawowym sposobem usunięcia opisanych podatności.
Wersje Node.js 20.x i starsze nie otrzymają tych poprawek, ponieważ zakończyły już okres wsparcia. Organizacje korzystające z tych wydań powinny przejść na wspieraną linię, a następnie przetestować działanie aplikacji po migracji.
Luka Brotli w Node.js może prowadzić do zdalnego wykonania kodu
Najważniejszy problem dotyczy dekodera Brotli, biblioteki kompresji, której kopię Node.js dołącza do własnego środowiska. Podatność CVE-2026-111497 wynika z zapisu poza granicami bufora podczas przetwarzania nieprawidłowo przygotowanych skompresowanych danych.
Taki błąd może naruszyć bezpieczeństwo pamięci procesu. Zgodnie z opisem projektu odpowiednio wykorzystana podatność może doprowadzić do zdalnego wykonania kodu (RCE), czyli sytuacji, w której atakujący uruchamia własny kod w podatnym środowisku.
Problem nie musi wynikać z błędu w kodzie napisanym przez programistę aplikacji. Node.js korzysta z własnej kopii dekodera, dlatego podatność może dotyczyć aplikacji, które nie implementują samodzielnie mechanizmów kompresji.
Ryzyko pojawia się przede wszystkim wtedy, gdy aplikacja dekoduje dane Brotli kontrolowane przez potencjalnego napastnika. Może to być treść żądania HTTP albo odpowiedź pobrana z innego serwera.
Dlaczego aplikacja może być podatna bez bezpośredniego używania Brotli?
Dekompresja może odbywać się automatycznie. Przykładowo funkcja fetch() w Node.js obsługuje odpowiedzi HTTP skompresowane z wykorzystaniem Brotli, a moduł node:zlib udostępnia funkcje związane z dekompresją.
Oznacza to, że programista nie musi bezpośrednio wywoływać dekodera Brotli, aby aplikacja korzystała z podatnego komponentu.
W praktyce należy zweryfikować przede wszystkim:
- aplikacje przyjmujące skompresowane treści od użytkowników;
- usługi pobierające dane z zewnętrznych serwerów przez
fetch(); - interfejsy API przetwarzające niezaufane żądania HTTP;
- procesy działające na starszych wersjach Node.js;
- wdrożenia korzystające z własnych obrazów kontenerowych i przypiętych wersji środowiska.
Lista ta nie oznacza, że każda aplikacja Node.js jest podatna w takim samym stopniu. Znaczenie ma sposób przetwarzania danych, źródło skompresowanej treści oraz wersja używanego środowiska.
Publiczny proof of concept nie potwierdził RCE na standardowej kompilacji
22 października opublikowano publiczny proof of concept, czyli demonstrację wykorzystania podatności. Według dostępnego opisu autor uzyskał wykonanie kodu wyłącznie w specjalnie osłabionej wersji testowej.
W przypadku standardowej kompilacji Node.js demonstracja doprowadziła do awarii procesu i ograniczonego odczytu pamięci, ale nie do wykonania dowolnego kodu. Autor nie zdołał więc wykazać skutecznego ataku RCE na zwykłym, niezmodyfikowanym środowisku.
To rozróżnienie jest istotne przy ocenie rzeczywistego ryzyka. Klasyfikacja podatności opisuje możliwe konsekwencje błędu, natomiast demonstracja wykorzystania pokazuje, co udało się osiągnąć w konkretnych warunkach testowych.
Brak udanego ataku na standardową kompilację nie oznacza, że podatność jest nieszkodliwa.
Poprawione wydania odrzucają nieprawidłowe dane wykorzystane w opisanym proof of concept. Według dostępnych informacji na 22 października 2026 roku nie zgłoszono wykorzystania tej luki w rzeczywistych atakach.
Pozostałe podatności dotyczą TLS, DNS i kryptografii
Październikowa aktualizacja obejmuje także błędy w innych elementach środowiska Node.js. Trzy z nich otrzymały wysoką ocenę zagrożenia i dotyczą mechanizmów, od których zależy bezpieczeństwo komunikacji sieciowej.
Dwa błędy odnoszą się do sprawdzania nazw hostów w certyfikatach TLS. W określonych warunkach nietypowy zapis adresu IP mógł prowadzić do zaakceptowania certyfikatu, który nie powinien zostać uznany za zgodny z danym hostem.
Trzecia luka dotyczy funkcji dns.resolve(). Podatność CVE-2026-105482 powodowała obcinanie nazw zawierających znak NUL, co mogło prowadzić do nieprawidłowej interpretacji przekazanego hosta.
Pozostałe problemy obejmują następujące obszary:
| Identyfikator CVE | Opis podatności | Poziom |
|---|---|---|
| CVE-2026-111497 | Zapis poza buforem w dekoderze Brotli, potencjalne RCE | Wysoki |
| CVE-2026-106069 | Ominięcie sprawdzania nazwy hosta TLS przy niestandardowym zapisie IP | Wysoki |
| CVE-2026-105483 | Błąd weryfikacji TLS przy adresie IP zapisanym pełnoszerokimi cyframi | Wysoki |
| CVE-2026-105482 | Obcinanie nazw z bajtem NUL w dns.resolve() | Wysoki |
| CVE-2026-105481 | Gniazdo keep-alive może przetworzyć odpowiedź zapisaną przed wysłaniem żądania | Średni |
| CVE-2026-106072 | Nieprawidłowa walidacja certyfikatu dla niestandardowego zapisu IPv4 | Średni |
| CVE-2026-106074 | Powtarzanie wartości randomUUID() i randomInt() w określonych snapshotach i aplikacjach SEA | Średni |
| CVE-2026-106070 | ZipFile może zwrócić kontrolowane przez atakującego bajty po błędnej walidacji nagłówka ZIP | Niski |
| CVE-2026-106071 | Nadmierne przyznawanie dostępu do plików przez wyszukiwanie wieloznaczne w Permission Model | Niski |
| CVE-2026-106073 | Ominięcie Permission Model z wykorzystaniem fs.realpathSync() | Niski |
W przypadku CVE-2026-106074 problem dotyczy aplikacji budowanych jako startup snapshot lub single-executable application (SEA). Bufory wartości losowych mogły być zachowywane w taki sposób, że kolejne procesy otrzymywały powtarzające się wyniki. Może to osłabić mechanizmy, które polegają na nieprzewidywalności tych wartości.
Warto też zwrócić uwagę na różnicę między oceną projektu a opisem konkretnej poprawki. CVE-2026-105483 otrzymało w zestawieniu Node.js poziom wysoki, choć sam opis zmiany naprawczej wskazywał na niższą ocenę i trudność wykorzystania błędu.
Node.js blokuje również skompromitowane certyfikaty eMudhra
Aktualizacje nie ograniczają się do 10 wymienionych podatności. Projekt zmienił także listę zaufanych certyfikatów w związku z wcześniejszym ujawnieniem kompromitacji ośmiu pośrednich kluczy urzędu certyfikacji należącego do indyjskiego dostawcy eMudhra.
Node.js korzysta z listy głównych certyfikatów Mozilla, ale domyślnie nie przeprowadza sprawdzania unieważnienia certyfikatów w taki sposób, który automatycznie wyeliminowałby wszystkie opisane przypadki. W efekcie łańcuch certyfikatów oparty na skompromitowanym kluczu mógł wcześniej przejść standardową walidację.
Nowe wydania wprowadzają blokadę ośmiu kluczy pośrednich oraz aktualizują dołączoną listę certyfikatów, usuwając trzy certyfikaty główne emSign. Podobną blokadę wdrożył projekt Go w aktualizacji opublikowanej 20 października.
Istnieje jednak ograniczenie dotyczące już nawiązanych połączeń. Sesje rozpoczęte przed aktualizacją nie są ponownie sprawdzane do czasu ich wygaśnięcia. Wersje Node.js, które zakończyły okres wsparcia, nie otrzymają również tej poprawki.
Zaktualizowano Undici, OpenSSL, c-ares i SQLite
Wraz z poprawkami bezpieczeństwa Node.js odświeżył kilka dołączonych zależności. Zaktualizowano między innymi bibliotekę Undici, która odpowiada za obsługę HTTP i stanowi zaplecze funkcji fetch().
Nowe wydanie Undici usuwa trzy problemy o umiarkowanym poziomie zagrożenia. Jeden dotyczy sprawdzania Subresource Integrity, a dwa pozostałe mogą prowadzić do wyczerpania pamięci, w tym w kliencie WebSocket dostępnym w Node.js.
Ponadto aktualizacje obejmują:
- c-ares we wszystkich trzech liniach wersji;
- OpenSSL w liniach 22.x i 24.x;
- SQLite w linii 22.x;
- aktualizacje list certyfikatów oraz innych dołączonych komponentów.
Takie zmiany mają znaczenie również dla aplikacji, których własny kod nie wykorzystuje bezpośrednio podatnych funkcji. Zależności środowiska mogą być uruchamiane przez biblioteki i mechanizmy działające w tle.
Jak zabezpieczyć aplikację Node.js?
Podstawowym działaniem jest instalacja poprawionej wersji środowiska i ponowne uruchomienie procesów korzystających ze starego wydania. Sama zmiana wersji w konfiguracji projektu nie wystarczy, jeżeli produkcyjny serwer lub kontener nadal działa na wcześniejszym obrazie.
Zalecana kolejność działań wygląda następująco:
- Sprawdź wersję Node.js poleceniem
node --version. - Zaktualizuj środowisko do wersji 22.23.4, 24.22.1 lub 26.12.1, zależnie od używanej linii.
- Przebuduj obrazy kontenerowe, jeśli zawierają starszą wersję Node.js.
- Uruchom ponownie wszystkie procesy i usługi korzystające z podatnego środowiska.
- Zweryfikuj, czy wdrożenie rzeczywiście korzysta z poprawionej wersji, a następnie przetestuj najważniejsze funkcje aplikacji.
W przypadku braku możliwości natychmiastowej aktualizacji projekt Node.js nie wskazuje tymczasowego obejścia, które usuwałoby ryzyko związane z błędem Brotli. Ograniczenia po stronie zapory mogą zmniejszyć część zagrożeń, ale nie zastępują poprawki.
Firma Vercel poinformowała o wdrożeniu 21 października reguł zapory blokujących ataki w przychodzących żądaniach. Mechanizm ten nie obejmuje jednak odpowiedzi Brotli pobieranych przez aplikację z innych serwerów.
Dla zespołów utrzymujących aplikacje najważniejsze pozostaje zatem sprawdzenie wszystkich środowisk uruchomieniowych, w tym systemów CI/CD, kontenerów oraz instancji, które mogą nie być objęte standardowym procesem aktualizacji.
Node.js naprawił 10 podatności, a najpoważniejsza z nich dotyczy dekodera Brotli i potencjalnej możliwości zdalnego wykonania kodu. Dostępność poprawek dla linii 22.x, 24.x i 26.x pozwala usunąć opisane problemy bez oczekiwania na kolejne wydanie główne. Organizacje korzystające z niewspieranych wersji powinny zaplanować migrację, ponieważ nie otrzymają ani poprawek Brotli, ani pozostałych aktualizacji bezpieczeństwa.
