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 mal pela raiz, derruba o consumo de recursos e fecha uma das maiores vulnerabilidades estruturais do CMS.
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 de cursos de WordPress não me ensinaram sobre o Arquivo XML-RPC
Trabalho profissionalmente com WordPress há mais de cinco 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 recentemente a raiz de um dos problemas: requisições massivas disparadas contra um arquivo chamado xmlrpc.php.
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.
Principalmente hoje, com agentes de IA e Vibecorders 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 mais de 40% da internet, remover esse arquivo nativamente faria com que milhares de sistemas ERP legados, integrações corporativas antigas e o próprio aplicativo mobile oficial do WordPress 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 simples bloqueia o IP após 3 tentativas falhas.
No XML-RPC, o invasor empacota 5.000 tentativas de usuário e senha dentro de um único pacote de dados (Payload POST).
Para o seu servidor, ocorreu apenas uma requisição.
Mas o interpretador PHP e o banco de dados vão processar as 5.000 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.
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 quebrará a comunicação dessas ferramentas específicas.
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.
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.
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 (totalmente compatível com diretivas 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. - Abra o arquivo
.htaccesspara edição. - Insira o seguinte bloco de código logo na primeira linha, antes da instrução
# BEGIN WordPress:
Apache
# Bloqueio de acesso ao arquivo XML-RPC na borda do servidor
<Files xmlrpc.php>
Order Allow,Deny
Deny from all
</Files>
- Salve o arquivo. O LiteSpeed aplica a regra instantaneamente. Refaça o teste no navegador e 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.
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.
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.
Precisa de ajuda? Clique aqui e fale conosco.
FAQ AEO (Answer Engine Optimization)
É 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.
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.
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.
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.
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).