O seu site está lento, o seu fornecedor de alojamento envia avisos sobre limites excedidos e os registos mostram um fluxo interminável de pedidos POST para xmlrpc.php. Se administra WordPress, este pesadelo é-lhe provavelmente familiar.

O ficheiro xmlrpc.php é um elemento silencioso, mas extremamente perigoso, de qualquer instalação WordPress. Vive na raiz do seu site desde a instalação do CMS e continua a ser um ponto de entrada favorito para bots e atacantes há décadas. De acordo com o relatório Wordfence de 2024, os ataques XML-RPC estão entre os cinco principais vetores de ameaça para sites WordPress, e nada mudou em 2026.

No entanto, a maioria dos proprietários de sites não faz ideia da razão pela qual este ficheiro existe ou como neutralizá-lo. Este guia aborda quatro métodos funcionais para bloquear o xmlrpc.php, desde uma regra rápida no .htaccess até uma firewall ao nível da CDN. Sem palha, apenas código testado e explicações sobre quando usar cada método.

💡 Resumo rápido:

• Verifique se o seu xmlrpc.php responde a pedidos POST (provavelmente sim)
• Escolha um método de bloqueio: htaccess, código no functions.php, plugin ou WAF
• Adicione a regra de bloqueio e verifique se o endpoint devolve 403 Forbidden
• Se usar o Jetpack, configure proteção de firewall direcionada em vez de desativar totalmente

O que é o xmlrpc.php e porque ainda está no WordPress

XML-RPC (Remote Procedure Call) é um protocolo que permite que aplicações externas comuniquem com o WordPress. Foi adicionado ao núcleo na versão 1.5 e serviu durante décadas como a única API para publicação remota: as aplicações móveis do WordPress, clientes de desktop como o Windows Live Writer e serviços de terceiros dependiam todas dele.

Com o lançamento da API REST do WordPress na versão 4.7 (2016), a necessidade do XML-RPC desapareceu em grande parte. A API REST moderna cobre tudo o que o XML-RPC fazia e fá-lo de forma mais segura, mais rápida e com autenticação adequada via nonce ou OAuth.

Mas o ficheiro xmlrpc.php continua a residir na raiz de cada instalação WordPress. A publicação remota através dele está desativada por predefinição, mas o endpoint aceita pedidos. Basta abrir yoursite.com/xmlrpc.php num navegador para ver: «XML-RPC server accepts POST requests only». Isto significa que o endpoint está ativo e pronto para ser atacado.

Porque é que o xmlrpc.php é perigoso: principais vetores de ataque

Os atacantes usam o xmlrpc.php para dois tipos principais de ataques, e ambos podem deitar o seu site abaixo.

Força bruta via system.multicall. O método system.multicall permite empacotar centenas de tentativas de autenticação num ÚNICO pedido HTTP. Em vez de testar palavras-passe uma a uma (como através do wp-login.php), um bot envia um array de logins e palavras-passe de uma só vez. Os plugins padrão de limitação de login não detetam tais pedidos; para eles, parece «uma tentativa». Resultado: os atacantes percorrem milhares de combinações em segundos sem acionar bloqueios.

DDoS de Pingback. A função de pingback permite que outro site notifique o seu WordPress sobre um link para ele. Um atacante envia um pedido de pingback forjado, substituindo o endereço IP da vítima como a «origem». O seu servidor vai obedientemente verificar o link e ataca um host de destino insuspeito. Amplie isto por milhares de instalações WordPress comprometidas e obtém um ataque DDoS distribuído onde o seu site serve de bucha de canhão.

Os fornecedores de alojamento monitorizam o tráfego de saída deste tipo e podem congelar a sua conta por «participação em DDoS». Entretanto, o seu servidor desperdiça CPU, memória e largura de banda a servir pedidos de lixo.

Verifique: o seu xmlrpc.php responde

Antes de bloquear, certifique-se de que o endpoint está realmente aberto. Abra isto no seu navegador:

1
https://yoursite.com/xmlrpc.php

Se vir a string «XML-RPC server accepts POST requests only», o endpoint está ativo e os atacantes podem enviar-lhe pedidos. Se obtiver 403 Forbidden ou 404, a proteção já está a funcionar.

Segundo método: envie um pedido POST de teste via terminal:

1
curl -X POST https://yoursite.com/xmlrpc.php -d '<methodCall><methodName>demo.sayHello</methodName></methodCall>'

Uma resposta com 200 OK e uma estrutura XML confirma: o XML-RPC aceita pedidos e está pronto para ser explorado.

Método 1: bloqueio rápido via.htaccess

