Todos os sites WordPress guardam um ficheiro «silencioso» na raiz que a maioria dos proprietários só descobre após um ataque. O seu nome é xmlrpc.php. O ficheiro em si não é malicioso: o WordPress avisa honestamente que se trata de uma interface para interação remota. Mas é através deste ficheiro que os bots têm vindo a fazer brute-force de palavras-passe, a enviar pingbacks de spam e a gerar tráfego DDoS durante anos.

De acordo com os dados da Wordfence para 2024, os ataques via XML-RPC estão entre os cinco principais vetores de ataque contra sites WordPress. Um único pedido system.multicall permite que um atacante teste centenas de palavras-passe de uma só vez, em vez de uma, como acontece através do formulário de login. Os fornecedores de alojamento registam milhões destas tentativas mensalmente num site médio.

Vamos perceber para que serve este ficheiro, quem o deve manter e, mais importante, mostrar cinco formas de desativar ou bloquear com segurança o xmlrpc.php, desde um plugin de um clique até edições direcionadas no .htaccess.

💡 Visão geral rápida:

• Saiba o que é o xmlrpc.php e que funções do WordPress dependem dele (pingback, aplicação móvel, Jetpack)
• Avalie os riscos reais: amplificação de brute-force, DDoS por pingback e análise de diretórios por bots
• Escolha o método de proteção adequado: desativação via plugin, bloqueio através do .htaccess, fecho do acesso ao nível do servidor web ou remoção do ficheiro
• Configure a monitorização: como garantir que o xmlrpc.php já não responde a pedidos

O que é o xmlrpc.php e que funções do WordPress dependem dele

XML-RPC é um protocolo de chamada de procedimento remoto que funciona sobre HTTP e transmite dados em formato XML. A tecnologia surgiu no final dos anos 1990, muito antes da REST API, e o WordPress herdou-a nos seus primeiros tempos. O ficheiro xmlrpc.php na raiz do site aceita pedidos XML, processa-os e devolve uma resposta, por exemplo, publica um artigo, carrega um ficheiro multimédia ou verifica permissões de utilizador.

Na prática, vários cenários funcionam através do xmlrpc.php:

• Pingbacks e trackbacks. Quando alguém cria uma ligação para o seu artigo, o site dessa pessoa envia um pedido XML-RPC com uma notificação. O seu WordPress verifica a ligação e, se for real, adiciona o pingback aos comentários.

• Publicação remota. Aplicações como o antigo Windows Live Writer ou clientes de desktop (TextMate, MarsEdit) usavam XML-RPC para escrever e enviar artigos sem entrar no painel de administração.

• Aplicação móvel do WordPress. A aplicação oficial para iOS e Android dependeu do XML-RPC durante muito tempo, embora esteja cada vez mais a migrar para a REST API.

• Integrações. Serviços como o Jetpack (parte da sua funcionalidade), o IFTTT e algumas ferramentas de SEO ainda usam XML-RPC para se ligarem ao site.

Com o lançamento da REST API do WordPress na versão 4.7 (dezembro de 2016), a maioria das integrações modernas migrou para o novo protocolo. A REST API é mais rápida, trabalha com JSON em vez de XML e está melhor documentada. No entanto, o WordPress ainda inclui o xmlrpc.php em cada instalação por uma questão de compatibilidade retroativa.

Nuance importante: a partir do WordPress 2.6 (em 2008), a funcionalidade de publicação remota via XML-RPC está desativada por predefinição. Para a ativar, é necessário marcar explicitamente a caixa em «Definições → Escrita». Os pingbacks e trackbacks continuam a funcionar ao mesmo tempo.

Como o xmlrpc.php é perigoso: três vetores de ataque principais

Os programadores do WordPress já corrigiram o xmlrpc.php mais do que uma vez. Na versão 2.1.2, um utilizador autenticado com direitos de «colaborador» podia publicar um artigo contornando as restrições. Na 2.3.1, descobriram uma fuga de informação através do XML-RPC. Ambas as falhas foram rapidamente fechadas, mas o protocolo em si permaneceu arquitetonicamente vulnerável a três classes de ataques que ainda são relevantes em 2026.

Amplificação de brute-force via system.multicall

O principal problema é o método system.multicall. Ele permite empacotar várias chamadas wp.getUsersBlogs num único pedido HTTP. Cada chamada verifica um par «login + palavra-passe». Assim, em vez de uma tentativa por pedido, o atacante faz centenas. A Cloudflare registou picos de dezenas de milhares destes pedidos por hora num único site.

