CVE-2026-111497: Sårbarhet i Brotli-avkodaren påverkar Node.js, Bun, Python, .NET och Envoy – det här behöver du uppdatera nu

Googles Brotli-avkodare innehåller i versionerna 1.0.3 till 1.2.0 ett fel som gör att manipulerade Brotli-data kan skriva över minne utanför en buffert. Sårbarheten har beteckningen CVE-2026-111497 och ett betyg på 9.2 enligt CVSS 4.0; offentligt går den under namnen Node2Shell och Broccoli2Shell. Möjliga följder är en krasch, läsning av processminne eller körning av kod. Imperva har visat kodexekvering på en oförändrad Node.js 24.22.0. Proof-of-concept-kod är delvis offentlig, men attacker i det vilda är hittills inte kända. Node.js publicerade korrigeringarna den 21 oktober 2026, och övriga ekosystem följde fram till den 26 oktober.

Efter rapporten kontrollerade jag mina egna system: bygg-runnern för denna webbplats körde fortfarande Node.js 22.23.1, trots att 22.23.4 hade funnits tillgänglig i flera dagar. Orsaken beskrivs i avsnittet om GitHub Actions längre ned; den berör alla självhostade runners med actions/setup-node.

Orsak

Felet finns i funktionen DecodeBlockTypeAndLength(). Den bearbetar blockväxlingar i den komprimerade dataströmmen, alltså de punkter där avkodaren växlar till en annan Huffman-kod. I de sårbara versionerna returnerar funktionen endast ett sanningsvärde; BROTLI_FALSE betyder då både “dataströmmen är felaktig” och “ytterligare indata krävs”. En manipulerad dataström deklarerar en enda blocktyp och förbrukar dess längd, vilket tvingar fram en växling som inte kan lyckas. Avkodaren behandlar detta som saknade indata, lägger till ytterligare byte i en intern buffert på 8 byte och skriver därmed förbi dess slut.

Uppströmsfixen (commit 0ed4268 i repositoriet google/brotli) inför en egen felkod BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH och avbryter avkodningen. OpenAI Codex Security rapporterade redan felet i februari 2026. Fixen hamnade då i källkoden, men klassades inte som en säkerhetskorrigering och förekom inte i någon release. Först med Brotli 1.2.1 och Node.js-releaserna den 21 oktober 2026 levererades den.

När ett system kan angripas

Att komprimera med Brotli är ofarligt; endast den som dekomprimerar Brotli-data från en extern källa är sårbar. Det finns två riktningar:

• Klient: Applikationen hämtar en URL och avkodar ett svar med Content-Encoding: br. Den inbyggda fetch() i Node.js och Bun gör detta automatiskt och kan inte stängas av. Därmed påverkas crawlers, webhook-mottagare med återanrop, länkförhandsvisningar, övervakningsskript och all automation som laddar innehåll från tredjepartsservrar. En angripare behöver bara kontrollera en av de hämtade servrarna.
• Server: Ett ramverk eller middleware packar upp request-bodies med Content-Encoding: br. Imperva nämner för Node.js body-parser 2.0.0 till 2.3.0 och Express 5.0.0 till 5.3.0 med konfigurerade parsrar json() eller raw(). En ren http-server från Node.js avkodar inte själv inkommande bodies.

Apache mod_brotli och de vanliga Brotli-modulerna för nginx komprimerar endast och påverkas därför inte. Envoy och Istio är sårbara endast när Brotli-decompressor-filtret är konfigurerat; Istio aktiverar det inte som standard.

Berörda komponenter och fixversioner

Ytterligare bindningar för PHP, Ruby och Go (cgo) är beroende av systemets eller en paketerad libbrotli. Bland Linux-distributionerna hade Debian 12 och 13, Alpine och Amazon Linux 2023 patchade paket den 26 oktober; Fedora och Red Hat var delvis patchade, medan fixen ännu saknades för Ubuntu och SUSE.

Hitta berörda versioner

För Node.js, Python och systembiblioteket räcker tre frågor. I Windows ger node -v samma resultat som i Linux.

node -v
pip show Brotli brotlicffi
pipdeptree -r -p Brotli

I Debian/Ubuntu och Alpine visar pakethanteraren systembibliotekets version:

dpkg -l 'libbrotli*'
apk info -v brotli-libs

Containeravbildningar måste kontrolleras separat: En uppdaterad värd hjälper inte om avbildningen innehåller en gammal Node.js-version eller en paketerad libbrotli. Efter uppdateringen måste avbildningar byggas om och körande workloads startas om; för Bun och brotli4j gäller detta även applikationer som länkar Brotli statiskt.

Självhostade GitHub-runners: setup-node hämtar versionen från cachen

actions/setup-node med node-version: 22 kontrollerar som standard inte om det finns en nyare 22-version. Om det redan finns en matchande version i runnerns tool-cache används den. På GitHub-hostade runners rullas avbildningen ut på nytt regelbundet; en självhostad runner behåller däremot sin cache tills någon tömmer den. I loggen står då exempelvis Found in cache @ .../_tool/node/22.23.1/x64.

En extra rad i varje setup-node-steg löser problemet:

- uses: actions/setup-node@v4
  with:
    node-version: 22
    check-latest: true

Alternativt kan minimiversionen anges fast (node-version: 22.23.4); den måste då uppdateras vid varje säkerhetsrelease. Detta är särskilt relevant för pipelines som hämtar innehåll från externa servrar, till exempel skannrar, länkkontroller eller flöden: Där körs fetch() mot servrar som du inte kontrollerar, och runnern har normalt åtkomst till deploy-hemligheter.

Om en uppdatering inte är möjlig omedelbart

Mitigeringarna riktar sig mot avkodningen:

• Inkommande: Avvisa requests med Content-Encoding som innehåller br i reverse proxy eller middleware. Jämförelsen måste ignorera versaler/gemener och även fånga listor som gzip, br.
• Utgående: Ta bort br från Accept-Encoding och kasta svar med Content-Encoding: br före avkodning. Att enbart ta bort det från Accept-Encoding räcker inte, eftersom en manipulerad server ändå kan skicka kodningen. För den inbyggda fetch() i Node.js och Bun är detta inte möjligt; där hjälper endast uppdateringen.
• curl: Utelämna --compressed; låt CURLOPT_ACCEPT_ENCODING vara inställt på NULL i libcurl.
• Python: Avinstallera Brotli och brotlicffi samt ta bort extras som httpx[brotli] från beroendena. urllib3, requests och aiohttp faller då tillbaka till gzip och deflate.
• Envoy/Istio: Ta bort Brotli-decompressorn från konfigurationen respektive EnvoyFiltren och kontrollera den aktiva konfigurationen.

Cloudflare Workers och webbläsare

Den som kör applikationer som en Cloudflare Worker kör ingen egen Node.js-process; runtime-miljön workerd drivs och uppdateras av Cloudflare. Något uttalande från Cloudflare om CVE-2026-111497 fanns inte den 26 oktober, och kunder kan inte själva ändra något i runtime-miljön. Verktygen kring workern förblir dock berörda: byggskript, wrangler och lokala utvecklingsmiljöer körs på Node.js och bör använda en patchad version. Webbläsare använder egna Brotli-implementationer; de nämns inte som berörda i rapporterna från tillverkare och säkerhetsforskare.

Tidslinje