Como Ativar e Desativar o xmlrpc.php no WordPress (E Por Que Isso É Importante)

O ficheiro xmlrpc.php é um componente central do WordPress que expõe um endpoint de API XML-RPC, permitindo que aplicações remotas se autentiquem e executem operações no servidor — publicar posts, gerir comentários, acionar pingbacks, entre outras. Como aceita pedidos POST não autenticados por padrão e os processa antes que a maioria das camadas de segurança seja ativada, é uma das superfícies de ataque mais frequentemente exploradas em qualquer instalação WordPress.

Se não utiliza a aplicação móvel do WordPress, o Jetpack, ou qualquer serviço de terceiros que exija explicitamente XML-RPC, desativar o xmlrpc.php é a postura de segurança predefinida correta. Se depende dessas integrações, pode reforçar o endpoint em vez de o remover completamente.

O que é o xmlrpc.php e como funciona

XML-RPC (Extensible Markup Language Remote Procedure Call) é um protocolo que codifica chamadas de função em XML e as transmite via HTTP. O WordPress inclui um servidor XML-RPC completo desde a versão 3.5, implementado no ficheiro xmlrpc.php localizado no diretório raiz do WordPress.

Quando um cliente remoto — uma aplicação móvel, um cliente de blogging para desktop, ou um script de automação — envia um pedido POST para https://yourdomain.com/xmlrpc.php, o WordPress analisa o payload XML, autentica as credenciais incorporadas no corpo do pedido e executa o método solicitado. Todo o processo ocorre numa única troca HTTP, o que é simultaneamente o seu ponto forte e a sua fraqueza fundamental do ponto de vista da segurança.

Métodos XML-RPC principais expostos pelo WordPress

• wp.newPost / wp.editPost — criar e atualizar posts remotamente
• wp.getComments / wp.deleteComment — gerir comentários
• wp.uploadFile — carregar ficheiros de media para o servidor
• pingback.ping — notificar um site remoto de que foi referenciado
• system.multicall — agrupar múltiplas chamadas de método num único pedido HTTP

O método system.multicall é particularmente perigoso. Um único pedido HTTP pode agrupar centenas de chamadas wp.getUsersBlogs, cada uma testando uma palavra-passe diferente. Isto permite que um atacante realize milhares de tentativas de autenticação gerando apenas uma entrada no registo do servidor, contornando ferramentas de limitação de taxa que contam pedidos individuais.

Riscos de segurança de deixar o xmlrpc.php ativado

Amplificação de força bruta via system.multicall

Os ataques de força bruta tradicionais enviam um par de credenciais por pedido HTTP. Com XML-RPC, um atacante encapsula 500 tentativas de login num único payload system.multicall. Uma regra padrão do fail2ban ou um contador de tentativas de login vê um pedido; o atacante obtém 500 tentativas. Este não é um risco teórico — é o exploit XML-RPC mais comum observado em ambiente real.

DDoS amplificado por Pingback

O WordPress processa automaticamente pedidos de pingback recebidos através do xmlrpc.php. Um atacante pode enviar um pedido pingback.ping manipulado para milhares de sites WordPress, instruindo cada um a enviar um pedido HTTP para um único URL alvo. A vítima recebe uma inundação volumétrica de pedidos originados de servidores WordPress legítimos, tornando o bloqueio baseado em IP ineficaz. O seu servidor torna-se simultaneamente uma vítima (esgotamento de recursos) e um amplificador de ataque involuntário.

SSRF via Pingback

O mecanismo de pingback pode ser explorado para Server-Side Request Forgery (SSRF). Um atacante envia um pedido pingback.ping onde o URL de origem aponta para um recurso de rede interna — http://192.168.1.1/admin, por exemplo. O servidor WordPress acede a esse URL a partir do interior do perímetro de rede, potencialmente expondo serviços internos que não são publicamente acessíveis.

Exposição de credenciais em trânsito

O XML-RPC transmite credenciais no corpo do pedido POST como texto simples dentro do envelope XML. Se o seu site não impõe HTTPS, as credenciais ficam expostas a qualquer observador de rede. Mesmo com TLS, as credenciais estão incorporadas em cada pedido individual — não existe token de sessão nem fluxo OAuth para limitar a janela de exposição.

Quando deve manter o xmlrpc.php ativado

Desative-o por padrão, mas mantenha-o ativado se o seu fluxo de trabalho depender genuinamente de algum dos seguintes:

