Uma simples requisição POST não autenticada enviada para o arquivo xmlrpc.php é capaz de derrubar um worker PHP em uma instalação padrão de WordPress — e não há nada de incomum no pedido que provoca esse efeito. O invasor envia um pingback cuja URL de origem aponta para um servidor sob seu próprio controle. O WordPress, por sua vez, busca essa URL, o servidor responde com um corpo comprimido em Brotli, e a biblioteca libcurl descompacta esse conteúdo antes mesmo que o WordPress tenha acesso a um único byte dele. Nas versões atuais, essa descompactação grava dados além do limite do buffer, abrindo caminho para o problema identificado como CVE-2026-111497.
O que é a falha CVE-2026-111497
Trata-se de uma vulnerabilidade de escrita fora dos limites (out-of-bounds write) no decodificador Brotli do Google. A própria Google atribuiu o CVE e classificou a gravidade com nota 9.2. A falha atinge as versões 1.0.3 a 1.2.0 do Brotli e foi corrigida em 21 de outubro de 2026, nas versões 1.0.10, 1.1.1 e 1.2.1. Já a CISA (agência de cibersegurança dos Estados Unidos) incluiu o caso em seu catálogo de vulnerabilidades conhecidas e exploradas em 27 de outubro, determinando que agências federais resolvessem o problema até 10 de novembro.
O ponto central é que o WordPress não distribui o Brotli diretamente. Ele depende do que o sistema operacional oferece, por meio da libcurl, em toda requisição de saída que realiza. Ou seja, não existe nada para atualizar dentro do próprio WordPress, nenhum plugin específico para corrigir, e nenhum sinal na requisição de entrada que denuncie o ataque — afinal, o payload malicioso nunca trafega na requisição original, mas sim na resposta vinda do servidor do atacante.
Diante desse cenário, as medidas possíveis envolvem fechar as rotas que levam ao decodificador e alterar a forma como o WordPress solicita respostas. Desativar o XML-RPC fecha a porta mais óbvia, mas, apesar disso, outras rotas continuam abertas, como chamadas de plugins e temas que buscam endereços informados por usuários, descoberta de oEmbed e a busca de feeds via SimplePie.
Como o WordPress chega até o decodificador vulnerável
Toda requisição de saída feita pelo WordPress passa pela WP_Http, pela biblioteca Requests embutida e pelo seu transporte via cURL. Esse transporte define o parâmetro CURLOPT_ENCODING como uma string vazia em todo handle, sem possibilidade de desativar esse comportamento. Um valor vazio equivale, para a libcurl, a aceitar qualquer compressão e descompactá-la automaticamente — assim, uma resposta marcada com Content-Encoding: br segue direto para o decodificador Brotli dentro da função curl_exec(). Configurar decompress => false não resolve, já que esse parâmetro apenas define o que o WordPress fará com um corpo que a libcurl já descompactou.
Um stream malformado faz o decodificador escrever além do buffer, invadindo a memória heap adjacente. Provocar essa falha é simples e funciona em qualquer build, de modo que uma única requisição pode derrubar um worker, e algumas centenas conseguem manter um site fora do ar. Já a execução remota de código é outra questão, que exige um ataque construído especificamente para cada alvo.
Pesquisadores já demonstraram shells funcionais contra builds padrão de Node.js e Bun, e provas de conceito públicas circulam na internet. No entanto, essas cadeias de ataque dependem de um offset fixo em uma build não-PIE específica e da adivinhação de um número de socket, falhando em qualquer outro contexto. O PHP rodando atrás de Apache ou FPM não é esse alvo, e nenhuma cadeia pública mira especificamente esse cenário até o momento. Já existem ferramentas públicas voltadas para o caminho do WordPress, mas elas se limitam a provocar a queda do serviço.
Um laboratório publicou, em 27 de outubro, uma demonstração que explora a falha via pingback e documenta dois resultados possíveis: um worker completamente derrubado, ou um worker travado em 100% de uso de CPU a partir de um payload com bem menos de cem bytes. O autor do estudo é claro ao afirmar que nenhuma execução de código está incluída e que a execução remota de código às cegas (blind remote RCE) ainda não foi estabelecida. Assim, a negação de serviço já é algo replicável facilmente, enquanto a parte mais complexa do ataque continua difícil — o que não significa impossível. Os offsets precisam ser calculados uma vez por build, e não uma vez por vítima, e nada impede que alguém que já tenha feito esse trabalho decida publicá-lo.
O que precisa ser planejado agora é a possibilidade de workers derrubados e a instabilidade que isso provoca. Já o vazamento de memória e a execução de código são cenários mais difíceis — e são eles que justificam a nota 9.2 atribuída à falha.
O caminho não autenticado da vulnerabilidade no WordPress
O método pingback.ping está presente no mapa padrão de métodos do XML-RPC e não exige nenhuma conta de usuário. Ele recebe uma URL de origem, e a função pingback_ping() busca esse endereço usando wp_safe_remote_get(). Uma instalação padrão tem o XML-RPC ativado, a opção default_ping_status configurada como aberta e pelo menos um post passível de pingback — por isso, basta ao atacante apontar a origem para seu próprio servidor e responder com o stream malicioso. O worker que processa essa requisição decodifica o conteúdo e trava.
Muitos sites nunca tiveram essa rota aberta. Hospedagens gerenciadas costumam bloquear o acesso ao xmlrpc.php diretamente na borda da infraestrutura, e scripts de hardening já desativam esse recurso há anos — por isso, há boa chance de que essa porta já esteja fechada na sua instalação. Ainda assim, vale confirmar em vez de simplesmente presumir, já que a expressão “XML-RPC desativado” pode significar duas coisas bem diferentes. Um bloqueio no servidor web realmente fecha a rota. Já o filtro xmlrpc_enabled, usado por muitos plugins de forma simplificada, não faz isso: ele apenas restringe os métodos que exigem login, e o pingback não é um deles. Um site que usa apenas esse filtro responde a um pingback exatamente como um site sem nenhuma proteção.
Uma única requisição revela qual situação se aplica ao seu site. O endereço de origem usado abaixo é local, e o WordPress o rejeita antes mesmo de tentar buscá-lo — por isso, é seguro testar contra o próprio site:
- Um retorno 403, 404 ou qualquer resposta que não seja XML indica que a rota está bloqueada e esse caminho não se aplica ao seu site.
- Uma falha informando que o método pingback.ping não existe (requested method pingback.ping does not exist) também mostra que o método foi desativado, fechando essa porta.
- Qualquer outra resposta do tipo methodResponse, seja um erro ou não, indica que a função pingback_ping() foi executada e que a rota está aberta.
Vale destacar que nada disso cobre os caminhos relacionados a plugins, oEmbed e feeds mencionados anteriormente — ou seja, fechar a rota de pingback reduz a exposição, mas não a elimina por completo.
Os riscos vindos de plugins e temas
Como o problema está no transporte de dados, ele não fica restrito ao XML-RPC. Qualquer plugin que busque, no lado do servidor, um endereço fornecido por um visitante acaba caindo no mesmo decodificador vulnerável — é o caso de prévias de links, importadores de URLs e imagens, verificadores de webhooks e proxies de avatar. Nesse sentido, usar o wrapper considerado “seguro” não resolve o problema: tudo o que wp_safe_remote_get() acrescenta em relação a wp_remote_get() é o filtro reject_unsafe_urls, criado contra SSRF, que bloqueia IPs internos e portas diferentes de 80, 443 e 8080. Esse filtro, porém, nunca verifica o cabeçalho Content-Encoding, de modo que um servidor malicioso comum, operando na porta 443, passa por ele sem qualquer obstáculo.
Por que um firewall de aplicação não detecta o ataque
Um WAF (firewall de aplicação web) toma decisões com base no que o visitante enviou — e é justamente nesse ponto que este ataque não aparece. Uma chamada a pingback.ping, ou mesmo uma chamada feita por um plugin, carrega apenas uma URL e pouco mais, parecendo uma requisição comum. A parte realmente perigosa chega depois, vinda do próprio servidor do atacante. Para diferenciar essa requisição de uma legítima, o WAF precisaria buscar a URL por conta própria e decodificar a resposta em Brotli — exatamente o passo que provoca a falha. Um firewall baseado em PHP, por sua vez, nem chega a esse ponto, já que roda dentro do WordPress, enquanto a decodificação ocorre em uma camada inferior, na libcurl, antes de qualquer execução de código PHP.
Em resumo, o cenário descrito por CVE-2026-111497 mostra como uma dependência indireta — no caso, a biblioteca Brotli usada pelo sistema operacional através da libcurl — pode comprometer a estabilidade de sites WordPress mesmo sem qualquer falha no núcleo da plataforma ou em seus plugins. Até que soluções específicas de mitigação se consolidem, desativar o XML-RPC e revisar plugins que fazem requisições externas seguem sendo as medidas mais práticas para reduzir a superfície de exposição.
Com informações de patchstack.com.
