Como desativar o XML-RPC com segurança no WordPress
O que é o XML-RPC no WordPress?
O XML-RPC é um protocolo antigo de acesso remoto do WordPress, exposto pelo arquivo xmlrpc.php na raiz do site. Ele permite publicar por apps externos, pingbacks e algumas integrações legadas. O problema é de segurança: o método system.multicall deixa o atacante testar centenas de senhas em uma única requisição (força bruta amplificada), e o pingback é usado em ataques de negação de serviço refletida. A maioria dos sites hoje usa a REST API e não precisa do XML-RPC, então desativá-lo é uma medida de hardening segura.
Como identificar
- No log de acesso aparecem dezenas de POST para “/xmlrpc.php” vindos do mesmo IP em segundos.
- O plugin de segurança reporta “XML-RPC multicall attempt” ou bloqueios repetidos no xmlrpc.php.
- Picos de CPU e lentidão coincidindo com requisições a xmlrpc.php no relatório do servidor.
- Recebe pingbacks de spam ou seu site aparece como origem de um ataque de pingback reportado pelo host.
Como prevenir
- Mantenha o xmlrpc.php bloqueado por padrão em sites que não dependem dele
- Use um firewall/WAF que limite requisições a xmlrpc.php e bloqueie multicall
- Prefira a REST API para integrações modernas, que tem controle de autenticação mais granular
Causa
- O xmlrpc.php fica ativo por padrão em toda instalação WordPress, mesmo sem app remoto configurado.
- O método system.multicall permite testar muitas senhas numa só chamada, burlando limites de tentativa de login.
- O recurso de pingback (X-Pingback) é explorado para ataques DDoS refletidos usando seu site como amplificador.
- Bots varrem a internet em busca de xmlrpc.php aberto porque é um vetor de ataque conhecido e padronizado.
- Plugins de cache ou firewall mal configurados deixam o xmlrpc.php fora das regras de bloqueio.
Como resolver
- Confirme se você realmente não usa o XML-RPC: verifique se algum app móvel, o Jetpack clássico ou uma integração externa pública via xmlrpc.php. Se nada depende dele, pode bloquear com segurança.
- Bloqueie o arquivo no servidor (Apache): no Apache, a forma mais robusta é negar acesso ao xmlrpc.php direto no .htaccess da raiz, antes mesmo de o PHP rodar. Use o bloco de código abaixo, que recusa qualquer requisição ao arquivo.
- No Nginx, negue pela configuração do site: adicione um bloco location para xmlrpc.php retornando 403 e peça ao host para recarregar a configuração.
- Alternativa via filtro do WordPress: se não puder editar o servidor, desative o XML-RPC por código no functions.php do tema-filho ou em um plugin de snippets, com o filtro xmlrpc_enabled e a remoção do cabeçalho de pingback.
- Valide o bloqueio: acesse seudominio.com/xmlrpc.php no navegador. Bloqueado certo, retorna 403 Forbidden em vez da mensagem "XML-RPC server accepts POST requests only".
# .htaccess da raiz - nega acesso ao xmlrpc.php antes de o PHP rodar (Apache)
<Files xmlrpc.php>
Require all denied
</Files>
# Em servidores Apache mais antigos (2.2), use a sintaxe equivalente:
# <Files xmlrpc.php>
# Order Deny,Allow
# Deny from all
# </Files>Perguntas frequentes
Desativar o XML-RPC quebra alguma coisa no meu site?
Bloquear pelo .htaccess é melhor que desativar por plugin?
O XML-RPC é o mesmo que a REST API do WordPress?
Como sei se estou sob ataque de força bruta pelo XML-RPC?
Preciso desativar o XML-RPC se já uso um firewall?
Como reativo o XML-RPC se precisar depois?
Como corrigir o bloqueio de login que não funciona no All in One Security
O AIOS não bloqueia login quando o recurso Login Lockdown do All in One Security esta desativado, com limite de tentativas alto demais, ou quando os ataques chegam por um formulário de login customizado que não passa pelo wp-login.php. Nesses casos o plugin registra as falhas mas nunca tranca o IP atacante.
Como limpar o Japanese Keyword Hack no WordPress
O Japanese Keyword Hack e uma infecao de SEO spam que cria milhares de páginas em japones no seu site WordPress e as injeta nos resultados do Google. Elas vendem produtos falsificados e usam a autoridade do seu domínio para ranquear.
Como resolver Are you sure you want to do this no WordPress
Tem certeza que deseja fazer isso e a mensagem que o WordPress mostra quando o nonce de segurança de uma acao expira ou não confere. O nonce e um token temporario que prova que o pedido partiu de uma tela legitima, e ele caduca em cerca de 24 horas.
Como corrigir a alteração de prefixo do banco que falha no All in One Security
No All in One Security, mudar o prefixo do banco falha quando o wp-config.php não é gravável pelo PHP ou quando o usuário do MySQL não tem privilégio ALTER para renomear as tabelas. A correção exige liberar a escrita do arquivo e conceder o privilégio.
Como corrigir API REST do WordPress exposta
A API REST exposta no WordPress é o problema de a rota /wp-json/wp/v2/users listar publicamente os nomes de usuário do site, entregando ao invasor metade do par login-senha. Corrigir significa restringir esse endpoint e os dados sensíveis sem desligar a REST API, que muitos recursos do site usam.
Como corrigir o 404 Lockout que bloqueia visitantes no All in One Security
O AIOS 404 lockout acontece quando o recurso 404 Detection do All in One Security conta os erros 404 de um visitante e bloqueia o IP dele depois de passar do limite no intervalo configurado. Quando assets quebrados, links antigos ou um favicon ausente geram 404 demais, o plugin tranca visitantes legitimos e até o próprio administrador.
