Brotli-sårbarhet rammer .NET og Node.js: Slik sjekker og oppdaterer du apper

En app kan motta vanlig HTTPS-trafikk og likevel behandle farlige inndata hvis den pakker ut Brotli-data som brukere har levert. 25. oktober 2026 lanserte Microsoft ekstraordinære .NET-oppdateringer for å rette en bufferoverflyt i Brotli-dekoderen; sårbarheten er identifisert som CVE-2026-111497. Node.js inkluderte en rettelse for samme sårbarhet i en egen sikkerhetsutgivelse 21. oktober. Det første utviklere bør gjøre, er å finne veien fra eksterne data til dekoderen, og deretter oppdatere runtime-miljøet og bygge appen på nytt eller starte den på nytt.

Ifølge Microsofts beskrivelse kan .NET-sårbarheten gjøre det mulig for en angriper uten autentisering å lese eller ødelegge prosessminne, noe som kan føre til datalekkasjer, tjenestenekt eller rettighetseskalering. Rettelser er publisert for .NET 8, 9 og 10, samt .NET 11 Release Candidate 3. For .NET 8 er runtime 8.0.33 og SDK 8.0.133 eller 8.0.427 oppgitt. .NET Framework er ikke berørt av denne sårbarheten.

Hvor eksponeringen oppstår

Risikoen oppstår når en app sender en Brotli-strøm fra en upålitelig kilde til en sårbar dekoder. I .NET kan dette skje ved bruk av ASP.NET Core request decompression, automatisk dekomprimering av svar med HttpClient eller direkte kall til API-er i System.IO.Compression, for eksempel BrotliStream og BrotliDecoder. .NET-rådgivningen lister opp disse inngangspunktene og opplyser at dekomprimering av innkommende forespørsler og automatisk dekomprimering av svar er slått av som standard.

En oversikt over pakker er bare starten på undersøkelsen. Finn konfigurasjoner for middleware og HTTP-klienter, direkte kall til dekoderen og tredjepartskomponenter som mottar komprimerte data. Undersøk om slike data kommer fra klienter, webhooks, proxyer eller eksterne API-er, og hvilke grenser for størrelse og behandlingstid som er satt før utpakking. Dette gjør det lettere å finne hvor sårbar kode mottar data som kan styres utenfra.

Oppdatering av .NET

Installer oppdateringen for grenen du bruker: .NET 8 – 8.0.33, .NET 9 – 9.0.22, .NET 10 – 10.0.14; for .NET 11 – Release Candidate 3. For framework-dependent-apper installerer du den oppdaterte runtime-versjonen og starter appen på nytt. Self-contained-apper må bygges og publiseres på nytt: En runtime-oppdatering på vertsmaskinen erstatter ikke kopien som er inkludert i appen. Bygg containerne på nytt og distribuer dem med oppdaterte .NET-avbildninger.

For NativeAOT må du også bruke oppdaterte SDK-er og runtime-pakker når du publiserer på nytt. Hvis du ikke kan distribuere rettelsen ennå, bør du midlertidig deaktivere Brotli på identifiserte inngangspunkter som tar imot data fra upålitelige kilder. Test vanlige forespørsler og integrasjoner: Deaktivert komprimering kan påvirke håndteringen av klienter som sender komprimerte forespørsler.

Sjekk Node.js og systemavhengigheter

Node.js-prosjektet varslet om sårbarheten 21. oktober: Den innebygde Brotli-dekoderen i Node.js 22.x, 24.x og 26.x er berørt. Sikkerhetsutgivelsen for Node.js oppgir de rettede versjonene 22.23.4, 24.22.1 og 26.12.1. Oppdater grenen du bruker til en rettet, støttet versjon, og start tjenesten på nytt. Ifølge prosjektets beskrivelse oppstår problemet når en app pakker ut data levert av en angriper ved hjelp av node:zlib; minnekorrupsjon kan føre til at appen krasjer, minne avsløres eller kode kjøres eksternt.

Kontroller også avhengigheter som leveres separat fra systemets Node.js eller .NET. Sammenlign Brotli-versjonene i containere og byggartefakter, og gjenta kontrollen etter distribusjon. I CI bør du låse den oppdaterte basisavbildningen og inkludere kontroll av sårbare bibliotekversjoner i den vanlige byggeprosessen.

Kort handlingsplan

1. Lag en liste over apper, SDK-er, runtime-miljøer, containere og NativeAOT-bygg som bruker Brotli.
2. Finn stedene der eksterne data dekodes automatisk eller direkte.
3. Oppdater .NET, Node.js og biblioteker som leveres separat, til rettede versjoner; bygg selvstendige apper og containere på nytt.
4. Start prosessene på nytt, og kontroller versjonene i det kjørende miljøet – ikke bare i prosjektfilene.
5. Inntil rettelsen er distribuert, bør du begrense behandlingen av Brotli-inndata fra upålitelige kilder på de identifiserte sårbare inngangspunktene.

Prioriteringen avhenger av to faktorer: om en sårbar komponent finnes, og om det er mulig å sende en spesialformet komprimert strøm til den. Oppdateringen lukker feilen, mens en oversikt over inngangspunktene bidrar til å sikre at rettelsen når prosesser, selvstendige bygg og containere.