O formulário de login normal wp-login.php está limitado a um login por tentativa e é facilmente protegido por um plugin como o Wordfence ou o Limit Login Attempts. O xmlrpc.php contorna todos estes limitadores porque funciona através de um endpoint diferente.

DDoS por pingback

A funcionalidade de pingback foi concebida como uma notificação inofensiva. Mas um atacante pode enviar pedidos de pingback falsos em nome de centenas de sites, e o seu servidor irá verificar cada «ligação», sobrecarregando o CPU, a rede e a base de dados. Com escala suficiente, o site fica em baixo. A Sucuri, no seu relatório de 2023, classifica os ataques de pingback como um dos vetores de DDoS mais comuns contra o WordPress.

Análise de diretórios por bots

Os bots procuram o xmlrpc.php não só na raiz, mas também em subdiretórios inventados como /2026/01/xmlrpc.php e /blog/xmlrpc.php. Cada pedido destes devolve um 404 e desperdiça recursos do servidor. Mesmo que o ataque falhe, dezenas de milhares de pedidos de lixo abrandam o site e entopem os registos. Na prática, os proprietários veem os gráficos no cPanel entrar na zona vermelha, e a razão é precisamente a análise do xmlrpc.php por bots.

5 Formas de desativar ou proteger o xmlrpc.php

Abaixo estão cinco métodos, do mais simples ao mais radical. Escolha com base na sua situação: se usa a aplicação móvel, se precisa de pingbacks, que alojamento tem.

1. Desativar via plugin

O caminho mais seguro para quem não quer mexer no código. Instale um plugin e ele bloqueará o acesso ao xmlrpc.php ao nível do WordPress, antes de o processamento do pedido começar.

Vantagens: não precisa de editar o .htaccess ou o functions.php, é fácil de voltar a ligar. Desvantagens: adiciona mais um plugin ao painel de administração, a proteção é removida na desativação.

Algumas opções comprovadas:

• Disable XML-RPC, minimalista, uma ação: ativado e o acesso está fechado. Sem configurações.
• Wordfence Security, firewall abrangente na qual a desativação do XML-RPC é apenas uma das funções. Adequado se já usa o Wordfence ou planeia instalá-lo.

2. Bloquear via.htaccess

Se estiver a trabalhar num servidor Apache, o ficheiro .htaccess na raiz do site permite bloquear o acesso antes de o pedido chegar ao WordPress. Isto reduz a carga: o Apache devolve 403 Forbidden imediatamente, sem executar o PHP.

Adicione o seguinte bloco ao .htaccess no início do ficheiro, antes de # BEGIN WordPress:

1
<IfModule mod_alias.c>
2
    RedirectMatch 403 /(.*)/xmlrpc.php$
3
</IfModule>

A diretiva RedirectMatch 403 interceta qualquer URL que termine em /xmlrpc.php, incluindo subdiretórios como /2025/06/xmlrpc.php, e devolve instantaneamente 403.

Vantagens: não mexe no código do WordPress, funciona antes de o PHP carregar, poupa recursos. Desvantagens: necessidade de editar o .htaccess manualmente, ao mudar de alojamento ou tema o ficheiro pode ser sobrescrito.

Importante: antes de editar o .htaccess, faça uma cópia de segurança. Um erro na sintaxe do .htaccess pode deitar o site abaixo (500 Internal Server Error).

3. Remover ligações via functions.php

Este método não bloqueia o ficheiro em si, mas remove as ligações HTML para o xmlrpc.php e o wlwmanifest.xml da secção <head> do site. O benefício é a visibilidade reduzida: os bots que analisam o HTML não veem um apontador direto para o endpoint XML-RPC.

Adicione ao functions.php do tema ativo (ou através do plugin Code Snippets):

1
remove_action('wp_head', 'rsd_link');
2
remove_action('wp_head', 'wlwmanifest_link');

O hook rsd_link produz <link rel="EditURI">, uma ligação para o xmlrpc.php para clientes Really Simple Discovery. O hook wlwmanifest_link é para o Windows Live Writer (há muito sem suporte, mas o WordPress ainda o produz).

Vantagens: <head> limpo sem ligações de lixo. Desvantagens: o xmlrpc.php permanece fisicamente acessível via URL direto, isto não é um bloqueio, mas uma ocultação.

4. Fechar o acesso via WAF ou Cloudflare

A Web Application Firewall bloqueia pedidos ao xmlrpc.php antes de chegarem ao seu servidor. Esta é a abordagem mais eficaz para sites em qualquer alojamento.

Opções de configuração:

