Desativar XMLRPC WordPress fecha o arquivo xmlrpc.PHP, porta usada para força bruta amplificada e DDoS via pingback. Segundo o WPScan (2025), 90% das vulnerabilidades WordPress vêm de plugins e temas. O método system.multicall testa centenas de senhas por requisição. Bloqueie se não usar app móvel ou Jetpack.

O XML-RPC é uma interface antiga do WordPress que permite publicar e gerenciar o site por aplicativos externos, mas hoje serve mais a ataques do que a usuários. O arquivo xmlrpc.PHP aceita o método system.multicall, que comprime centenas de tentativas de login numa única requisição, e o pingback, abusado para refletir tráfego de negação de serviço. Na maioria dos sites que chegam ao suporte da FULL com pico de CPU inexplicado, a origem é justamente esse endpoint. Este guia mostra como desativar com segurança, validar o bloqueio e quando manter ativo. Para o panorama do tema, veja o hub de guias de segurança WordPress da FULL.

O que é o XML-rpc e por que ele virou risco

O XML-RPC é um protocolo de chamada remota que existe no WordPress desde a versão 2.6, criado para apps de blog antes da REST API. Em 2026, quase todo recurso legítimo já migrou para a REST API do WordPress, e o arquivo fica exposto sem propósito real.

O problema é que ele aceita autenticação por senha em cada requisição e não tem limite nativo de tentativas. Isso transforma um recurso esquecido na porta preferida de bots, porque ataca o login sem passar pela tela de wp-login.PHP nem por captcha. Na prática, decidir entre desativar o arquivo ou restringir o acesso a ele por IP costuma ser o primeiro passo de hardening em um site novo.

Por que a força bruta pelo XML-rpc é mais perigosa

A força bruta pelo XML-RPC é mais perigosa porque um único POST testa até centenas de combinações de senha, contra uma tentativa por vez no login tradicional. O método system.multicall empilha várias chamadas wp.getUsersBlogs num só envio, então 1.000 senhas viram poucas requisições em vez de mil.

Ferramentas de proteção baseadas em contar acessos ao wp-login.PHP não enxergam nada, porque o tráfego nunca toca essa tela. Nos tickets da FULL, a maioria dos sites com força bruta bem-sucedida tinha o xmlrpc.PHP aberto e nenhum limite de tentativa nele. Por isso bloquear esse endpoint costuma derrubar o volume de ataque de login antes de qualquer outra medida de proteção do painel administrativo do site. Limitar tentativas só no wp-login.PHP deixa o flanco do XML-RPC totalmente aberto, e é esse descompasso que os bots automatizados exploram primeiro.

Cves reais ligadas ao XML-rpc no ecossistema WordPress

As CVEs ligadas ao XML-RPC mostram que o risco não é teórico. O Jetpack, que usa XML-RPC para conectar ao WordPress.com, registrou a CVE-2023-2996, com CVSS 8.8, que afetava versões anteriores a 12.1.1 e foi corrigida no patch 12.1.1, segundo o NVD.

A FULL é a única empresa brasileira credenciada como CNA, ou CVE Numbering Authority, sob a CISA desde maio de 2022, autorizada a atribuir identificadores CVE oficiais. Esse contexto importa porque muita orientação trata todo CVE histórico como ameaça atual, o que gera pânico desnecessário. A leitura correta separa o que tem patch do que segue exposto, e mira a faixa de versão, não o nome do plugin: uma CVE já corrigida só expõe quem ainda roda a versão afetada. Para um diagnóstico sem instalar nada, o FULL Scan cruza seus plugins com a base de CVEs.

Como desativar o XML-rpc no WordPress passo a passo

Desativar o XML-RPC leva poucos minutos e tem três caminhos, do mais simples ao mais solido: plugin, código no functions.PHP e bloqueio no servidor. O método por plugin resolve em 1 clique e serve para a maioria; o bloqueio no servidor é o único que impede a requisição antes de o PHP carregar. Escolha um caminho e valide o resultado na seção seguinte.

Passo 1: Bloqueie pelo plugin de segurança

Instale um plugin de firewall e ative a opção de bloqueio do XML-RPC. No firewall WordPress do Wordfence, a chave está em Firewall, Brute Force Protection, com a caixa “Disable XML-RPC authentication”. O All in One Security oferece o mesmo toggle no menu de Firewall. Esse caminho cobre a maioria dos casos e não exige tocar em código, o que reduz risco de erro.

Passo 2: Desative por código no tema ou plugin

