HTTP2Shell

01Sumário executivo

A CVE-2026-111497 é uma escrita fora dos limites (out-of-bounds write) no decodificador da biblioteca Brotli, o formato de compressão do Google usado na web, em fontes e em arquivos [1] [3]. Foi relatada ao Node.js por Khai Tran e Sylvie Mayer, do OpenAI Codex Security, e corrigida em 21 de outubro de 2026 [1] [4]. O Google, autoridade que emitiu a CVE, atribuiu 9.2 em CVSS v4; o Node.js classifica como alta, e a Red Hat, como importante [3] [4].

O nome HTTP2Shell é o último de uma série: a falha foi chamada de Node2Shell quando saiu a correção do Node.js, de Python2Shell quando as bibliotecas Python entraram na lista e de HTTP2Shell quando a lista se espalhou por toda a pilha HTTP [3]. Não há defeito no protocolo HTTP/2; o nome aponta para o canal mais comum de entrega, o cabeçalho Content-Encoding: br de requisições e respostas HTTP [3] [4].

A exploração é real. Em 22 de outubro, pesquisadores demonstraram execução de código no Node.js 24.22.0 oficial para arm64 [3] [4]; em 27 de outubro, a CISA incluiu a falha no catálogo KEV, com prazo de correção para órgãos federais em 10 de novembro [4]. Não há solução de contorno no Node.js: a única correção completa é atualizar [1] [2].

A ação é: atualize o Node.js para 22.23.4, 24.22.1 ou 26.12.1, e depois procure as outras cópias do Brotli na mesma infraestrutura, como Bun, .NET, Python, Envoy e Istio, com as versões da tabela 2 [1] [3] [4]. Reinicie os processos e reconstrua as imagens de contêiner. A seção 6 traz a verificação da plataforma CiberLab, que roda em Node.js.

02Identificação do objeto analisado

A falha está numa biblioteca, então cada produto que a embute tem sua própria versão corrigida. A tabela reúne as principais:

03Contexto técnico: quem descomprime o quê

Brotli é um formato de compressão sem perdas criado pelo Google, adotado pelos navegadores e servidores web como alternativa ao gzip [3]. Na web, quem envia dados comprimidos declara o formato no cabeçalho Content-Encoding, e o valor br indica Brotli [4]. O ponto que importa para esta falha é quem descomprime, porque é o decodificador que tem o defeito, e não o compressor.

3.1Três lugares onde a descompressão acontece

1. No servidor, ao receber: um servidor que aceita corpo de requisição comprimido descomprime o que o cliente mandou. No Express 5 com body-parser 2, os leitores JSON, raw, text e urlencoded fazem isso por padrão, porque a opção inflate começa ligada [2]. Um servidor HTTP do Node sem framework não descomprime corpo de requisição sozinho [2].
2. No cliente, ao buscar: o fetch() nativo do Node descomprime automaticamente respostas em Brotli, então um servidor malicioso ou comprometido ataca quem o consulta [2]. O HttpClient do .NET com descompressão automática faz o mesmo [3].
3. Em arquivos: leitores de Parquet, extratores de arquivos compactados (7-Zip, p7zip), conversores de fonte WOFF2, leitores de PDF e ferramentas de firmware embutem o decodificador para abrir arquivos [3].

3.2Cópias embutidas

A Brotli é distribuída como código-fonte que os projetos copiam para dentro do próprio repositório (vendoring). O Node.js, o Bun, o .NET, o Chromium, o Firefox, o DuckDB, o ClickHouse e o Apache Arrow carregam cada um a sua cópia [3]. Por isso atualizar o pacote libbrotli do sistema não corrige esses programas, e atualizar o Node.js não corrige o .NET instalado na mesma máquina [3] [4]. Cada cópia precisa da sua própria atualização.

04Mecanismo da vulnerabilidade e causa raiz

4.1O erro que virou espera

