O XML-RPC pode ser um Risco no WordPress
TL;DR
O xmlrpc.php é um protocolo de 2005 mantido no WordPress apenas por retrocompatibilidade comercial. Invasores utilizam o método system.multicall neste arquivo para testar milhares de senhas em uma única requisição HTTP, contornando bloqueios comuns de login.
Resposta Direta (Bottom Line Up Front – BLUF): Se o seu site WordPress apresenta picos inexplicáveis de uso de CPU na hospedagem, o culpado pode ser o arquivo xmlrpc.php sofrendo um ataque de amplificação (DDoS de força bruta). Bloquear esse protocolo legado na camada do servidor (via .htaccess no LiteSpeed ou Apache) corta o problema na origem, reduz o consumo de recursos e fecha uma porta que muita gente nem sabe que está aberta.
NOTA TÉCNICA: Todas as informações contidas aqui retratam a minha experiência e o meu método de trabalho, você é o total responsável por alterações no seu site ou no site de seus clientes. Nos responsabilizamos exclusivamente em parcerias formalizadas por contratos. Em dúvida, visite o Aviso Legal.
+7 cursos de WordPress não me ensinaram sobre o Arquivo XML-RPC
Trabalho profissionalmente com WordPress há mais de seis anos e já passei por mais de sete formações e certificações diferentes, desde cursos na Udemy até treinamentos de agências brasileiras especializadas em desenvolvimento web.
Em todas essas ementas, o foco era quase exclusivo no front-end: construtores de página, temas e instalação de dezenas de plugins.
Ao longo do tempo, assumindo a infraestrutura e a aquisição de clientes para empresas B2B, comecei a notar um padrão bizarro.
Sites de alto desempenho que eu gerenciava (desde portais de concursos online até clínicas de psicologia) apresentavam um uso altíssimo de CPU na Hostinger sem qualquer justificativa prévia de tráfego real.
Picos assimétricos de consumo que não faziam sentido no Google Analytics.
Ao investigar o back-end e os logs do servidor, encontrei a raiz de um dos problemas: requisições massivas disparadas contra um arquivo chamado xmlrpc.php. O consumo de recursos computacionais era real, e não um erro de leitura do painel.
Foi uma surpresa descobrir essa vulnerabilidade aberta por padrão, algo que nunca havia sido sequer mencionado nos cursos de “especialização”.
Isso reforça uma premissa fundamental na engenharia de sistemas e na web: você precisa ir além da interface. É o que eu reúno na minha área de tecnologia aplicada.
Principalmente hoje, com agentes de IA e vibe coders (gente que programa só pedindo código para a IA) por todos os lados, dominar aspectos de back-end e DevOps vai fazer toda a diferença para a sua empresa (vida profissional).
É necessário buscar conhecimento sobre como o back-end opera e entender os elementos que conectam o servidor web à operacionalidade da sua instalação WordPress.
A Origem do Legado: Por que o XML-RPC ainda existe?
O XML-RPC (Extensible Markup Language Remote Procedure Call) foi implementado no WordPress em 2005.
Naquela época, a internet era diferente.
A ideia era permitir que softwares de terceiros (como aplicativos de desktop para blogueiros) publicassem artigos remotamente no seu site sem precisar abrir o navegador.
Se é um protocolo antigo, por que a equipe do WordPress não o remove na versão atual?
A resposta é comercial: retrocompatibilidade.
Como o WordPress roda em uma fatia enorme da internet, remover esse arquivo nativamente poderia fazer com que sistemas ERP legados, integrações corporativas antigas e aplicativos que ainda usam o protocolo parassem de funcionar da noite para o dia.
A porta fica aberta para não quebrar a “web antiga”, e a responsabilidade de trancá-la passa a ser sua.
A Mecânica do Caos: O Ataque de Amplificação
O grande perigo do XML-RPC não é apenas a sua existência, mas uma função específica chamada system.multicall.
Em um ataque de força bruta normal na tela de login (wp-login.php), o invasor tenta uma senha por vez.
Um sistema de segurança pode bloquear o IP depois de algumas tentativas falhas (o número depende do plugin e da configuração).
No XML-RPC, o invasor pode empacotar centenas de tentativas de usuário e senha dentro de uma única requisição (Payload POST), como mostrou a Sucuri ao documentar esse tipo de ataque.
Para o seu servidor, ocorreu apenas uma requisição.
Mas o interpretador PHP e o banco de dados vão processar todas as tentativas.
É isso que pode causar o pico letal de CPU e memória, eventualmente, derrubando o site.
Diagnóstico Rápido: O seu XML-RPC está escutando a rede?
Fazer essa verificação é simples e não exige acesso ao servidor.
- Abra o seu navegador web.
- Digite a URL do seu site seguida do arquivo: https://seusite.com.br/xmlrpc.php
- Se a página carregar em branco contendo apenas a frase “XML-RPC server accepts POST requests only.”, seu protocolo está ativo, escutando a rede e vulnerável.
- Se retornar um erro 403 Forbidden ou 404 Not Found, a porta já está blindada.
Avaliação de Impacto: Devo desativar? E as integrações?
Na esmagadora maioria dos casos modernos: Sim, você deve desativar.
Desde a versão 4.7, o WordPress integrou nativamente a REST API.
É através dela que os sistemas modernos operam.
Se você planeja conectar o seu site a agentes de Inteligência Artificial, criar fluxos complexos no n8n ou no Make para publicação automatizada, você usará a REST API.
E, se o n8n for auto-hospedado, ele vai rodar num servidor seu. Eu explico o que avaliar em VPS para automação com IA.
Ela é infinitamente mais segura e utiliza métodos de autenticação robustos (como Application Passwords ou JWT).
Onde ter extremo cuidado: Inspecione se o seu site ou do seu cliente possui integração com sistemas de gestão (ERPs) muito antigos ou se depende estritamente do plugin Jetpack e do app mobile do WordPress.
Interromper o XML-RPC pode quebrar a comunicação dessas ferramentas específicas. Na minha experiência, nos sites em que bloqueei o XML-RPC, nenhuma integração quebrou de forma notável, mas isso depende de cada instalação, então confira antes.
Se você tem dúvidas sobre as dependências da sua infraestrutura ou o que está fazendo, não aja às cegas copiando códigos da internet ou de IAs.
O ideal é procurar ajuda com um profissional mais experiente que entenda de arquitetura de servidores.
Um Vetor Silencioso: Spam de Trackbacks e Pingbacks
Assim como o XML-RPC, os Trackbacks e Pingbacks são resquícios de uma arquitetura web antiga.
Originalmente desenhados para criar uma rede de notificações automatizadas entre blogs (avisando quando um site linkava para o outro), hoje esse sistema está obsoleto e foi massivamente cooptado por botnets para táticas de SEO Black-hat.
O arquivo responsável por processar essa comunicação clássica é o wp-trackback.php.
Diariamente, bots escaneiam instalações WordPress abertas e disparam requisições POST com dados falsos contra esse arquivo.
O objetivo do invasor é injetar um comentário pendente no seu painel de moderação contendo um link para o domínio deles.
Veja um exemplo no meu próprio caso abaixo:
A aposta é que o administrador aprove o “ping” por engano, fornecendo um backlink gratuito e manipulando a autoridade de domínio perante o Google.
O impacto sistêmico dessa vulnerabilidade se divide em duas frentes:
- Desperdício de Processamento: Cada ping falso força o PHP a processar a requisição e gravar dados inúteis no MySQL, consumindo CPU e memória.
- Risco de SEO e AEO: Aprovar acidentalmente esses links associa a infraestrutura do seu site a “vizinhanças ruins” da web (como sites de spam ou maliciosos), o que é penalizado em qualquer estratégia séria de ranqueamento.
Para resolver essa brecha na camada de aplicação, é necessário acessar o painel em Configurações > Discussão e desativar os avisos de links em novos artigos.
Para os artigos já publicados, basta fazer uma edição em massa na listagem de posts e alterar a opção de “Pings” para “Não permitir”.
Contudo, a trava definitiva contra o consumo de recursos também pode ser feita na borda do servidor, bloqueando o acesso direto ao arquivo.
Podemos usar um código simples no .htaccess como este:
# Bloqueio de protocolos legados na borda do servidor (XML-RPC e Trackbacks)
<FilesMatch "^(xmlrpc\.php|wp-trackback\.php)$">
Require all denied
</FilesMatch>Execução na Borda: Aplicação vs. Servidor
O erro mais comum ao tentar resolver isso é instalar um plugin para “Desativar o XML-RPC” ou inserir uma regra no arquivo functions.php do tema. Se você faz o bloqueio via PHP (Camada de Aplicação), o servidor web ainda precisará alocar memória RAM e processamento de CPU para carregar o core do WordPress apenas para dizer “não” ao invasor. E cada plugin a mais é dependência, como vimos na troca do Elementor Pro pelo nosso tema.
Em um ataque massivo, seu site vai cair por esgotamento de recursos do mesmo jeito.
A solução de engenharia correta é bloquear a requisição na borda do servidor web (LiteSpeed, Apache ou Nginx).
Assim, a conexão maliciosa é derrubada instantaneamente antes mesmo de o PHP ser acionado.
Passo a Passo: O Bloqueio Definitivo no LiteSpeed / Apache
Se você utiliza hospedagens como a Hostinger, que rodam LiteSpeed (que lê o arquivo .htaccess no formato do Apache), o bloqueio é feito no arquivo oculto .htaccess localizado na raiz da sua instalação.
- Acesse seu servidor via SSH ou pelo Gerenciador de Arquivos do painel da hospedagem.
- Navegue até a pasta raiz (geralmente
public_html). - Crie uma cópia de segurança: Via terminal, execute
cp .htaccess .htaccess.bkp_seguranca. Se o seu.htaccessjá acumulou regras antigas, vale fazer antes uma higienização do WordPress. - Abra o arquivo
.htaccesspara edição. - Insira o seguinte bloco de código logo na primeira linha, antes da instrução
# BEGIN WordPress:
# Bloqueio de acesso ao arquivo XML-RPC na borda do servidor (Apache 2.4)
<Files xmlrpc.php>
Require all denied
</Files>
Nota sobre versões: em tutoriais antigos você vai encontrar Order Allow,Deny e Deny from all. Essa é a sintaxe do Apache 2.2. No Apache 2.4 ela só funciona se o módulo mod_access_compat estiver ativo, e a forma recomendada pela documentação oficial é Require all denied. Se o seu servidor ainda usa a sintaxe antiga, o bloco legado é este:
# Sintaxe legada (Apache 2.2)
<Files xmlrpc.php>
Order Allow,Deny
Deny from all
</Files>
- Salve o arquivo. Refaça o teste no navegador: se a regra estiver valendo, você verá o bloqueio
403 Forbidden.
Considerações Finais
A segurança e a performance de uma operação digital B2B não se resolvem apenas instalando plugins visuais.
Como sempre defendo na engenharia de vendas online, é preciso entender as camadas do sistema. Eu uso um método para analisar o site por camadas, e a base de tudo está na arquitetura do WordPress.
Omitir a gestão do servidor e confiar cegamente em configurações padrão é deixar o sucesso (e o uptime) do seu negócio nas mãos do acaso.
Avalie sua infraestrutura, feche as portas legadas e adote protocolos modernos.
Além do .htaccess, eu também uso um setup completo na Cloudflare, com planos gratuitos, como mais uma camada antes do servidor. Esse setup vai ganhar uma documentação própria aqui no site.
Tenha MUITO CUIDADO ao seguir orientações de IA (LLMs) sobre infraestrutura, código ou qualquer aspecto que possa comprometer a segurança e funcionalidade de seus ativos digitais.
No topo desta página existe um botão com a opção de download de todo o conteúdo em markdown, para que você possa utilizar como referência no trabalho com seu agente de IA. O download é gratuito, não pede cadastro, não pede e-mail e você não entra em nenhuma lista. É um conteúdo 100% público, para qualquer pessoa acessar e baixar.
Precisa de ajuda? Fale comigo no WhatsApp.
Perguntas frequentes
O que é xmlrpc.php no WordPress?
É um arquivo nativo de protocolo de comunicação remota criado em 2005. Ele permite que aplicativos de terceiros publiquem e modifiquem conteúdos no WordPress sem acessar o painel administrativo pelo navegador.
Como saber se meu site está sofrendo um ataque de XML-RPC?
Os principais sintomas são lentidão extrema do site, painel da hospedagem relatando 100% de uso de CPU ou Memória RAM, e os logs de acesso do servidor mostrando centenas de requisições POST seguidas direcionadas ao arquivo /xmlrpc.php.
Desativar o XML-RPC quebra o Elementor ou Gutenberg?
Não. O editor de blocos nativo (Gutenberg) e construtores modernos como o Elementor utilizam a REST API moderna do WordPress (/wp-json/) para funcionar. Eles não dependem do protocolo legado XML-RPC.
Posso usar o n8n ou agentes de IA para postar no WordPress sem o XML-RPC?
Sim. A forma correta e atualizada de integrar automações como n8n, Make ou Inteligência Artificial ao WordPress é utilizando a REST API nativa combinada com o recurso de "Application Passwords" (Senhas de Aplicativo) do próprio CMS.
É seguro bloquear o XML-RPC pelo arquivo functions.php?
Embora funcione, não é recomendado para segurança e performance. Bloquear via functions.php exige que o servidor processe o código PHP a cada ataque, o que consome recursos. O bloqueio ideal deve ser feito no servidor web (via .htaccess no LiteSpeed/Apache ou nginx.conf no Nginx).