O método mais simples e eficaz é bloquear o acesso ao ficheiro ao nível do servidor web. O pedido é rejeitado antes de chegar ao WordPress, o que poupa recursos do servidor e funciona mesmo que o site esteja sob carga.

Adicione isto ao seu .htaccess raiz (o que está ao lado do wp-config.php):

1
Block xmlrpc.php — protection from brute force and DDoS
2
<Files "xmlrpc.php">
3
    Require all denied
4
</Files>

A diretiva Require all denied é sintaxe do Apache 2.4+, atual para todos os fornecedores de alojamento modernos. Após guardar, abra o xmlrpc.php no seu navegador; deverá obter 403 Forbidden.

Se o seu servidor correr nginx, adicione a regra à configuração do virtual host:

1
location = /xmlrpc.php {
2
    deny all;
3
    return 403;
4
}

Após alterar a configuração do nginx, lembre-se de recarregar o servidor: sudo nginx -s reload.

Este método funciona se DEFINITIVAMENTE não precisa de XML-RPC, nem para o Jetpack, nem para as aplicações móveis do WordPress, nem para integrações com o WooCommerce.

Método 2: desativação via functions.php (método programático)

Se prefere resolver o problema ao nível do código em vez de configurações do servidor, aqui estão dois snippets testados para o functions.php do seu tema ativo ou Code Snippets.

Desativação completa do XML-RPC (WP 3.5+):

1
// Disable XML-RPC completely
2
add_filter('xmlrpc_enabled', '__return_false');

Uma linha e o WordPress deixa de processar quaisquer pedidos XML-RPC. Ao tentar aceder ao xmlrpc.php, o cliente recebe uma resposta de erro; o ficheiro em si permanece no servidor, mas está funcionalmente morto.

Limpeza dos cabeçalhos wp_head dos links RSD e WLW:

Mesmo após desativar o XML-RPC WordPress continua a inserir duas linhas no <head> que revelam informações sobre o seu site:

1
// Remove RSD and WLW Manifest links from headers
2
function sd_remove_xmlrpc_headers() {
3
    remove_action('wp_head', 'rsd_link');
4
    remove_action('wp_head', 'wlwmanifest_link');
5
}
6
add_action('init', 'sd_remove_xmlrpc_headers');

Os hooks rsd_link e wlwmanifest_link adicionam as tags <link rel="EditURI"> e <link rel="wlwmanifest"> ao <head>; estas existem exclusivamente para clientes XML-RPC e não servem nenhum propósito prático em 2026. Remova-as.

⚠️ Importante: as edições ao functions.php do tema serão perdidas na atualização. Use um tema filho ou o plugin Code Snippets para armazenamento permanente de código personalizado.

Método 3: plugins de segurança

Se não quiser mexer em código, instale um plugin. Três opções testadas:

• Wordfence Security. A firewall WordPress mais popular. Além de bloquear o XML-RPC, fornece um scanner de malware, proteção de login e monitorização de tráfego. Em definições do Wordfence → Login Security → marque «Disable XML-RPC authentication».

• Disable XML-RPC-API. Um plugin leve que faz exatamente uma coisa: liga-se ao filtro xmlrpc_enabled e desativa o endpoint. Sem definições adicionais; ative e esqueça.

• iThemes Security (Solid Security). Um plugin abrangente com um módulo WordPress Tweaks onde o XML-RPC é desativado com uma única caixa de seleção. Também fecha outros vetores: alteração do prefixo da tabela, desativação do editor de ficheiros do admin, proteção contra força bruta.

Após ativar qualquer um destes plugins, verifique sempre se o xmlrpc.php devolve um erro, não uma saudação.

Método 4: bloqueio ao nível da firewall (Cloudflare / Sucuri)

O nível mais poderoso de proteção é uma firewall web que descarta pedidos maliciosos antes mesmo de chegarem ao seu alojamento.

Cloudflare** WAF.** Crie uma regra personalizada: campo URI Path contém xmlrpc.php → ação Block. Os pedidos são filtrados ao nível da rede Cloudflare (mais de 330 pontos de presença em todo o mundo); o seu servidor nunca os vê. O plano Free inclui 5 regras personalizadas, o que é suficiente. Bónus: a Cloudflare mostra estatísticas de pedidos bloqueados e pode ver a escala do ataque com os seus próprios olhos.

Sucuri Website Firewall. Abordagem semelhante: uma regra WAF no URI /xmlrpc.php. A Sucuri também oferece monitorização da integridade dos ficheiros e limpeza automática de malware.

Uma regra de firewall funciona bem combinada com .htaccess ou desativação programática: a firewall corta o lixo em massa, enquanto o bloqueio local serve de reserva caso o tráfego contorne a WAF de alguma forma.

O que fazer se usar o Jetpack

