O que é xmlrpc.php no WordPress e Como Desativá-lo (Guia Completo 2024)

WordPress alimenta mais de 43% de todos os sites na internet — e com essa dominância vem uma superfície de ataque significativa. Um dos pontos de entrada mais frequentemente explorados é um arquivo chamado xmlrpc.php. Quer você seja um desenvolvedor experiente ou um proprietário de site gerenciando sua primeira instalação WordPress, entender o que este arquivo faz, por que é perigoso e como desativá-lo é crítico para manter seu site seguro.

Este guia cobre tudo o que você precisa saber sobre xmlrpc.php: seu propósito, as ameaças do mundo real que introduz e três métodos comprovados para desativá-lo — nenhum grau técnico necessário.

O que é xmlrpc.php no WordPress?

xmlrpc.php é um arquivo principal do WordPress que implementa o protocolo XML-RPC — um sistema de chamada de procedimento remoto (RPC) que usa XML para codificar chamadas e HTTP como mecanismo de transporte. Em linguagem simples, permite que aplicativos e serviços externos se comuniquem com seu site WordPress sem usar a interface padrão do navegador da web.

Introduzido muito antes da REST API do WordPress existir, xmlrpc.php era a ponte principal entre WordPress e o mundo exterior. Permitia:

• Publicação remota de conteúdo — Clientes de blog como Windows Live Writer ou MarsEdit podiam postar artigos diretamente em seu site.
• Gerenciamento de aplicativos móveis — O aplicativo móvel oficial do WordPress historicamente dependia de XML-RPC para gerenciar posts, páginas e comentários.
• Trackbacks e pingbacks — O protocolo lida com notificações entre sites, alertando outros blogs quando você vincula ao seu conteúdo.
• Integrações de terceiros — Serviços como IFTTT, Zapier (em configurações antigas) e vários plugins usavam XML-RPC para interagir com WordPress programaticamente.

Embora esses recursos fossem genuinamente úteis no início dos anos 2010, WordPress introduziu desde então a REST API, que fornece uma forma mais segura, moderna e flexível de alcançar os mesmos resultados. Como resultado, xmlrpc.php agora é amplamente obsoleto — mas permanece ativo por padrão em toda instalação WordPress.

Por que xmlrpc.php é um risco de segurança?

O problema com xmlrpc.php não é o protocolo em si — é que o arquivo permanece ativado mesmo quando você não o usa, criando um vetor de ataque desnecessário. Pesquisadores de segurança e provedores de hospedagem consistentemente o sinalizam como uma das principais vulnerabilidades do WordPress. Aqui está o porquê:

1. Ataques de Amplificação de Força Bruta

Esta é a ameaça mais perigosa e amplamente explorada. Ataques de força bruta padrão contra a página de login do WordPress (wp-login.php) são limitados a uma tentativa de credencial por solicitação HTTP. XML-RPC muda isso dramaticamente.

O método system.multicall em XML-RPC permite que um atacante agrupe centenas ou até milhares de combinações de nome de usuário/senha em uma única solicitação HTTP. Isso significa:

• Limitação de taxa tradicional e plugins de tentativa de login são contornados.
• Atacantes podem testar listas de credenciais enormes com largura de banda mínima.
• Logs do servidor mostram muito menos solicitações, tornando a detecção mais difícil.

Um único botnet pode comprometer um site WordPress com uma senha fraca em minutos usando esta técnica.

2. Amplificação DDoS via Pingbacks

Atacantes podem explorar a funcionalidade de pingback em xmlrpc.php para transformar seu site WordPress em um participante involuntário de um ataque de Negação de Serviço Distribuído (DDoS). Ao enviar uma solicitação de pingback especialmente elaborada, um ator malicioso pode instruir seu servidor a enviar solicitações HTTP para uma URL de destino — efetivamente usando os recursos do seu servidor e reputação de IP contra um terceiro.

Isso não apenas prejudica o alvo do ataque, mas também pode fazer com que o IP do seu servidor seja colocado na lista negra, afetando a entregabilidade e reputação do seu site.

3. Esgotamento de Recursos do Servidor

Mesmo sem um ataque coordenado, xmlrpc.php é um alvo comum para bots de varredura automatizados que investigam vulnerabilidades. Essas sondagens constantes consomem ciclos de CPU, memória e largura de banda — recursos que deveriam servir seus visitantes legítimos. Em ambientes de hospedagem compartilhada especialmente, isso pode degradar notavelmente o desempenho do site.

4. Exposição Desnecessária

Se você não está usando ferramentas de publicação remota, aplicativos móveis que exigem XML-RPC ou integrações de terceiros herdadas, então xmlrpc.php fornece zero benefício para seu site enquanto mantém uma superfície de ataque totalmente ativa. O princípio do menor privilégio em segurança dita: se você não precisa, desative.

Você realmente precisa de xmlrpc.php?

Antes de desativá-lo, pergunte-se:

Para a grande maioria dos proprietários de sites WordPress, a resposta é: você não precisa. Desative.