• Aplicação móvel do WordPress (iOS/Android): A aplicação oficial utiliza XML-RPC para todas as operações de gestão de sites em instalações WordPress auto-hospedadas.
• Plugin Jetpack: Vários módulos do Jetpack — incluindo publicize, notificações push para dispositivos móveis e algumas funcionalidades de estatísticas — comunicam via XML-RPC com os servidores WordPress.com.
• Clientes de blogging para desktop: MarsEdit, Windows Live Writer e ferramentas similares dependem exclusivamente da API XML-RPC.
• Pipelines de publicação automatizada: IFTTT, Zapier e scripts personalizados que enviam conteúdo para o WordPress frequentemente utilizam XML-RPC quando a API REST não está configurada.
• Pingbacks/trackbacks entre sites WordPress: Se as notificações de pingback entre sites fazem parte do seu fluxo de trabalho editorial, desativar o xmlrpc.php silencia-as.

Se nenhum destes casos se aplica, não existe razão operacional para manter o endpoint aberto.

xmlrpc.php vs. API REST do WordPress

O WordPress introduziu a API REST na versão 4.7 como um substituto moderno e baseado em tokens para o XML-RPC. Compreender as diferenças ajuda a decidir se desativar o XML-RPC compromete algo crítico.

Se está a criar uma nova integração ou a migrar uma existente, utilize a API REST. O modelo de autenticação é significativamente mais seguro, e o endpoint é muito mais fácil de auditar e limitar em termos de taxa ao nível da infraestrutura.

Como desativar o xmlrpc.php no WordPress

Escolha o método que corresponde ao seu nível de acesso ao servidor e tolerância ao risco. Os métodos estão ordenados do menor para o maior nível de imposição ao nível do servidor.

Método 1: Desativar via Plugin (Mais rápido, sem acesso ao servidor necessário)

Para ambientes de alojamento partilhado ou sites onde prefere não editar ficheiros de configuração do servidor, um plugin é a opção mais acessível.

Plugins recomendados:

• Disable XML-RPC-API — propósito único, pegada mínima, ativa instantaneamente
• All In One WP Security and Firewall — suite de segurança mais abrangente com controlos granulares de XML-RPC

Passos para o Disable XML-RPC-API:

1. Navegue até Plugins > Adicionar Novo no painel do WordPress.
2. Pesquise por “Disable XML-RPC-API” e clique em Instalar Agora, depois em Ativar.
3. Não é necessária configuração adicional — o plugin conecta-se ao xmlrpc_enabled e devolve false imediatamente após a ativação.

Passos para o All In One WP Security and Firewall:

1. Após ativar o plugin, vá a WP Security > Firewall.
2. Localize a secção XML-RPC.
3. Ative a opção para bloquear completamente os pedidos XML-RPC.
4. Guarde as definições.

Limitação: O bloqueio baseado em plugin é executado dentro do contexto de execução PHP do WordPress. O servidor ainda inicia o PHP, carrega o WordPress e processa o pedido antes de o rejeitar. Sob um ataque intenso, isto consome CPU e memória. Para sites com muito tráfego sob ataque ativo, utilize o método .htaccess ou Nginx.

Método 2: Desativar via .htaccess (Apache — Bloqueio ao nível do servidor)

Bloquear ao nível do .htaccess impede que o PHP seja executado para pedidos direcionados ao xmlrpc.php. Isto é significativamente mais eficiente sob carga.

1. Ligue-se ao seu servidor via FTP, SFTP ou o gestor de ficheiros do seu alojamento e abra o ficheiro .htaccess no diretório raiz do WordPress (normalmente public_html/.htaccess).
2. Adicione o seguinte bloco. Coloque-o antes das regras de reescrita padrão do WordPress:

# Block all access to xmlrpc.php
<Files "xmlrpc.php">
    Order Deny,Allow
    Deny from all
</Files>

1. Guarde o ficheiro.

Para verificar se o bloqueio está ativo, execute um teste a partir da sua máquina local:

curl -s -o /dev/null -w "%{http_code}" -X POST https://yourdomain.com/xmlrpc.php

Deverá receber uma resposta 403. Uma resposta 200 ou 405 significa que o bloqueio ainda não está em vigor.

Caso especial — se ainda precisar de pingbacks de IPs específicos de confiança, pode adicioná-los à lista de permissões:

<Files "xmlrpc.php">
    Order Deny,Allow
    Deny from all
    Allow from 192.0.2.10
</Files>

Método 3: Desativar via configuração Nginx

Se o seu servidor utiliza Nginx (comum em ambientes de Alojamento VPS), os ficheiros .htaccess não têm efeito. Adicione o bloco diretamente à configuração do bloco de servidor do seu site.

# Block xmlrpc.php at the Nginx level
location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
    return 444;
}