O Jetpack da Automattic usa XML-RPC para ligar o seu site aos servidores WordPress.com. Se desativar completamente o xmlrpc.php, o Jetpack deixa de funcionar: estatísticas, subscrições, CDN de imagens, o módulo Related Posts e a proteção contra força bruta do Jetpack param todos de uma vez.

A solução: não mate o XML-RPC totalmente, mas permita seletivamente pedidos dos servidores Jetpack:

• Deixe o xmlrpc.php acessível (NÃO bloqueie via .htaccess e NÃO use o filtro xmlrpc_enabled).

• Configure a WAF da Cloudflare assim: permita pedidos ao xmlrpc.php APENAS dos intervalos de IP da Automattic (a lista é atualizada na documentação do Jetpack), bloqueie o resto.

• No mínimo, remova os cabeçalhos RSD e WLW usando o snippet do método 2, para não expor o endpoint no <head> desnecessariamente.

• Instale o Wordfence e ative a proteção contra força bruta especificamente para o xmlrpc.php; não bloqueia pedidos legítimos do Jetpack, mas corta tentativas de adivinhação de palavras-passe.

⁉️🤔 Perguntas frequentes

Posso simplesmente apagar o ficheiro xmlrpc.php do servidor?

Pode, mas é uma má prática. Na próxima atualização do WordPress, o ficheiro será restaurado e fica vulnerável novamente. É melhor bloquear o acesso via .htaccess ou desativar a funcionalidade com um filtro no código: o efeito é o mesmo, mas as atualizações do núcleo não quebrarão a sua proteção. Se apagou o ficheiro, certifique-se de remover o rsd_link do wp_head, caso contrário os visitantes obterão um 404 ao seguir o link EditURI.

Desativar o XML-RPC vai quebrar o WooCommerce?

Não. O WooCommerce transitou totalmente para a API REST do WordPress e não depende do XML-RPC. A sua loja continuará a funcionar sem alterações. A única exceção é se usar uma solução personalizada antiga ligada ao XML-RPC, mas praticamente nenhuma dessas permanece.

E se o meu fornecedor de alojamento já bloquear o xmlrpc.php?

Se o fornecedor já desativou o XML-RPC ao nível do servidor, não precisa de fazer nada; o endpoint está inacessível. Verifique: abra o xmlrpc.php; se vir 403, a proteção está a funcionar. A única coisa que vale a pena adicionar é remover os cabeçalhos RSD e WLW via functions.php, porque o fornecedor não mexe neles.

Preciso de desativar o XML-RPC se estiver num alojamento WordPress gerido?

A maioria dos hosts geridos (Kinsta, WP Engine, SiteGround) bloqueia ou limita estritamente o xmlrpc.php ao nível da plataforma. Verifique se o endpoint está aberto via navegador. Se estiver bloqueado, não é necessária nenhuma ação adicional. Se estiver aberto, adicione a regra .htaccess: os hosts geridos não a sobrescrevem.

Como sei se o meu site está a ser atacado através do xmlrpc.php neste momento?

Três sinais: um pico acentuado na carga do servidor com tráfego inalterado, centenas de pedidos POST idênticos ao xmlrpc.php nos registos de acesso e erros de limite de memória/CPU do seu fornecedor de alojamento. Ative a monitorização (Wordfence → Live Traffic ou Cloudflare → Security Events); verá a origem e a escala do ataque em tempo real.

Vale a pena desativar o xmlrpc.php em 2026

Resposta curta: sim, se não usar o Jetpack e não publicar artigos através da aplicação móvel do WordPress.

O XML-RPC é um legado da era do WordPress 1.5. A API REST há muito que tomou o seu lugar, e o próprio xmlrpc.php tornou-se uma porta aberta para ataques de força bruta e DDoS. Fechá-la leva cinco minutos. Escolha o método para a sua situação:

• Não quer mexer em código: instale o Disable XML-RPC-API, dois cliques.
• Tem acesso aos ficheiros do servidor: adicione uma regra ao .htaccess, o nível do servidor é mais fiável.
• Prefere código limpo: aplique o filtro xmlrpc_enabled e remova os cabeçalhos com dois snippets no functions.php.
• Quer proteção máxima: configure uma regra WAF no Cloudflare e combine-a com um bloqueio local.

Após o bloqueio, verifique sempre se o xmlrpc.php devolve 403 Forbidden e monitorize os registos durante pelo menos uma semana; ficará surpreendido com a quantidade de tráfego de lixo que desaparece. Subscreva também as atualizações do WordPress: a história mostra que os protocolos antigos morrem lentamente e novas vulnerabilidades XML-RPC podem surgir mesmo depois de 2026.