Um fluxo Brotli é dividido em blocos, e o fluxo pode sinalizar a troca de um tipo de bloco para outro [1]. Quando essa troca é inválida para a estrutura do próprio fluxo, o decodificador vulnerável não reconhece o erro: relata que precisa de mais entrada, uma condição temporária, em vez de um erro permanente de formato [1] [2]. O decodificador em modo de fluxo (streaming) então continua anexando os bytes que chegam a um buffer interno de oito bytes, e passa a escrever além do fim dele [1].

O resultado é corrupção da memória do processo que descomprime, com três desfechos possíveis: queda, revelação de memória do processo ou execução remota de código [1]. Nenhuma autenticação é necessária: basta que o atacante consiga entregar o fluxo ao decodificador, por uma requisição ou por uma resposta [2].

4.2A correção

A correção do Brotli introduz um código de erro próprio, BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH, e faz o decodificador rejeitar o fluxo malformado em vez de esperar mais dados [2]. Isso dá um teste simples para cópias embutidas: um arquivo decode.h do Brotli sem esse identificador é uma cópia sem correção [3].

05Caminhos de exposição e exploração

5.1Quando uma aplicação está exposta

Ter uma versão afetada não basta: é preciso que dados Brotli não confiáveis cheguem ao decodificador. A tabela reúne os caminhos documentados:

Apache com mod_brotli e Nginx não decodificam Brotli por padrão; eles comprimem as respostas, e não descomprimem as requisições [3].

5.2Estado da exploração

1. Execução demonstrada: a Imperva obteve execução de código no Node.js 24.22.0 oficial (Linux arm64), com várias tentativas; o exploit não foi publicado [3] [4]. A Cycode cita o Express 5 e o body-parser 2 como caminhos de requisição que a pesquisa pública mostrou chegarem à execução de código [4].
2. Prova de conceito pública: o repositório ikow/brotli2crash só executa código em compilações enfraquecidas; nas normais, causa queda e leitura limitada de memória [3].
3. Exploração em campo: não havia ataque confirmado até 24 de outubro [3]; em 27 de outubro, a CISA incluiu a CVE no KEV com base em evidência de exploração ativa [4]. A inclusão confirma o abuso do componente, mas não diz quais produtos foram atacados.

5.3As outras falhas da mesma versão do Node.js

A versão de 21 de outubro corrigiu dez falhas; além da do Brotli, três de severidade alta merecem atenção de quem faz requisições de saída [1]:

06Verificação: a exposição do CiberLab

A plataforma CiberLab roda em Node.js, então foi verificada contra cada caminho da tabela 3. A conclusão é que a exposição é baixa, mas a versão do Node precisa ser confirmada e fixada.

07Detecção e inventário

Para esta falha, inventário vem antes de assinatura: a Cycode recomenda começar pela verificação de versões, e não por varredura de rede [4]. A ordem abaixo vai do mais barato ao mais caro.

7.1Inventário de versões

Os comandos abaixo cobrem os ambientes mais comuns, inclusive dentro de contêineres e nas máquinas de build [3] [4]:

# Runtimes JavaScript
node -v
bun --version

# Python
pip show brotli brotlicffi

# .NET
dotnet --list-runtimes