A diretiva return 444 fecha a ligação TCP sem enviar uma resposta HTTP, o que é mais eficiente do que um 403 porque impede que o cliente do atacante receba qualquer feedback. Após editar, recarregue o Nginx:

sudo nginx -t && sudo systemctl reload nginx

Coloque este bloco location dentro do seu bloco server {}, antes de quaisquer diretivas try_files ou de processamento PHP.

Método 4: Desativar via functions.php (Filtro de hook do WordPress)

Este método utiliza um filtro do WordPress para desativar o XML-RPC ao nível da aplicação. É menos eficiente do que o bloqueio ao nível do servidor, mas útil quando não tem acesso direto ao servidor e pretende uma solução baseada em código sem dependência de plugin.

1. Vá a Aparência > Editor de Temas no painel do WordPress, ou aceda ao ficheiro diretamente via SFTP em wp-content/themes/your-theme/functions.php.
2. Adicione o seguinte ao final do ficheiro:

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

1. Guarde o ficheiro.

Aviso importante: Este filtro desativa os métodos XML-RPC autenticados, mas não bloqueia o método pingback.ping nem impede que o ficheiro seja acedido. O servidor ainda processa o pedido até ao ponto em que o WordPress avalia o filtro. Para proteção completa, combine isto com o bloqueio .htaccess ou Nginx.

Se estiver a utilizar um tema filho, adicione sempre o código personalizado ao functions.php do tema filho, não ao tema pai. As atualizações do tema pai irão sobrescrever as suas alterações.

Método 5: Desativação seletiva — Bloquear apenas Pingbacks

Se necessita de XML-RPC para o Jetpack ou publicação móvel, mas pretende eliminar o vetor de amplificação DDoS, pode desativar apenas o método de pingback mantendo o restante da API funcional.

// Disable only the pingback method, keep XML-RPC otherwise functional
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    unset( $methods['pingback.extensions.getPingbacks'] );
    return $methods;
} );

Adicione isto ao functions.php do seu tema filho ou a um plugin específico do site. Esta é a configuração recomendada para sites que utilizam o Jetpack mas não precisam de receber pingbacks.

Como reativar o xmlrpc.php

Reverter qualquer um dos métodos acima restaura o acesso ao XML-RPC:

• Método de plugin: Desative ou elimine o plugin de bloqueio em Plugins > Plugins Instalados.
• Método .htaccess: Remova o bloco <Files "xmlrpc.php"> do .htaccess e guarde.
• Método Nginx: Remova o bloco location = /xmlrpc.php da configuração do servidor e recarregue o Nginx com sudo systemctl reload nginx.
• Método functions.php: Remova a linha add_filter( 'xmlrpc_enabled', '__return_false' ) e guarde.

Após reativar, verifique se o endpoint responde corretamente:

curl -s -X POST https://yourdomain.com/xmlrpc.php 
  -H "Content-Type: text/xml" 
  --data '<?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>'

Uma resposta XML válida com a lista de métodos disponíveis confirma que o endpoint está ativo.

Reforçar o xmlrpc.php sem o desativar

Se desativar não é uma opção, aplique estas medidas de mitigação para reduzir a superfície de ataque:

Impor HTTPS: Certifique-se de que o seu site utiliza um certificado TLS válido. Se ainda não o fez, configure um através do seu fornecedor de alojamento — os Certificados SSL impedem a interceção de credenciais em trânsito.

Limitar a taxa ao nível da firewall ou CDN: Configure o seu WAF (Cloudflare, ModSecurity) para limitar os pedidos POST ao xmlrpc.php a um máximo de 5–10 por minuto por IP.

Bloquear system.multicall especificamente:

add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['system.multicall'] );
    return $methods;
} );

Isto elimina o vetor de amplificação de força bruta preservando toda a restante funcionalidade XML-RPC.

Restringir por IP: Se acede ao XML-RPC apenas a partir de endereços IP conhecidos (o intervalo de IP da operadora da sua aplicação móvel, ou um IP de escritório estático), adicione esses endereços à lista de permissões no .htaccess ou Nginx e negue todos os outros.

Monitorizar registos de acesso: Audite regularmente os registos do servidor em busca de pedidos POST repetidos para xmlrpc.php. Um aumento de pedidos POST com estado 200 para este ficheiro é um indicador fiável de uma campanha de força bruta em curso.

Num VPS com cPanel ou outro ambiente de painel gerido, pode configurar regras ModSecurity diretamente a partir do painel de controlo para impor estas restrições sem edição manual de ficheiros.

Escolher o método certo: Matriz de decisão

