Broccoli2Shell prova que seu código mais arriscado é o que você nunca escolheu

Qual biblioteca descompacta os dados que seu servidor recebe? Se você não consegue responder em menos de um minuto, o Broccoli2Shell também é um problema seu, tenha você digitado ou não a palavra "Brotli" no seu código.

O bug é o CVE-2026-111497, uma escrita fora dos limites no decodificador Brotli do Google. Segundo a Strobes, ele afeta as versões 1.0.3 a 1.2.0 do Brotli e tem nota 9,2 (crítica) no CVSS 4.0. Como clientes e servidores HTTP decodificam Content-Encoding: br automaticamente, ele chega ao Node.js, ao Python, ao Bun e a outras stacks por meio do tráfego web comum. O Node.js lançou correções em 21 de outubro nas versões 22.23.4, 24.22.1 e 26.12.1, conforme informam a Qualys e outros. O nome mudou várias vezes (Node2Shell, HTTP2Shell, Broccoli2Shell), sempre para o mesmo CVE.

A troca de nome é a verdadeira história

A Strobes faz uma observação precisa: o apelido mudou três vezes em quatro dias, e cada nome refletia quem o setor achava que estava exposto. Começou como uma correção de runtime e virou um problema de dependências e de cadeia de suprimentos. Achamos que esse percurso é a lição. O código vulnerável está em uma biblioteca em C que muitos projetos incluem, vinculam ou herdam. Ninguém a "instalou" por decisão própria. Ela veio com o runtime, o cliente HTTP ou a imagem.

Por isso é uma infraestrutura invisível. A Semgrep observa que o bug não está em um pacote npm chamado brotli, nem no próprio body-parser. Mesmo assim, o body-parser entrega ao decodificador dados compactados controlados pelo atacante. Seu scanner de dependências pode ficar quieto enquanto o problema está uma camada abaixo. A Strobes também aponta um rastreador público, mantido por pesquisadores independentes, que lista projetos cujas cópias incluídas ainda não tinham correção em 24 de outubro, entre eles o runtime do.NET, a extensão brotli do PHP e a gem brotli do Ruby. Atualizar a sua distribuição não adianta para software que traz a própria cópia privada.

A exposição depende dos caminhos, e o pior é o de saída

Nem todo serviço Node corre o mesmo risco, e vale dizer isso com clareza para evitar pânico. A Semgrep ressalta que a aplicação precisa executar uma versão afetada, usar um parser com suporte a Brotli, ter a descompactação ativada e expor uma rota em que ele esteja montado. A Strobes diz que o Express 5 com body-parser 2.x decodifica por padrão corpos de requisição em Brotli, de modo que um único app.use(express.json) pode colocar o decodificador diante de tráfego anônimo.

O caminho que consideramos mais incômodo é o que ninguém monitora: as respostas que o seu próprio código busca. O fetch nativo do Node decodifica Brotli automaticamente, e a Strobes afirma que urllib3, aiohttp e httpx, no Python, fazem o mesmo quando há um pacote Brotli instalado, mesmo que seu código nunca o importe. Webhooks, prévias de links, "importar de URL", crawlers e agentes de IA que navegam são portas por onde um estranho pode entrar. A Strobes também diz que nenhum WAF enxergará esse caminho. O WAF da Vercel, segundo a TuxCare, bloqueia a rota de entrada, mas não as respostas buscadas em outros lugares.

Correção heroica não escala; inventário, sim

A reação padrão é um fim de semana de atualizações frenéticas. Para Node 22, 24 e 26, funciona: a correção é, nas palavras da TuxCare, entediante. Mas a TuxCare também alerta que o Node.js 20, 18 e anteriores não recebem nada do projeto original, e o parque que você esqueceu é justamente o que morde. Há ainda a armadilha da reinicialização: um processo em execução mantém o decodificador antigo na memória.

A linha do tempo também deveria nos preocupar. A TuxCare, citando o The Hacker News, diz que a alteração que corrige o problema entrou no código-fonte do Brotli em fevereiro de 2026, mas só foi publicada em uma versão de segurança em 21 de outubro. A Strobes acrescenta que ninguém a associou à execução remota de código até outubro. Um patch público é um mapa, como escreveu um autor no Medium. A Strobes informa que existem provas de conceito públicas, e, segundo a TuxCare, não havia relato de exploração real até 22 de outubro. Trataríamos essa calma como temporária, não como tranquilizadora.

Na mesma semana veio o PHP2Shell, que a Semgrep descreve como uma falha que existe no PHP há mais de uma década, e o Google Cloud afirma que aplicações em PHP 7.4 continuam vulneráveis a ela. Duas divulgações sobre runtimes com um dia de diferença não provam que a segurança desmoronou; a própria Semgrep diz que a tendência mais ampla se forma há anos. Mas isso mostra o pouco tempo que temos para descobrir o que executamos.

Nosso veredito

Corrija agora, claro. Depois faça o trabalho chato que realmente protege: mantenha um inventário que vá além dos manifestos de pacotes e cubra runtimes, bibliotecas nativas incluídas, imagens-base de contêineres, runners de CI e todo lugar em que seu código busca uma URL controlada por outra pessoa. Aposente runtimes sem suporte em vez de torcer para dar certo. Esperamos que o próximo bug de descompactação chegue mais cedo ou mais tarde, e a equipe que souber responder em minutos "onde executamos isso?" vai superar a equipe com os melhores feitos heroicos de correção.