O XML RPC é um recurso antigo do WordPress que permite comunicação remota com o site. Ele pode ser usado por aplicativos móveis, integrações externas e alguns plugins. O problema é que também pode ser explorado por robôs para tentativas repetidas de login, abuso de pingbacks e aumento de carga no servidor.
Desativar XML RPC no WordPress faz sentido quando o site não usa integrações que dependem desse recurso. A decisão não deve ser automática. Primeiro você confirma se ele está ativo, verifica se algum plugin depende dele, faz backup e só então aplica o bloqueio.
Este guia mostra como revisar o XML RPC com cuidado. A meta é reduzir superfície de ataque sem quebrar recursos legítimos do site.
O que você resolve ao revisar o XML RPC
O arquivo associado ao recurso costuma ficar em xmlrpc.php, na raiz da instalação do WordPress. Em muitos sites ele responde mesmo quando o dono nunca usa acesso remoto.
Ao revisar esse ponto, você pode reduzir três tipos de problema:
- Tentativas automatizadas de login usando chamadas remotas.
- Requisições repetidas que aumentam consumo de CPU e memória.
- Uso indevido de pingbacks para gerar tráfego indesejado ou abuso externo.
Isso não substitui uma rotina completa de segurança. Continue cuidando de senha, permissões, atualizações, backup e autenticação em dois fatores. Se o seu problema principal é invasão por senha fraca, comece também pelo guia de como proteger o login do WordPress em /guias/proteger_login_wordpress/.
Quando faz sentido desativar XML RPC no WordPress
A desativação costuma fazer sentido em sites institucionais, blogs simples, landing pages, portfólios e sites de prestadores de serviço que são administrados apenas pelo painel do WordPress no navegador.
Exemplo prático: uma clínica tem um site institucional com páginas de serviços, formulário de contato e blog. A equipe acessa pelo endereço normal de administração. Não usa aplicativo móvel, Jetpack, publicação remota nem integração externa. Nesse cenário, manter XML RPC aberto geralmente não traz benefício claro.
Já em outros casos, bloquear tudo pode causar efeito colateral. Tenha cuidado se o site usa:
- Jetpack com recursos que dependem de comunicação remota.
- Aplicativo móvel do WordPress para publicar posts.
- Integrações antigas de automação editorial.
- Ferramentas externas de gestão de múltiplos sites.
- Plugins que sincronizam conteúdo por chamadas remotas.
Se você não sabe se usa alguma dessas integrações, trate a mudança como manutenção. Faça em horário de menor acesso e tenha plano de reversão.
Pré requisitos antes de mexer no site
Antes de bloquear XML RPC, prepare o ambiente. Segurança boa começa com mudança reversível.
Faça estes passos:
- Crie um backup recente dos arquivos e do banco de dados.
- Anote quais plugins estão ativos.
- Verifique se alguém da equipe usa aplicativo móvel.
- Confirme se Jetpack ou integrações externas estão em uso.
- Avise quem publica conteúdo no site.
- Separe um período curto para teste após a alteração.
Se você ainda não tem rotina de cópia segura, veja o guia de backup do WordPress antes de alterar o site em /hospedagem/backup_wordpress_antes_de_alterar_site/.
Em ambientes com VPS, como na LetsCloud, também vale revisar logs de acesso e criar um snapshot ou backup antes da mudança. Isso ajuda quando você quer testar regra de servidor sem depender apenas de plugin.
Como verificar se XML RPC está ativo
O teste mais simples é abrir no navegador o endereço do seu domínio seguido de /xmlrpc.php.
Por exemplo:
https://seudominio.com.br/xmlrpc.php
Se aparecer uma mensagem parecida com “XML RPC server accepts POST requests only”, o arquivo está respondendo. Isso não quer dizer que o site foi invadido. Quer dizer apenas que o endpoint está disponível.
Também vale olhar os logs da hospedagem. Procure por muitas chamadas para xmlrpc.php, especialmente vindas de vários IPs diferentes. Um volume alto pode indicar tentativa automatizada.
Sinais de atenção:
- Muitas requisições ao mesmo arquivo em poucos minutos.
- Picos de consumo sem campanha ou tráfego real.
- Tentativas de login repetidas no mesmo horário.
- Alertas de plugin de segurança mencionando XML RPC.
Se você usa painel de servidor, firewall ou monitoramento, salve uma captura ou anotação do padrão antes do bloqueio. Isso ajuda a comparar depois.
Opção 1: bloquear XML RPC com plugin
A forma mais simples para iniciantes é usar um plugin de segurança que permita desativar XML RPC ou limitar o recurso.
Essa opção é útil quando você não tem acesso ao servidor ou não quer editar regras técnicas. O cuidado é evitar instalar vários plugins que fazem a mesma coisa. Segurança em excesso mal configurada pode criar conflito, lentidão e bloqueios indevidos.
Ao escolher um plugin, observe:
- Se ele recebe atualizações frequentes.
- Se tem opção clara para XML RPC.
- Se permite reverter a configuração com facilidade.
- Se não duplica funções que você já usa em outro plugin.
- Se a documentação explica impacto em Jetpack e aplicativo móvel.
Depois de ativar a opção, teste o endereço /xmlrpc.php novamente. O ideal é receber bloqueio, erro de acesso ou resposta controlada pelo plugin.
Use plugin quando você quer praticidade. Evite plugin novo apenas para uma regra simples se o site já tem acesso ao servidor e alguém técnico para aplicar o bloqueio.
Opção 2: bloquear XML RPC no servidor
Quando você tem acesso à configuração da hospedagem, pode bloquear o arquivo no servidor. Essa abordagem reduz a dependência de plugin e costuma ser mais limpa em sites mantidos por equipe técnica.
O caminho exato depende do servidor, painel e stack usada. Em hospedagens com Apache, Nginx ou painel gerenciado, a regra pode ficar em locais diferentes. Por isso, não copie regra aleatória sem entender onde ela será aplicada.
A lógica é simples: negar acesso público ao arquivo xmlrpc.php, ou permitir apenas origens específicas quando houver integração legítima.
Em uma VPS na LetsCloud, por exemplo, esse bloqueio pode ser planejado junto com firewall, logs e backup. A vantagem é ter mais controle. A desvantagem é que uma regra errada pode afetar o site ou retornar erro em integrações necessárias.
Antes de aplicar em produção, se possível, teste em ambiente separado. Se o site tem tráfego comercial, faça a mudança em janela de menor movimento.
Opção 3: limitar por firewall ou regra de segurança
Nem sempre você precisa desativar tudo. Em alguns cenários, limitar é melhor do que bloquear.
Essa alternativa faz sentido quando uma integração confiável precisa acessar XML RPC, mas você quer impedir abuso de robôs. O firewall pode aplicar limite de requisições, bloquear padrões suspeitos ou permitir apenas IPs conhecidos.
Use limitação quando:
- O site depende de Jetpack ou ferramenta externa.
- Há integração legítima com origem conhecida.
- O volume de abuso é concentrado em poucos padrões.
- A equipe técnica consegue monitorar logs.
Evite limitação complexa em site pequeno sem manutenção. Regra difícil de entender vira problema no futuro, principalmente quando outra pessoa assume o projeto.
Como validar se nada quebrou depois da mudança
Depois de bloquear ou limitar XML RPC, faça uma validação curta e objetiva.
Teste:
- Acesso ao painel do WordPress.
- Publicação de um post de teste como rascunho.
- Envio de formulário de contato.
- Funcionamento do Jetpack, se estiver instalado.
- Aplicativo móvel, se alguém usa.
- Integrações externas de automação ou gestão.
- Logs de erro da hospedagem.
Depois, abra novamente /xmlrpc.php. A resposta deve indicar bloqueio ou negar o acesso. Também acompanhe os logs por algumas horas ou dias. A redução de chamadas suspeitas é um bom sinal, mas não trate isso como garantia de segurança total.
Se você fez a mudança junto com outras alterações, fica mais difícil saber o que causou problema. Por isso, prefira mudar uma coisa por vez.
Erros comuns ao desativar XML RPC
O erro mais perigoso é apagar o arquivo xmlrpc.php. Não faça isso. O arquivo faz parte do WordPress e pode voltar em atualização. Além disso, apagar arquivo do núcleo não é uma boa prática de manutenção.
Outros erros comuns:
- Bloquear XML RPC sem backup.
- Não avisar a equipe que usa aplicativo móvel.
- Instalar dois plugins de segurança com funções repetidas.
- Aplicar regra de servidor copiada sem testar.
- Confundir bloqueio de XML RPC com proteção completa de login.
- Ignorar logs após a mudança.
Também é comum bloquear XML RPC e esquecer de reforçar permissões de usuários. Se várias pessoas acessam o painel, revise funções e acessos com o guia de permissões de usuários no WordPress em /guias/permissoes_usuarios_wordpress_seguranca/.
Checklist final de segurança
Use este checklist antes de considerar a tarefa concluída:
- Backup feito e restaurável.
- Dependências revisadas.
- XML RPC testado antes da mudança.
- Bloqueio ou limitação aplicado.
- Painel do WordPress funcionando.
- Publicação de conteúdo validada.
- Formulários testados.
- Jetpack e aplicativo móvel conferidos, se existirem.
- Logs revisados após a alteração.
- Equipe avisada sobre o que mudou.
Se o site ainda não usa autenticação em dois fatores, esse é um próximo ajuste importante. Veja o guia de autenticação de dois fatores no WordPress em /guias/autenticacao_dois_fatores_wordpress/.
Perguntas frequentes
Posso apagar o arquivo xmlrpc.php?
Não é recomendado. O arquivo faz parte do núcleo do WordPress. O caminho mais seguro é bloquear ou limitar o acesso, sem alterar arquivos centrais.
XML RPC é sempre perigoso?
Não. Ele é um recurso legítimo. O risco aparece quando fica aberto sem necessidade, recebe muitas tentativas automatizadas ou é usado em um site sem monitoramento.
Desativar XML RPC melhora performance?
Pode reduzir carga quando o site recebe muitas requisições abusivas nesse endpoint. Em sites sem tráfego suspeito, a diferença pode ser pequena. Performance depende de vários fatores.
O Jetpack para de funcionar se eu bloquear XML RPC?
Alguns recursos podem ser afetados. Antes de bloquear, verifique a documentação do plugin e teste as funções usadas no seu site.
Preciso de VPS para bloquear XML RPC?
Não. Um plugin pode resolver em muitos sites. A VPS é útil quando você quer controle maior de regras, logs, firewall e rotina de manutenção. Nesse caso, uma infraestrutura como a LetsCloud pode facilitar a gestão técnica, desde que alguém acompanhe a configuração.
Próximos passos para proteger o WordPress
Desativar XML RPC é uma boa revisão quando o recurso não é usado. Mas ele é apenas uma parte da segurança do WordPress.
Depois deste ajuste, priorize três frentes: proteger o login, reduzir privilégios de usuários e manter backup testado. Essa combinação é mais importante do que acumular plugins sem critério.
Se você está fazendo uma revisão completa, siga esta ordem: backup, atualização controlada, login protegido, autenticação em dois fatores, permissões corretas e monitoramento de erros. Assim, cada mudança tem contexto e pode ser revertida se algo sair do esperado.