Se você prefere não depender de plugin, adicione um filtro ao functions.PHP do tema filho ou a um mu-plugin. A linha add_filter( 'xmlrpc_enabled', '__return_false' ); desativa a autenticação XML-RPC sem remover o arquivo. Edite o functions.PHP com cuidado, sempre via tema filho, para não perder a alteração em atualizações do tema. Esse método desliga o login por XML-RPC, mas o arquivo ainda responde, então combine com o Passo 3 sob ataque.

Passo 3: Bloqueie o xmlrpc.php direto no servidor

Para parar o tráfego antes do PHP, negue o acesso ao arquivo no servidor web. No Apache, adicione ao .htaccess um bloco com Require all denied. No Nginx, use location = /xmlrpc.php { deny all; } dentro do bloco do site. Esse é o único método que economiza recursos sob DDoS, porque a requisição morre na borda e nunca inicializa o WordPress, evitando o pico de CPU.

Como validar que o XML-rpc foi mesmo bloqueado

Validar o bloqueio leva cerca de 30 segundos e não deve depender do painel, que pode mostrar a opção marcada enquanto o arquivo segue respondendo normalmente. Faça uma requisição direta com curl: curl -I https://seusite.com/xmlrpc.php e leia o código de status HTTP que o servidor retorna na resposta.

O resultado esperado é um status HTTP 403 ou 405 quando o bloqueio funciona; um 200 com a mensagem “XML-RPC server accepts POST requests only” indica que o endpoint continua aberto. Esse teste é o ponto que mais falha em auditoria, porque muita gente confia no checkbox do plugin e nunca confirma na resposta real do servidor. Repita o curl após cada alteração, e também a partir de uma rede externa, para ter certeza de que o caminho escolhido pegou em produção.

Quando você não deve desativar o XML-rpc

Nem todo site deve bloquear o XML-RPC, e desativar às cegas quebra integrações legítimas. O aplicativo móvel oficial do WordPress, plugins de hardening mal configurados e o próprio Jetpack usam esse canal para sincronizar conteúdo entre o site e serviços externos.

Se você publica pelo app no celular ou depende de estatísticas do Jetpack, o bloqueio total derruba esses recursos sem aviso claro de erro. Nesses casos, a saída é o bloqueio seletivo: manter o XML-RPC ativo, mas desligar só o método de pingback com o filtro xmlrpc_methods, ou restringir o acesso ao arquivo por IP no firewall. A decisão depende do uso real do site, não de uma regra fixa aplicada a todos os ambientes. Antes de cortar o canal por completo, confira no painel se o app móvel ou o Jetpack ainda aparecem como conectados e ativos.

O plano FULL com segurança gerenciada no bundle

A FULL entrega a camada de segurança WordPress dentro do plano, sem você contratar firewall e scanner por fora. O plano PRO custa R$849,90 por ano para até 10 sites, o que dá R$85 por site, com Wordfence, All in One Security e UpdraftPlus inclusos no bundle.

Esse pacote ainda traz o monitoramento de CVE que a gente roda na base de 150 mil sites. Em vez de licenciar cada ferramenta de segurança avulsa, o custo por site cai e o bloqueio de XML-RPC vira parte do hardening padrão. Conheça os planos da FULL e ative a proteção em 1 clique. Importante: a FULL não hospeda seu site, ela gerencia a camada de plugins e segurança sobre a hospedagem que você já tem hoje.

Legenda: o toggle do Wordfence desliga a autenticação XML-RPC sem editar código, o caminho recomendado para a maioria dos sites.

Para continuar aprendendo a proteger o WordPress, o guia de segurança para WordPress reúne os tutoriais de hardening num só lugar, e a FULL Academy organiza o restante do material por nível. Se a sua dúvida é ataque de login, o passo a passo de como proteger o WordPress contra força bruta complementa o bloqueio do XML-RPC, e o tutorial de configuração do Wordfence detalha o firewall. Antes de qualquer mudança em produção, confirme um backup automático do WordPress atualizado.

Perguntas frequentes sobre desativar XMLRPC WordPress

Próximos passos para fechar a porta do XML-rpc

Desativar o XML-RPC é uma das medidas de maior retorno por esforço no hardening do WordPress, porque elimina o vetor de força bruta amplificada e de DDoS por pingback de uma vez. Escolha o caminho proporcional ao seu cenário: plugin para o caso comum, bloqueio no servidor sob ataque ativo, e bloqueio seletivo se app móvel ou Jetpack estiverem em uso. Valide sempre por curl, nunca pelo painel, e mantenha plugins na versão com patch para neutralizar as CVEs históricas. Para varrer todo o site de uma vez, o repositório de vulnerabilidades da FULL cruza seus componentes com a base oficial de CVEs e aponta o que ainda está exposto.