• Cloudflare (plano gratuito): Regra WAF → Bloquear → Campo URI Path contém /xmlrpc.php. O pedido é rejeitado ao nível da rede da Cloudflare, o seu servidor nem sequer o vê.
• Wordfence WAF: Função integrada «Disable XML-RPC» na secção da firewall.
• WAF do alojamento: Kinsta, WP Engine e outros alojamentos geridos permitem desativar o XML-RPC em alguns cliques através do painel de controlo.

Vantagens: carga zero no servidor, pode ser ajustado com precisão (por exemplo, permitir o Jetpack enquanto bloqueia todo o resto). Desvantagens: requer configuração do lado da WAF, nem todos os fornecedores de alojamento disponibilizam esta capacidade.

5. Remover ou renomear o próprio ficheiro

O método mais radical. Apaga (ou renomeia) o ficheiro xmlrpc.php do servidor. Se o ficheiro não existir fisicamente, não há nada para processar os pedidos, o servidor devolve 404.

Nuance importante: na próxima atualização do WordPress, o ficheiro será restaurado. As atualizações automáticas do núcleo sobrescrevem todos os ficheiros do WordPress, incluindo o xmlrpc.php. Portanto, a eliminação é uma medida temporária, a menos que configure uma limpeza regular.

Se seguir este caminho, complemente a eliminação com a regra .htaccess do método 2. Sem ela, os bots continuarão a bater à porta do URL xmlrpc.php, e o servidor devolverá honestamente 404 a cada pedido, milhares de erros nos registos.

Vale a pena desativar o xmlrpc.php?

A resposta depende do que utiliza. Percorra a lista de verificação:

Se não usa uma versão antiga da aplicação móvel, não ativou a gestão do Jetpack com o WordPress.com e os pingbacks não são críticos para si, desative sem hesitar. Em 2026, a REST API cobre quase todos os cenários reais.

Vídeo: como desativar o XML-RPC no WordPress em 5 minutos

Veja um guia visual para desativar o xmlrpc.php, com demonstração em ecrã e explicação de cada método:

⁉️🤔 Perguntas frequentes

É seguro simplesmente ignorar o xmlrpc.php?

Na maioria dos casos, não. Mesmo que não use XML-RPC, os bots analisam este endpoint constantemente. Cada pedido desses sobrecarrega o servidor. É melhor fechar explicitamente o acesso via .htaccess ou plugin, isto elimina tanto o risco de brute-force como os pedidos de lixo nos registos.

O site avaria se o xmlrpc.php for desativado?

O WordPress em si continuará a funcionar sem alterações. Verifique apenas se está a usar a gestão do Jetpack com o WordPress.com ou uma versão antiga da aplicação móvel. Se não, desative sem preocupações. Os pingbacks deixarão de chegar, mas a maioria dos sites já não os usa para comunicação real.

Como verificar se o xmlrpc.php está realmente bloqueado?

Abra no seu navegador https://your-site.com/xmlrpc.php. Se vir um ecrã branco com a mensagem «XML-RPC server accepts POST requests only», o ficheiro está ativo e a responder. Se obtiver 403 Forbidden ou 404 Not Found, o bloqueio está a funcionar. Para monitorização automática, pode usar verificadores online como xmlrpc.eror.xyz ou um pedido curl a partir da consola.

O que é melhor: plugin ou.htaccess?

O .htaccess bloqueia o pedido antes de o WordPress arrancar, o que poupa recursos do servidor. Um plugin é mais fácil de instalar e não requer a edição de ficheiros. Para sites não críticos, quase não há diferença. Para projetos de alta carga, o .htaccess ou uma regra WAF é preferível.

Preciso de atualizar o WordPress depois de desativar o xmlrpc.php?

Não. A desativação do xmlrpc.php não depende da versão do WordPress e não afeta as atualizações do núcleo. A única nuance: se apagou o ficheiro fisicamente, a atualização irá restaurá-lo, exigindo uma nova eliminação.

Então, o que deve fazer com o xmlrpc.php no seu site?

Não há uma resposta universal, o contexto decide tudo. Mas a prática de milhares de sites WordPress dá uma imagem clara: se não sabe se precisa de XML-RPC, não precisa.

Quer fiabilidade sem mergulhar no código, instale o Disable XML-RPC. Está disposto a gastar cinco minutos no .htaccess, obtenha proteção ao nível do servidor sem plugins extra. Se usa a Cloudflare, configure uma regra WAF e esqueça o problema.

O principal é não deixar o xmlrpc.php aberto «por defeito». Em 2026, cada endpoint WordPress não fechado é um alvo para bots automatizados que não querem saber se tem um blogue ou uma loja online. Feche o acesso usando um dos métodos acima, verifique o resultado com um pedido curl e durma descansado.