Como Desativar xmlrpc.php no WordPress: 3 Métodos

Existem três métodos confiáveis para desativar xmlrpc.php, variando de iniciante a nível de servidor. Escolha o que melhor se adequa ao seu nível de conforto técnico e ambiente de hospedagem.

Método 1: Use um Plugin de Segurança WordPress (Mais Fácil)

Se você quer uma solução sem código com risco mínimo de quebrar algo, um plugin de segurança é seu melhor ponto de partida.

Plugins recomendados:

• Wordfence Security — Firewall abrangente e scanner de malware com bloqueio de XML-RPC.
• iThemes Security (agora Solid Security) — Alternância dedicada para desativar XML-RPC.
• Disable XML-RPC — Um plugin leve e de propósito único que faz exatamente o que diz.

Passo a passo:

1. Faça login no seu painel de administração WordPress.
2. Navegue até Plugins → Adicionar Novo.
3. Procure seu plugin escolhido (por exemplo, “Disable XML-RPC”) e clique em Instalar Agora, depois Ativar.
4. Vá para a página de configurações do plugin. Para plugins de segurança dedicados como Wordfence ou iThemes Security, procure uma seção rotulada XML-RPC ou WordPress Tweaks.
5. Ative a opção para desativar XML-RPC ou bloquear solicitações XML-RPC.
6. Salve suas alterações.

Prós: Simples, reversível, nenhuma edição de arquivo necessária.

Contras: Adiciona uma dependência de plugin; o arquivo ainda existe no servidor (solicitações são bloqueadas no nível da aplicação, não no nível do servidor).

Método 2: Bloqueie xmlrpc.php via .htaccess (Recomendado para Servidores Apache)

Para ambientes de hospedagem baseados em Apache, editar o arquivo .htaccess bloqueia solicitações no nível do servidor web — antes mesmo do WordPress carregar. Isso é mais eficiente e fornece proteção mais forte do que um plugin sozinho.

Passo a passo:

1. Acesse os arquivos do seu site via FTP (usando FileZilla ou similar) ou através do Gerenciador de Arquivos do painel de controle de hospedagem.
2. Navegue até o diretório raiz do WordPress — isso é tipicamente public_html ou www.
3. Localize o arquivo .htaccess. Se você não conseguir vê-lo, ative arquivos ocultos no seu cliente FTP (no FileZilla: Server → Force Showing Hidden Files) ou nas configurações do seu gerenciador de arquivos.
4. Abra .htaccess para edição e adicione o seguinte bloco no final do arquivo:

# Block WordPress xmlrpc.php
<Files xmlrpc.php>
    Order Deny,Allow
    Deny from all
</Files>

1. Salve o arquivo e feche seu editor.

Para verificar se está funcionando, visite https://yourdomain.com/xmlrpc.php em seu navegador. Você deve receber um erro 403 Forbidden em vez da resposta padrão de XML-RPC.

Prós: Bloqueio no nível do servidor é mais eficiente; reduz carga do servidor; nenhum plugin necessário.

Contras: Requer acesso a arquivos; edições incorretas de .htaccess podem quebrar temporariamente seu site (sempre mantenha um backup).

> Dica profissional: Se sua hospedagem usa Nginx em vez de Apache, adicione o seguinte à configuração do bloco de servidor Nginx:

>

> “`nginx

> location = /xmlrpc.php {

> deny all;

> access_log off;

> log_not_found off;

> }

> “`

Método 3: Desative via functions.php (WordPress Filter Hook)

Este método usa um filtro WordPress para desativar programaticamente a funcionalidade XML-RPC dentro do tema ou de um plugin personalizado. É uma solução limpa baseada em código que funciona na camada de aplicação WordPress.

Passo a passo:

Opção A — Via Editor de Tema (rápido mas não recomendado para produção):

1. No seu painel WordPress, vá para Aparência → Editor de Tema.
2. Selecione functions.php da lista de arquivos no lado direito.
3. Adicione o seguinte código no final do arquivo:

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

1. Clique em Atualizar Arquivo para salvar.

Opção B — Via um Plugin Personalizado (recomendado):

Em vez de editar o functions.php do seu tema (que é sobrescrito em atualizações de tema), crie um plugin personalizado simples:

1. Usando FTP ou Gerenciador de Arquivos, navegue até wp-content/plugins/.
2. Crie uma nova pasta chamada disable-xmlrpc.
3. Dentro dessa pasta, crie um arquivo chamado disable-xmlrpc.php com o seguinte conteúdo:

<?php
/**
 * Plugin Name: Disable XML-RPC
 * Description: Disables XML-RPC functionality for improved security.
 * Version: 1.0
 * Author: Your Name
 */

add_filter( 'xmlrpc_enabled', '__return_false' );

1. Vá para Plugins → Plugins Instalados no seu painel e ative Disable XML-RPC.

Prós: Limpo, independente de tema (ao usar método de plugin personalizado); fácil de reverter.

