Luka Brotli dotyczy .NET i Node.js: jak sprawdzić i zaktualizować aplikacje

Aplikacja może przyjmować zwykły ruch HTTPS, a mimo to przetwarzać niebezpieczne dane wejściowe, jeśli rozpakowuje dostarczone przez użytkownika dane Brotli. 25 października 2026 roku Microsoft opublikował nadzwyczajne aktualizacje .NET usuwające przepełnienie bufora w dekoderze Brotli; lukę oznaczono jako CVE-2026-111497. Node.js uwzględnił poprawkę tej samej luki w osobnym wydaniu bezpieczeństwa z 21 października. Pierwszym krokiem dla programisty jest znalezienie drogi od danych zewnętrznych do dekodera, a następnie aktualizacja środowiska uruchomieniowego i ponowne zbudowanie lub uruchomienie aplikacji.

Według opisu firmy Microsoft luka w .NET może umożliwić nieuwierzytelnionemu atakującemu odczyt lub uszkodzenie pamięci procesu, co może prowadzić do ujawnienia danych, odmowy usługi lub eskalacji uprawnień. Poprawki opublikowano dla .NET 8, 9 i 10 oraz .NET 11 Release Candidate 3. Dla .NET 8 podano runtime 8.0.33 oraz SDK 8.0.133 lub 8.0.427. Luka nie dotyczy .NET Framework.

Gdzie występuje narażenie

Ryzyko pojawia się, gdy aplikacja przekazuje niezaufany strumień Brotli do podatnego dekodera. W .NET może się to dziać przy użyciu funkcji dekompresji żądań ASP.NET Core, automatycznym rozpakowywaniu odpowiedzi przez HttpClient lub bezpośrednim wywołaniu interfejsu API z System.IO.Compression, takiego jak BrotliStream i BrotliDecoder. Zalecenie .NET wymienia te ścieżki i wskazuje, że dekompresja przychodzących żądań oraz automatyczna dekompresja odpowiedzi są domyślnie wyłączone.

Inwentaryzacja pakietów to dopiero początek sprawdzania. Znajdź konfiguracje middleware i klientów HTTP, bezpośrednie wywołania dekodera oraz komponenty zewnętrzne przyjmujące skompresowane dane. Ustal, czy dane te pochodzą od klientów, webhooków, serwerów proxy lub zewnętrznych interfejsów API, a także jakie limity rozmiaru i czasu przetwarzania obowiązują przed rozpakowaniem. Pomoże to określić, gdzie podatny kod otrzymuje dane kontrolowane z zewnątrz.

Aktualizacja .NET

Zainstaluj aktualizację dla używanej gałęzi: .NET 8 — 8.0.33, .NET 9 — 9.0.22, .NET 10 — 10.0.14; dla .NET 11 — Release Candidate 3. W przypadku aplikacji zależnych od frameworka zainstaluj zaktualizowany runtime i uruchom aplikację ponownie. Aplikacje samodzielne trzeba ponownie zbudować i opublikować: aktualizacja runtime na hoście nie zastępuje kopii dołączonej do aplikacji. Obrazy kontenerów przebuduj i wdroż ponownie, korzystając ze zaktualizowanych obrazów .NET.

W przypadku NativeAOT użyj także zaktualizowanych pakietów SDK i runtime podczas ponownej publikacji. Jeśli nie można jeszcze wdrożyć poprawki, tymczasowo wyłącz Brotli na zidentyfikowanych ścieżkach wejściowych przyjmujących niezaufane dane. Sprawdź zwykłe żądania i integracje: wyłączenie kompresji może zmienić sposób obsługi klientów wysyłających skompresowane treści.

Sprawdź Node.js i zależności systemowe

Projekt Node.js poinformował o luce 21 października: podatny jest wbudowany dekoder Brotli w Node.js 22.x, 24.x i 26.x. Wydanie bezpieczeństwa Node.js wskazuje odpowiednio poprawione wersje 22.23.4, 24.22.1 i 26.12.1. Zaktualizuj używaną, wspieraną gałąź i uruchom usługę ponownie. Według opisu projektu problem występuje, gdy aplikacja rozpakowuje dostarczone przez atakującego dane za pomocą node:zlib; uszkodzenie pamięci może doprowadzić do awarii, ujawnienia zawartości pamięci lub zdalnego wykonania kodu.

Sprawdź także zależności dostarczane oddzielnie od systemowych wersji Node.js lub .NET. Zweryfikuj wersje Brotli w kontenerach i artefaktach kompilacji, a następnie powtórz kontrolę po wdrożeniu. W CI przypnij zaktualizowany obraz bazowy i włącz kontrolę wersji podatnych bibliotek do standardowego procesu budowania.

Krótka lista działań

1. Utwórz listę aplikacji, SDK, runtime’ów, kontenerów i kompilacji NativeAOT korzystających z Brotli.
2. Znajdź miejsca, w których zewnętrzne dane są poddawane automatycznemu lub bezpośredniemu dekodowaniu.
3. Zaktualizuj .NET, Node.js i osobno dostarczane biblioteki do poprawionych wersji; ponownie zbuduj aplikacje samodzielne i kontenery.
4. Uruchom procesy ponownie i sprawdź wersje w działającym środowisku, a nie tylko w plikach projektu.
5. Do czasu wdrożenia poprawki ogranicz przetwarzanie niezaufanych danych Brotli na zidentyfikowanych podatnych ścieżkach.

Priorytet zależy od połączenia dwóch czynników: obecności podatnego komponentu oraz możliwości przekazania mu specjalnie spreparowanego strumienia skompresowanych danych. Aktualizacja usuwa usterkę, a mapa ścieżek wejściowych pomaga upewnić się, że poprawka dotarła do procesów, kompilacji samodzielnych i kontenerów.