O Google publicou em 22 de outubro de 2026 a CVE-2026-111497, uma vulnerabilidade crítica na biblioteca de compressão Brotli com pontuação 9.2 no sistema CVSS v4.0. O problema, classificado como uma gravação fora dos limites (out-of-bounds write) no decodificador, permite que um fluxo de dados malicioso corrompa a memória do servidor.
A vulnerabilidade não reside no núcleo do WordPress, em seus plugins ou temas. No entanto, o gerenciador de conteúdo atua como um vetor que possibilita a exploração remota e sem autenticação. A falha circula sob nomes não oficiais como HTTP2Shell, Node2Shell e Brotli2Shell, embora o termo HTTP2Shell seja tecnicamente impreciso por não haver relação com o protocolo HTTP/2.
O projeto oficial do Brotli liberou versões corrigidas em 21 de outubro de 2026. Em 27 de outubro, a Agência de Segurança Cibernética e de Infraestrutura dos Estados Unidos (CISA) adicionou o problema ao seu catálogo de vulnerabilidades ativamente exploradas (KEV).
O caminho do ataque via XML-RPC
A exploração contra sites WordPress exige que o servidor da vítima seja forçado a buscar informações em um endereço externo. Uma prova de conceito pública utiliza o arquivo xmlrpc.php para iniciar essa requisição.
O fluxo de ataque ocorre em quatro etapas operacionais:
- O invasor envia uma requisição não autenticada que aciona o método pingback.ping, fornecendo uma URL de origem sob seu controle.
- O WordPress acessa essa URL para validar o link do pingback.
- O servidor do invasor devolve uma resposta forjada, identificada como comprimida via Brotli.
- O cliente HTTP do servidor da vítima processa a resposta com o decodificador vulnerável, corrompe a memória e concede ao invasor a execução de comandos com os privilégios do processo PHP.
A rota exige que o endpoint XML-RPC esteja acessível, o método de pingback registrado, a postagem configurada para aceitar pings e o servidor autorizado a realizar conexões de rede externas.
Confirmação em laboratório e limitações técnicas
A equipe da Wordfence confirmou a execução remota de código em um ambiente de laboratório que replicava o alvo exato da prova de conceito: WordPress 7.1.3 em Debian 13.7, executando Apache 2.4.69 e PHP 8.3.36 como mod_php, junto ao pacote libbrotli1 1.1.0-2+b7. A randomização de memória do sistema operacional estava habilitada. Após a atualização do pacote Brotli no Debian, o ataque falhou.
A pesquisa destacou a dependência estrita do ambiente. Ao disparar a mesma carga maliciosa contra um servidor rodando a versão 8.3.35 do PHP, o código não foi executado. O ataque apenas causou o travamento (crash) do worker do PHP. Isso indica que a exploração pública não é universal, exigindo alinhamento exato com a compilação do binário e o layout de memória do alvo.
Telemetria e atividade em 2 de novembro
A ameaça tem gerado atividade contínua de varredura. A empresa Previdian registrou tentativas de exploração em sua telemetria no dia 2 de novembro de 2026. A Check Point também relatou varreduras automatizadas com envio de cargas suspeitas.
Fora do ecossistema PHP, a empresa ELLIO interceptou tentativas de ataque direcionadas ao Node.js. Embora o exploit capturado na rede não tenha funcionado contra um alvo vulnerável, testes controlados pela própria ELLIO e pela Imperva validaram a execução de código em compilações do Node.js.
Até 2 de novembro de 2026, nenhum relatório público validado havia documentado um comprometimento bem-sucedido em ambientes de produção do WordPress utilizando essa técnica, o que não descarta o risco imediato diante das varreduras ativas.
Atualização de pacotes e mitigação
Modificações locais no WordPress não substituem a correção da biblioteca. O recurso nativo xmlrpc_enabled e as opções de plugins de segurança que desativam a autenticação XML-RPC não bloqueiam o método pingback.ping, pois ele opera sem exigir credenciais. Desabilitar os pingbacks elimina a rota pública testada, mas a biblioteca continuará exposta se outro plugin ou tema realizar uma requisição externa e receber um pacote comprimido.
A mitigação exige atualização no sistema operacional, na plataforma de hospedagem ou na imagem de contêiner. As versões originais corrigidas são a 1.0.10, 1.1.1 e 1.2.1.
Administradores devem verificar a string completa de revisão do pacote. No Debian 13, por exemplo, a falha foi resolvida no pacote libbrotli1 1.1.0-2+deb13u1 via backport. Após a instalação, é obrigatório reiniciar o Apache, o PHP-FPM e qualquer serviço que mantenha o Brotli na memória. Usuários de contêineres devem reconstruir a imagem, já que apenas reiniciar a instância atual preserva a biblioteca vulnerável.
Passos práticos para proteger o servidor Linux
Para garantir a segurança do ambiente e justificar a mitigação definitiva, a correção exige acesso administrativo ao servidor Linux. O processo técnico envolve verificar a versão atual da biblioteca, aplicar o pacote corrigido disponibilizado pelo fornecedor e forçar o recarregamento dos serviços que operam em memória.
Em distribuições baseadas em Debian ou Ubuntu, o administrador pode verificar o status do pacote instalado utilizando o comando dpkg -l | grep libbrotli. A atualização ocorre pelo gerenciador APT padrão. Ao executar sudo apt update && sudo apt install libbrotli1, o sistema operacional buscará a revisão de segurança mais recente (como a 1.1.0-2+deb13u1 no Debian 13) e substituirá os binários vulneráveis.
Para ambientes da família Red Hat, como CentOS, AlmaLinux ou Rocky Linux, o gerenciamento ocorre via DNF ou YUM. A verificação exige a busca pelo pacote “brotli” usando rpm -qa | grep brotli, seguida pelo comando sudo dnf upgrade brotli para aplicar o patch fornecido pelo repositório oficial da distribuição.
A etapa final do processo é a mais crítica. Como o decodificador de compressão opera ativamente na memória do servidor, atualizar o pacote no disco rígido não encerra a vulnerabilidade instantaneamente. O administrador precisa obrigatoriamente reiniciar todos os serviços web e interpretadores que dependem da biblioteca.
Em configurações padrão, isso significa reiniciar o servidor web (executando comandos como sudo systemctl restart apache2 ou sudo systemctl restart nginx) e o gerenciador de processos do PHP, como sudo systemctl restart php-fpm ou a versão específica em uso (por exemplo, php8.3-fpm). Sem o reinício destes serviços, o servidor continuará utilizando a versão comprometida do Brotli para processar as requisições externas originadas pelo WordPress.