Para sites em produção alojados em Servidores Dedicados, o bloqueio ao nível do servidor Nginx ou Apache é sempre preferível a uma solução baseada em plugin, pois impede completamente a execução PHP para pedidos maliciosos, eliminando a sobrecarga de CPU que o bloqueio baseado em plugin incorre sob ataque sustentado.

Lista de verificação prática com pontos-chave

• Verifique se algum plugin ou serviço ativo na sua stack realmente requer XML-RPC antes de o desativar — verifique o Jetpack, aplicações móveis e quaisquer ferramentas de automação de publicação.
• Se não existir dependência, aplique o bloqueio ao nível do servidor (.htaccess ou Nginx) em vez de um plugin — é mais eficiente e sobrevive à desativação de plugins.
• Se tiver de manter o XML-RPC ativo, remova incondicionalmente system.multicall e pingback.ping via filtro xmlrpc_methods — estes dois métodos são responsáveis pela grande maioria dos abusos XML-RPC.
• Imponha sempre HTTPS em qualquer site WordPress que aceite pedidos autenticados, incluindo XML-RPC.
• Após aplicar qualquer bloqueio, verifique com curl que o endpoint devolve 403 ou encerra a ligação — não assuma que a configuração está correta sem testar.
• Em ambientes VPS ou servidor dedicado baseados em Nginx, utilize return 444 em vez de deny all para evitar fornecer qualquer feedback ao nível HTTP aos atacantes.
• Registe e monitorize os pedidos POST para xmlrpc.php — um aumento repentino é um aviso precoce de uma campanha de credential-stuffing ou amplificação DDoS.
• Se gere múltiplos sites WordPress, considere centralizar esta configuração ao nível do servidor ou CDN em vez de aplicar regras de plugin por site.

Para sites que necessitam de gestão remota robusta sem a superfície de risco do XML-RPC, migrar integrações para a API REST do WordPress com palavras-passe de aplicação é o caminho correto a longo prazo. A API REST fornece revogação por token, permissões com âmbito definido e semântica HTTP padrão que são muito mais fáceis de proteger e auditar.

Se está a configurar um novo ambiente WordPress e pretende uma base limpa e segura desde o início, os Painéis de Controlo VPS com ModSecurity pré-configurado oferecem proteção WAF ao nível do servidor sem necessidade de criação manual de regras.

—

Perguntas Frequentes

Desativar o xmlrpc.php quebra a API REST do WordPress?

Não. A API REST (/wp-json/) é um endpoint completamente separado com a sua própria autenticação e encaminhamento. Bloquear o xmlrpc.php não tem qualquer efeito na funcionalidade da API REST. Os dois sistemas são arquiteturalmente independentes.

Desativar o xmlrpc.php quebra o Jetpack?

Depende dos módulos do Jetpack que utiliza. O Jetpack tem migrado progressivamente funcionalidades para a API REST, mas alguns módulos mais antigos — incluindo certas funcionalidades de publicize e notificações — ainda comunicam via XML-RPC. Verifique a página de depuração do Jetpack em Jetpack > Dashboard > Debug para ver se a conectividade XML-RPC está listada como requisito antes de o desativar.

O método .htaccess ou o método functions.php é mais seguro?

O método .htaccess é significativamente mais seguro em condições de ataque. Bloqueia o pedido ao nível do servidor web antes de o PHP carregar, consumindo recursos mínimos. O filtro functions.php é executado dentro do contexto de execução PHP do WordPress, o que significa que o servidor ainda inicializa o WordPress para cada pedido bloqueado — o que é dispendioso sob um ataque de alto volume.

Um atacante ainda pode explorar o xmlrpc.php se eu o desativar apenas via filtro do WordPress?

Parcialmente. O filtro xmlrpc_enabled impede chamadas de métodos autenticados, mas o ficheiro permanece publicamente acessível e o servidor ainda processa os pedidos recebidos. O endpoint de pingback pode permanecer parcialmente funcional dependendo da versão do WordPress. Para proteção completa, combine o filtro com um bloqueio ao nível do servidor.

Como verifico se o xmlrpc.php está atualmente acessível no meu site?

Execute o seguinte comando a partir do seu terminal local, substituindo o domínio pelo seu:

curl -s -o /dev/null -w "%{http_code}" -X POST https://yourdomain.com/xmlrpc.php

Uma resposta 200 significa que o endpoint está aberto. Uma resposta 403 ou uma queda de ligação (000) confirma que está bloqueado. Também pode utilizar a ferramenta online em xmlrpc.eritreo.it para testar especificamente a vulnerabilidade de pingback.