# Desativar XMLRPC WordPress
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 , 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.
Riscos do XML-RPC ativo no WordPress por tipo de ataque
Vetor
Como funciona
Impacto observado
Forca bruta amplificada
system.multicall agrupa centenas de senhas numa requisicao
Login quebrado sem rastro no wp-login
DDoS por pingback
O site e usado para refletir trafego contra terceiros
Pico de CPU e IP marcado como abusivo
SSRF via pingback
Requisicoes internas forjadas a partir do servidor
Varredura de rede interna do host
## 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 , 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.
Perguntas frequentes sobre desativar XMLRPC WordPress
É possível desativar o XML-RPC sem instalar nenhum plugin?
Sim, dá para desativar sem plugin de duas formas. A primeira é o filtro `add_filter( 'xmlrpc_enabled', '__return_false' );` no functions.PHP do tema filho, que desliga a autenticação. A segunda, mais forte, é negar o acesso ao xmlrpc.PHP no servidor, com `Require all denied` no Apache ou `deny all` no Nginx. O bloqueio por servidor é o único que para a requisição antes de o PHP carregar.
Por que o XML-RPC causa picos de CPU mesmo sem invasão?
O XML-RPC causa pico de CPU porque cada requisição de força bruta inicializa o WordPress inteiro e o método system.multicall processa centenas de logins por envio. Mesmo sem o atacante acertar a senha, o servidor gasta recurso respondendo milhares de tentativas por minuto. Bloquear o arquivo no servidor mata o tráfego na borda e o pico de CPU cai junto, porque o PHP nem chega a ser chamado.
Qual a diferença entre risco atual e CVE histórica no XML-RPC?
Risco atual é uma falha sem patch disponível hoje; CVE histórica é uma falha já corrigida em alguma versão. A CVE-2023-2996 do Jetpack, com CVSS 8.8, foi corrigida na versão 12.1.1, então só expõe quem ainda roda versão anterior. A versão instalada decide o risco, não o nome do plugin. Atualizar para a versão com patch neutraliza a maioria das CVEs históricas.
Como saber se o bloqueio do XML-RPC realmente funcionou?
Para confirmar o bloqueio, rode `curl -I https://seusite.com/xmlrpc.php` no terminal e leia o status HTTP. Um código 403 ou 405 indica que o bloqueio pegou; um 200 mostra que o endpoint segue aberto, mesmo que o painel diga o contrário. Não confie no checkbox do plugin: o teste por curl lê a resposta real do servidor e é o único jeito de ter certeza.
Desativar o XML-RPC quebra o aplicativo móvel do WordPress?
Sim, o bloqueio total do XML-RPC quebra o app móvel oficial e o Jetpack, que dependem desse canal para sincronizar. Se você publica pelo celular ou usa estatísticas do Jetpack, prefira o bloqueio seletivo: desligue só o pingback com o filtro `xmlrpc_methods` ou libere o arquivo por IP no firewall. Assim você corta o vetor de DDoS e mantém a integração legítima funcionando.
## 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.