Brotli-sårbarhet påverkar .NET och Node.js: så kontrollerar och uppdaterar du appar

En app kan ta emot vanlig HTTPS-trafik och ändå hantera farlig indata om den packar upp Brotli-data som användare har skickat in. Den 25 oktober 2026 släppte Microsoft oplanerade .NET-uppdateringar för att åtgärda en buffertöverskridning i Brotli-dekodern; sårbarheten har beteckningen CVE-2026-111497. Node.js inkluderade en korrigering för samma sårbarhet i en separat säkerhetsversion den 21 oktober. För utvecklare är det första steget att hitta vägen från externa data till dekodern och därefter uppdatera runtime och bygga om eller starta om appen.

Enligt Microsofts beskrivning kan .NET-sårbarheten göra det möjligt för en oautentiserad angripare att läsa eller skada processminne, vilket kan leda till röjande av data, överbelastning eller utökade privilegier. Korrigeringar har släppts för .NET 8, 9 och 10 samt .NET 11 Release Candidate 3. För .NET 8 anges runtime 8.0.33 och SDK 8.0.133 eller 8.0.427. .NET Framework påverkas inte av sårbarheten.

Var exponeringen uppstår

Risken uppstår när en app skickar en obetrodd Brotli-ström till en sårbar dekoder. I .NET kan detta ske när ASP.NET Core request decompression används, när svar packas upp automatiskt via HttpClient eller när API:er från System.IO.Compression anropas direkt, till exempel BrotliStream och BrotliDecoder. .NET:s rekommendation listar dessa vägar och anger att uppackning av inkommande förfrågningar och automatisk uppackning av svar är avstängda som standard.

En inventering av paket är bara början på kontrollen. Leta efter konfigurationer av middleware och HTTP-klienter, direkta anrop till dekodern och tredjepartskomponenter som tar emot komprimerade data. Ta reda på om sådana data kommer från klienter, webhooks, proxyservrar eller externa API:er, och vilka begränsningar för storlek och bearbetningstid som finns före uppackningen. Det hjälper dig att avgöra var den sårbara koden tar emot data som kan kontrolleras utifrån.

Uppdatera .NET

Installera uppdateringen för den gren du använder: .NET 8 — 8.0.33, .NET 9 — 9.0.22, .NET 10 — 10.0.14; för .NET 11 — Release Candidate 3. För framework-dependent-appar installerar du den uppdaterade runtime-versionen och startar om appen. Self-contained-appar måste byggas och publiceras på nytt: en uppdatering av runtime på värden ersätter inte kopian som ingår i appen. Bygg om containrarna och driftsätt dem med uppdaterade .NET-avbildningar.

Använd även uppdaterade SDK:er och runtime-paket när du publicerar om för NativeAOT. Om korrigeringen ännu inte går att driftsätta kan du tillfälligt stänga av Brotli på de identifierade inkommande vägar som tar emot obetrodda data. Testa vanliga förfrågningar och integrationer: avstängd komprimering kan påverka hanteringen av klienter som skickar komprimerade meddelanden.

Kontrollera Node.js och systemberoenden

Node.js-projektet rapporterade sårbarheten den 21 oktober: Brotli-dekodern som är inbyggd i Node.js 22.x, 24.x och 26.x påverkas. Node.js säkerhetsversion anger de korrigerade versionerna 22.23.4, 24.22.1 respektive 26.12.1. Uppdatera den underhållna gren du använder och starta om tjänsten. Enligt projektets beskrivning uppstår problemet när en app packar upp data som en angripare har skickat med hjälp av node:zlib; minnesskada kan leda till att processen kraschar, att minne röjs eller till fjärrkörning av kod.

Kontrollera även beroenden som levereras separat från systemets Node.js eller .NET. Jämför Brotli-versionerna i containrar och byggartefakter och gör sedan om kontrollen efter driftsättning. Lås den uppdaterade basavbildningen i CI och inför kontroll av sårbara biblioteksversioner i den vanliga byggprocessen.

Kort åtgärdsordning

1. Lista appar, SDK:er, runtime-versioner, containrar och NativeAOT-byggen som använder Brotli.
2. Hitta ställen där externa data går igenom automatisk eller direkt avkodning.
3. Uppdatera .NET, Node.js och separat levererade bibliotek till korrigerade versioner; bygg om fristående appar och containrar.
4. Starta om processerna och kontrollera versionerna i den körande miljön, inte bara i projektfilerna.
5. Begränsa hanteringen av obetrodd Brotli-indata på de identifierade sårbara vägarna tills korrigeringen har driftsatts.

Prioriteringen beror på två faktorer: om en sårbar komponent finns och om någon kan skicka en särskilt utformad komprimerad ström till den. En uppdatering åtgärdar felet, medan en kartläggning av inkommande vägar hjälper dig att säkerställa att korrigeringen har nått processer, fristående byggen och containrar.