Contras: Apenas nível de aplicação — o arquivo ainda existe e pode receber solicitações (embora sejam rejeitadas); não reduz carga do servidor tão efetivamente quanto bloqueio .htaccess.

Combinando Métodos para Segurança Máxima

Para a proteção mais forte, combine Método 2 (.htaccess) com Método 3 (filter hook):

• A regra .htaccess bloqueia solicitações no nível do servidor, reduzindo carga.
• O filter hook garante que XML-RPC seja desativado mesmo se a regra .htaccess for alguma vez contornada ou sobrescrita.

Esta abordagem em camadas segue o princípio de segurança de defesa em profundidade — múltiplos controles independentes protegendo o mesmo ativo.

Como Verificar se xmlrpc.php Foi Desativado com Sucesso

Após aplicar seu método escolhido, confirme se está funcionando:

1. Teste do navegador: Visite https://yourdomain.com/xmlrpc.php. Um bloqueio bem-sucedido mostra um erro 403 Forbidden ou 404 Not Found.
2. Verificador XML-RPC online: Use uma ferramenta como xmlrpc.eritreo.it para testar se o endpoint XML-RPC do seu site responde.
3. Logs do servidor: Verifique seus logs de acesso para quaisquer solicitações restantes para xmlrpc.php — uma queda repentina confirma que o bloqueio está funcionando.

Escolhendo a Hospedagem Certa para Segurança WordPress

Desativar xmlrpc.php é apenas uma camada de segurança WordPress. A base de um site WordPress seguro começa com escolher o provedor de hospedagem certo — um que ofereça controles de segurança no nível do servidor, backups regulares e infraestrutura projetada para resistir a ataques.

Na AlexHost, a segurança WordPress é integrada à pilha de hospedagem. Quer você esteja executando um blog pessoal ou um site de negócios com alto tráfego, o plano certo faz uma diferença significativa:

• Hospedagem VPS — Acesso root completo permite que você implemente configurações de segurança no nível do servidor, incluindo regras personalizadas de Nginx ou Apache para bloquear xmlrpc.php no nível da infraestrutura. Ideal para desenvolvedores e sites em crescimento que precisam de controle granular.

• Hospedagem Web Compartilhada — Um ponto de entrada econômico para sites WordPress, com configurações de segurança gerenciadas e acesso fácil à edição de .htaccess através do painel de controle.

• VPS com cPanel — Combina o poder de um servidor privado virtual com a interface cPanel familiar, tornando simples gerenciar arquivos .htaccess, certificados SSL e configurações de segurança sem experiência em linha de comando.

• Certificados SSL — Criptografar seu site com HTTPS é uma linha de base de segurança inegociável. Um certificado SSL garante que mesmo se solicitações XML-RPC forem feitas, credenciais e dados transmitidos sejam criptografados em trânsito.

• Registro de Domínio — Mantenha seu domínio e hospedagem sob o mesmo teto para gerenciamento DNS simplificado e superfície de ataque reduzida de vulnerabilidades de registrador de terceiros.

Parear infraestrutura de hospedagem forte com endurecimento no nível de aplicação como desativar xmlrpc.php oferece ao seu site WordPress uma postura de segurança robusta e em múltiplas camadas.

Perguntas Frequentes

Desativar xmlrpc.php vai quebrar meu site WordPress?

Para a maioria dos usuários, não. Se você não usa clientes de blog de desktop herdados, o aplicativo oficial WordPress (versões modernas usam REST API) ou integrações de terceiros específicas que explicitamente exigem XML-RPC, desativá-lo não terá efeito perceptível na funcionalidade.

Jetpack requer xmlrpc.php?

Versões antigas do Jetpack dependiam de XML-RPC. Versões modernas do Jetpack usam principalmente a REST API do WordPress.com. Verifique a documentação da sua versão específica do Jetpack antes de desativar XML-RPC.

Posso apenas desativar pingbacks em vez de todo o XML-RPC?

Sim. Se você quer manter XML-RPC ativo para outros fins mas eliminar abuso de pingback, adicione isto ao seu functions.php:

// Disable pingbacks only
add_filter( 'xmlrpc_methods', function( $methods ) {
    unset( $methods['pingback.ping'] );
    return $methods;
} );

xmlrpc.php é removido em versões mais recentes do WordPress?

Não. A partir das versões mais recentes do WordPress, xmlrpc.php ainda está incluído e ativado por padrão. O time principal do WordPress discutiu seu futuro, mas permanece presente para compatibilidade com versões anteriores.

Conclusão

xmlrpc.php é um arquivo WordPress herdado que uma vez serviu um propósito legítimo, mas hoje representa uma das vulnerabilidades mais comumente exploradas em instalações WordPress em todo o mundo. A menos que você tenha uma necessidade específica e documentada de funcionalidade XML-RPC, desativá-lo é uma melhoria de segurança direta e de alto impacto que leva menos de cinco minutos para implementar.

Para recapitular suas opções: