Category: Security · Vulnerability Management · Supply Chain
Level: Foundational
CVE-2026-111497 is an out-of-bounds write in Google's Brotli decoder, scored 9.2 on CVSS v4.0, and it's already shown up in security coverage under three different nicknames: Broccoli2Shell, Node2Shell, and HTTP2Shell. No vendor settled on the same name, and that says more about the bug than it first looks like: Brotli isn't a library one product uses, it's a compression library sitting inside almost anything that speaks HTTP. The "HTTP2Shell" name isn't even accurate — the bug has nothing specific to do with HTTP/2, it just reflects the most common way the payload gets delivered.
The flaw affects libbrotli 1.0.3 through 1.0.9, 1.1.0, and 1.2.0. Google and the Node.js project shipped fixes on October 21, covering the 22.x, 24.x, and 26.x release lines. Microsoft followed four days later with an out-of-band patch: .NET 8.0.33, 9.0.22, 10.0.14, and the Release Candidate 3 of .NET 11. The Python brotli and brotlicffi packages also have patched releases out.
Like PHP2Shell, this isn't a bug born from a bad decision in your application. It lives in the decompression decoder itself — the part of the code that runs when your server (or your runtime) receives a Brotli-compressed response and has to decompress it before anything else happens. Having Node.js installed doesn't make you vulnerable on its own: the requirement is that the application decompresses Brotli data coming from someone you don't control — exactly what happens constantly in HTTP requests carrying Content-Encoding: br.
The Brotli decoder reads the compressed stream in blocks, switching state as it goes. A malformed stream can force an invalid block switch that the decoder doesn't reject — it treats it as a legitimate request for more input. Depending on how the application reacts to that inconsistent state, the result ranges from a process crash to memory disclosure, up to remote code execution.
Imperva's Red Team is credited with the discovery, coining the name "Node2Shell" in a technical report published October 22, demonstrating real code execution against the official Node.js 24.22.0 image on Linux ARM64 — Imperva itself noted the run took several attempts, this isn't a trivial, first-try exploit. A public proof of concept that circulated the same day only achieved code execution against a deliberately weakened test build; against a standard build, the result was a crash and limited memory reads, not direct RCE. It's the same pattern as PHP2Shell: the first wave of PoC always looks worse (or better, from an attacker's perspective) than it actually is, until someone tests it against a real target.
What this incident exposes well is the transitive dependency chain nobody audits. Brotli isn't something most teams consciously choose — it ships embedded in the runtime (Node.js), in the framework (.NET), in the language bindings (Python), silently, as part of native support for Content-Encoding: br. Fixing this bug wasn't one patch, it was several patches, published on different days, by different vendors, each chasing the same root cause coming from a project most of their own developers have never heard of.
There's an extra catch worth calling out for anyone doing vulnerability management: patching the operating system's Brotli library does not fix applications that bundle their own static copy of the library. If your inventory only tracks top-level packages in package.json or the OS package manager, this is exactly the kind of exposure that slips through — the vulnerable dependency isn't on your list of direct dependencies, it's two or three layers down, and it may be duplicated: a system copy already patched, and a vendored copy inside a binary nobody thought to rescan.
The exploitation timeline followed the usual script for any high-CVSS, relatively easy-to-reproduce CVE. On October 23, researchers still said there was no confirmed exploitation in production. That changed on October 27: CISA added CVE-2026-111497 to its Known Exploited Vulnerabilities (KEV) catalog, with a remediation deadline of November 10 for US federal agencies — without detailing the observed attacks. The same day, honeypot firm Previdian logged an exploitation attempt from a US-based IP, but its own analysis found the exploit used was broken; as Previdian itself notes, a honeypot catching an attempt doesn't mean it would have worked against a real target.
In short: public PoC since October 22, KEV listing on the 27th, recorded attempt volume still low and mostly unsuccessful — but the usual pattern repeats anyway. The moment a high-CVSS CVE exists, automated scanning is usually already running before press coverage settles, and waiting for confirmation of "serious" exploitation before patching is always the wrong bet.
For anyone who can't update right away, the edge mitigation here is more direct than PHP2Shell's: block requests carrying Content-Encoding: br at the reverse proxy or firewall, or disable Brotli support in the runtime until the patch is applied. That works because, unlike session.upload_progress, this attack vector rides on a standard, visible HTTP header — easier to filter at the edge than a feature buried in the application engine.
Nobody chooses Brotli. It ships enabled by default, does its job without drawing attention, and because of that it never enters the conversation about "which third-party libraries do we audit." It's the same pattern as session.upload_progress in PHP2Shell: the most dangerous component isn't the one you chose to use, it's the one that was already switched on before you decided anything — except this time, spread across three different language ecosystems at once.
Related: BleepingComputer — CISA warns of hackers now exploiting critical Node2Shell flaw · SecurityWeek — CISA Warns of Node2Shell Exploitation as Honeypots Log Attack Attempts · Sysdig — Detecting the Node.js Brotli RCE
Categoria: Segurança · Gestão de Vulnerabilidades · Cadeia de Suprimentos
Nível: Fundamental
CVE-2026-111497 é um out-of-bounds write no decoder Brotli do Google, nota 9.2 no CVSS v4.0, e já apareceu na imprensa de segurança com três apelidos diferentes: Broccoli2Shell, Node2Shell e HTTP2Shell. Nenhum vendor concordou em usar o mesmo nome, e isso diz mais sobre a falha do que parece à primeira vista: Brotli não é uma biblioteca de um produto, é uma biblioteca de compressão que está dentro de praticamente tudo que fala HTTP. O nome "HTTP2Shell" nem é preciso — a falha não tem nada de específico com HTTP/2, só reflete o jeito mais comum de entregar o payload.
A falha afeta libbrotli 1.0.3 a 1.0.9, 1.1.0 e 1.2.0. Google e o projeto Node.js lançaram correção em 21 de outubro, cobrindo as linhas 22.x, 24.x e 26.x. A Microsoft seguiu quatro dias depois com patch fora do ciclo normal: .NET 8.0.33, 9.0.22, 10.0.14, e a Release Candidate 3 do .NET 11. Os pacotes Python brotli e brotlicffi também já têm release corrigida.
Assim como o PHP2Shell, essa não é uma falha que nasce de uma decisão ruim na sua aplicação. É um bug no decoder de descompressão em si — a parte do código que roda quando seu servidor (ou seu runtime) recebe uma resposta comprimida com Brotli e precisa descomprimir ela antes de fazer qualquer outra coisa. Ter Node.js instalado não te deixa vulnerável sozinho: o requisito é que a aplicação descomprima dados Brotli vindos de alguém que você não controla — exatamente o que acontece o tempo todo em requisições HTTP com Content-Encoding: br.
O decoder Brotli lê o stream comprimido em blocos, trocando de estado conforme avança. Um stream malformado consegue forçar uma troca de bloco inválida que o decoder não rejeita — ele trata como um pedido legítimo por mais input. Dependendo de como a aplicação reage a esse estado inconsistente, o resultado vai de crash do processo a vazamento de memória, até execução remota de código.
Quem assinou a descoberta foi o Red Team da Imperva, que batizou a falha de "Node2Shell" em relatório técnico publicado em 22 de outubro, demonstrando execução de código contra a imagem oficial do Node.js 24.22.0 em Linux ARM64 — a própria Imperva reconheceu que precisou de várias tentativas pra conseguir, não é um exploit trivial de primeira tacada. Uma prova de conceito pública que circulou no mesmo dia só conseguiu execução de código numa build de teste deliberadamente enfraquecida; contra uma build padrão, o resultado era crash e leitura limitada de memória, não RCE direto. É o mesmo padrão do PHP2Shell: a primeira onda de PoC sempre parece pior (ou melhor, do ponto de vista do atacante) do que realmente é, até alguém testar contra um alvo de verdade.
O que esse incidente expõe bem é a cadeia de dependência transitiva que ninguém audita. Brotli não é algo que a maioria dos times escolhe conscientemente — ele vem embutido no runtime (Node.js), no framework (.NET), na linguagem (os bindings Python), silenciosamente, como parte do suporte nativo a Content-Encoding: br. Corrigir essa falha não foi um patch, foram vários patches, publicados em dias diferentes, por vendors diferentes, cada um correndo atrás da mesma causa raiz vinda de um projeto que a maioria dos seus desenvolvedores nunca ouviu falar.
Tem uma pegadinha a mais aqui que vale destacar pra quem trabalha com gestão de vulnerabilidades: atualizar a Brotli do sistema operacional não resolve aplicações que empacotam sua própria cópia estática da biblioteca. Se o seu inventário rastreia só os pacotes de primeiro nível do package.json ou do gerenciador de pacotes do SO, essa é exatamente o tipo de exposição que passa batido — a dependência vulnerável não está na sua lista de dependências diretas, está duas ou três camadas abaixo, e pode estar duplicada: uma cópia do sistema já corrigida, e uma cópia vendorizada dentro de um binário que ninguém pensou em re-escanear.
A linha do tempo de exploração seguiu o roteiro clássico de todo CVE com CVSS alto e vetor relativamente simples de reproduzir. Em 23 de outubro, pesquisadores ainda diziam não haver exploração confirmada em produção. Em 27 de outubro isso mudou: a CISA adicionou o CVE-2026-111497 ao catálogo KEV (Known Exploited Vulnerabilities), com prazo de remediação até 10 de novembro pra agências federais americanas — sem detalhar os ataques observados. No mesmo dia, a empresa de honeypots Previdian registrou uma tentativa de exploração vinda de um IP nos EUA, mas a própria análise concluiu que o exploit usado estava quebrado; como a Previdian mesma ressalta, um honeypot captar uma tentativa não significa que ela teria funcionado contra um alvo real.
Em resumo: PoC pública desde 22 de outubro, listagem na KEV em 27, volume de tentativas registradas ainda baixo e majoritariamente malsucedido — mas o padrão de sempre se repete. Assim que existe um CVE com CVSS alto, varredura automatizada normalmente já está rodando antes da cobertura da imprensa se estabilizar, e esperar por confirmação de exploração "séria" antes de patchear é sempre a aposta errada.
Pra quem não consegue atualizar na hora, a mitigação de borda é mais direta que a do PHP2Shell: bloquear requisições com Content-Encoding: br no proxy reverso ou firewall, ou desabilitar o suporte a Brotli no runtime até aplicar o patch. Isso funciona porque, diferente do session.upload_progress, o vetor de ataque passa por um cabeçalho HTTP padrão e visível — mais fácil de filtrar na borda do que um recurso enterrado no motor da aplicação.
Ninguém escolhe o Brotli. Ele vem ligado por padrão, faz seu trabalho sem chamar atenção, e por isso nunca entra na conversa de "quais bibliotecas de terceiros a gente audita". É o mesmo padrão do session.upload_progress no PHP2Shell: o componente mais perigoso não é o que você escolheu usar, é o que já estava ligado antes de você decidir qualquer coisa — só que dessa vez, espalhado por três ecossistemas de linguagem diferentes ao mesmo tempo.
Relacionado: BleepingComputer — CISA warns of hackers now exploiting critical Node2Shell flaw · SecurityWeek — CISA Warns of Node2Shell Exploitation as Honeypots Log Attack Attempts · Sysdig — Detecting the Node.js Brotli RCE