# Processos com o decodificador carregado dinamicamente
# (nao encontra copias estaticas ou embutidas)
grep -l brotlidec /proc/*/maps 2>/dev/null

# Copias embutidas no codigo-fonte, inclusive submodulos:
# um decode.h sem o novo erro e uma copia sem correcao
grep -rL BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH \
  $(find . -path '*brotli*' -name decode.h)

Compare com a versão corrigida do pacote da distribuição, e não com a versão do upstream, para não acusar falsamente pacotes com correção retroportada [3].

7.2Caminhos de código

Procure no código os pontos onde o decodificador é alcançado: AddRequestDecompression, UseRequestDecompression, AutomaticDecompression com Brotli ou All, BrotliStream e BrotliDecoder no .NET; Express 5, body-parser 2, Koa e @fastify/compress no Node; fetch() sobre URL fornecida pelo usuário; e chamadas diretas a node:zlib [4].

7.3Regra Suricata para requisições comprimidas

Onde a aplicação não espera corpo comprimido, uma requisição com Content-Encoding: br já é anômala. A regra abaixo alerta esse caso em sensores com visibilidade do tráfego decifrado:

alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"CIBERLAB BROTLI CVE-2026-111497 REQUEST BODY WITH CONTENT-ENCODING BR"; \
    flow:to_server,established; \
    http.header_names; content:"Content-Encoding"; nocase; \
    http.header; content:"Content-Encoding|3a 20|br"; nocase; \
    classtype:attempted-admin; sid:9000301; rev:1; \
    reference:cve,2026-111497; reference:url,ciberlab.seg.br/reports/http2shell;)

7.4Sinais no host

Uma exploração malsucedida derruba o processo, e uma bem-sucedida tende a gerar processos filhos inesperados [1] [2]. Alerte quedas repetidas de processos Node, Bun ou .NET logo após requisições com corpo comprimido ou após buscas de saída, shells filhos desses processos e conexões de saída novas a partir dos servidores de aplicação.

08Mitigação e resposta a incidentes

8.1Correção definitiva

Atualize cada cópia do Brotli para a versão corrigida do seu produto (tabela 2), reinicie os processos e reconstrua as imagens de contêiner com docker build --pull [4]. Reconstrua também aplicações .NET autocontidas e binários independentes do Bun, que carregam o runtime dentro de si [4]. Linhas do Node.js fora de suporte não recebem correção e precisam migrar [1] [2].

8.2Medidas temporárias

1. Desligue a descompressão de requisições: no body-parser, inflate: false faz o servidor recusar corpos comprimidos com HTTP 415 [2]. Isso também recusa gzip [4].
2. Recuse Content-Encoding: br na borda: no proxy ou balanceador, para requisições que chegam [4]. Cloudflare, Azure, Imperva e Vercel publicaram regras de WAF, que só cobrem o tráfego de entrada [3].
3. Proteja os clientes: remover br do Accept-Encoding não basta, porque um servidor hostil manda Brotli mesmo assim; recuse respostas com Content-Encoding contendo br antes de ler o corpo [3].
4. Segmente: limite o acesso de entrada aos serviços Node.js e a saída dos hosts afetados [2].
5. Arquivos: recuse Parquet com codec Brotli de origem não confiável antes de analisá-lo [3].

8.3Resposta a um comprometimento

Se houver sinal de exploração, trate o processo afetado como comprometido: gire os segredos que ele podia ler, reconstrua a instância a partir de imagem limpa com o runtime corrigido e confirme, depois do reinício, que o componente corrigido é o que está rodando [3]. Revise as conexões de saída feitas pelo servidor após a requisição ou a busca suspeita.

8.4Mapeamento de técnicas MITRE ATT&CK

IDs e nomes conferidos na base oficial do MITRE ATT&CK for Enterprise [5]:

09Indicadores de comprometimento

Nenhuma fonte publicou IPs, domínios ou hashes ligados à exploração. Os indicadores abaixo são de exposição e de comportamento:

10Limitações da análise

1. Ausência de detonação: o CiberLab não reproduziu a falha nem executou exploit. A causa raiz e as versões vêm das referências [1] a [4].
2. Divergência sobre a exploração: a Phoenix registrava a falha fora do KEV em 24 de outubro [3]; a Cycode registra a inclusão em 27 de outubro [4]. Este relatório adota a data mais recente, mas nenhuma fonte descreve quais ambientes foram atacados.
3. Rastreador incompleto: a lista de cópias embutidas da Phoenix ignora submódulos, alguns repositórios grandes e cópias privadas [3]. A tabela 2 não é exaustiva.
4. Regra derivada: a regra Suricata da seção 7.3 foi deduzida dos caminhos descritos em [2] e [4] e não foi testada em produção. Ela detecta a presença do cabeçalho, e não o fluxo malformado.
5. Versão em produção: a seção 6 verificou o Dockerfile e a etiqueta do Docker Hub, mas não a versão do Node em execução no servidor, que depende de quando o build rodou. O comportamento do Next.js diante de corpo de requisição com Content-Encoding: br não foi testado.