Node.js: luki HTTP/2 i HTTPS pozwalają klientom wywoływać awarie serwerów i odczytywać dane innych użytkowników

Co się stało

W dniu 11 listopada 2026 roku projekt Node.js opublikował wydania bezpieczeństwa dla trzech obsługiwanych linii wydań. Poprawione wersje to 22.23.5, 24.22.3 i 26.13.1. Naprawiono w nich 16 podatności w samym Node.js, z czego siedem oznaczono jako wysokie. Wydania aktualizują także dołączone zależności: llhttp (22.x, 24.x, 26.x), undici (24.x, 26.x) oraz sqlite (22.x, 24.x).

Najważniejsze problemy dotyczą kodu serwerowego, który Node.js udostępnia samodzielnie dla HTTP/2, HTTPS i TLS:

• Awaria serwera HTTP/2 (24.x i 26.x): dowolny niezalogowany klient może zatrzymać proces Node.js. Serwer potrzebuje jedynie domyślnej konfiguracji HTTP/2 oraz handlera, który odpowiada, zanim treść żądania dotrze w całości. Projekt określa to zachowanie jako typowe. Atak działa zarówno przez TLS, jak i przez połączenia bez szyfrowania.
• Ujawnienie pamięci w HTTP/2 (wszystkie trzy linie): serwer może wysłać klientowi fragmenty swojej pamięci, w tym odpowiedzi przeznaczone dla innych połączeń. Od wersji 24.22.0 i 26.9.0 klient może wywołać to samodzielnie. W buildach 22.x oraz starszych 24.x i 26.x może to nastąpić, gdy serwer zamknie strumień w trakcie wysyłania odpowiedzi, na przykład po przekroczeniu limitu bezczynności.
• Ujawnienie pamięci w HTTPS (wszystkie trzy linie): niezalogowany klient może odczytać pamięć z innych połączeń, "w tym prywatne klucze TLS i żądania innych użytkowników", według projektu. Wymaga to handlera, który wywołuje res.flushHeaders() przed zakończeniem treści żądania, a następnie res.end() z danymi. Aby odczytać wyciekłą pamięć, atakujący potrzebuje też trasy, która odsyła lub zapisuje treść żądania.
• Wyczerpanie zasobów w HTTP/2 (wszystkie trzy linie): klient może spowodować, że dowolny domyślny serwer HTTP/2 będzie trwale trzymał pamięć i deskryptory plików.
• Obsługa plików w HTTP/2 (24.x i 26.x): klient może uszkodzić pamięć serwera, gdy serwer udostępnia pliki za pomocą stream.respondWithFile() lub stream.respondWithFD(). We wszystkich trzech liniach anulowanie takich pobrań może również spowodować awarię serwera (oceniono jako średnią).
• Awaria serwera TLS (24.x i 26.x): klient może spowodować awarię serwera TLS, który korzysta z hooków SNICallback, OCSPRequest, newSession lub resumeSession albo z server.addContext().
• Obejście kontroli certyfikatów klienta w TLS (wszystkie trzy linie): niektóre serwery stosują surowsze reguły certyfikatów klienta dla określonych nazw hostów. Na takich serwerach klient zatwierdzony dla innej nazwy hosta może przejść na surowszą, podczas renegocjacji TLS 1.2, bez spełnienia jej reguł.

W zaleceniu nie zgłoszono żadnych ataków wykorzystujących te luki.

Kogo to dotyczy

• Serwery działające na Node.js 22.x przed 22.23.5, 24.x przed 24.22.3 lub 26.x przed 26.13.1.
• Linie po zakończeniu wsparcia, w tym 20.x i 25.x, nie otrzymują poprawki w tym wydaniu. Projekt podaje, że takie wersje są zawsze podatne.
• Poważne problemy po stronie serwera dotyczą wyłącznie sytuacji, w której proces Node.js sam przyjmuje połączenia HTTP/2, HTTPS lub TLS. Przykładami są wbudowane moduły node:http2, node:https lub node:tls albo frameworki, które używają ich do terminacji TLS lub HTTP/2.
• Zwykłe serwery HTTP zbudowane na node:http nie są dotknięte wyciekiem pamięci w HTTPS.
• Awaria HTTP/2 dotyczy wyłącznie linii 24.x i 26.x, nie 22.x.

Ekspozycja jest znacznie mniejsza, jeśli TLS i HTTP/2 kończy reverse proxy, takie jak nginx, Apache, HAProxy lub load balancer, a Node.js otrzymuje od niego wyłącznie zwykły HTTP/1.1. Należy mimo to zaktualizować, ponieważ wydanie zawiera także inne poprawki i aktualizacje zależności.

Co zrobić teraz

1. Znajdź wszystkie instalacje Node.js. Pamiętaj o pakietach systemowych, menedżerach wersji (nvm, n, Volta), obrazach Docker, runnerach CI oraz panelach hostingowych, które dostarczają własne Node.js.
2. Zaktualizuj do poprawionej wersji swojej linii: 22.23.5, 24.22.3 lub 26.13.1. Jeśli korzystasz z pakietów dystrybucji lub dostawcy (np. NodeSource lub dystrybucji Linuksa), zainstaluj aktualizację, gdy tylko źródło pakietów udostępni te wersje.
3. Przejdź z wersji po zakończeniu wsparcia. Jeśli nadal używasz 20.x, 25.x lub starszych, przejdź na obsługiwaną linię. Zalecenie nie podaje obejścia dla serwerów, których nie da się zaktualizować.
4. Przebuduj obrazy kontenerów z zaktualizowanym bazowym obrazem Node.js i wdróż je ponownie. Sama aktualizacja hosta nie zmienia Node.js wewnątrz kontenerów.
5. Zrestartuj wszystkie procesy Node.js (jednostki systemd, PM2, kontenery Docker itp.), aby załadowany został nowy runtime. Następnie sprawdź, czy aplikacje działają prawidłowo.
6. Rozważ wymianę sekretów, jeśli byłeś narażony. Zalecenie nie precyzuje, czy serwery spełniające warunki wycieku pamięci w HTTPS powinny wymienić klucze TLS lub inne sekrety. Jeśli Twój serwer HTTPS na Node.js spełniał te warunki i był dostępny z internetu, rozważ odnowienie certyfikatu TLS wraz z kluczem.

Jak sprawdzić, czy jesteś narażony

• Uruchom node -v na każdym serwerze oraz wewnątrz każdego kontenera (docker exec <container> node -v). Wersje niższe niż 22.23.5, 24.22.3 lub 26.13.1 w swojej linii albo dowolna linia po zakończeniu wsparcia, np. 20.x lub 25.x, są podatne.
• W przypadku PM2 polecenia pm2 list i pm2 show <app> pokazują, z którego pliku binarnego Node.js i w jakiej wersji korzysta każda aplikacja.
• Sprawdź, czy Twoje aplikacje same kończą TLS lub HTTP/2 w Node.js: przeszukaj kod pod kątem http2.createSecureServer, http2.createServer, https.createServer, tls.createServer, respondWithFile, respondWithFD, SNICallback oraz addContext.
• Sprawdź menedżer procesów i logi systemowe pod kątem nieoczekiwanych restartów lub awarii Node.js. Powtarzające się przerwania serwera HTTP/2 mogą wskazywać na próby wywołania awarii.

Źródła

• https://thehackernews.com/2026/11/nodejs-fixes-16-flaws-including-http2.html