# Xml-rpc no WordPress: Como desativar em 4 camadas Desativar o XML-RPC fecha o `xmlrpc.php`, vetor de força bruta e DDoS por pingback, sem quebrar o site. Segundo o Cloudflare Radar (2026), ataques DDoS responderam por 82,4% da camada de aplicação mitigada no Brasil. O risco real está no método system.multicall. Bloqueie por plugin, .htaccess, filtro PHP ou firewall de borda. O XML-RPC é a interface antiga do WordPress que permite a aplicações externas publicar e gerenciar conteúdo via requisições remotas. Hoje ele é legado: a REST API moderna cobre quase tudo que esse protocolo fazia, e o arquivo `xmlrpc.php` virou um dos alvos preferidos de ataque automatizado. Manter esse endpoint aberto, sem necessidade, é deixar uma porta de entrada para força bruta e amplificação de DDoS. Este guia mostra como desativar o XML-RPC em quatro camadas independentes, do clique no plugin ao bloqueio na borda, e explica o que quebra e o que continua intacto. Para o contexto maior, veja o hub de guias de segurança WordPress da FULL. --- ## Diagnóstico rápido: Por que o protocolo virou alvo O XML-RPC concentra dois riscos concretos que aparecem com frequência nos tickets de suporte da FULL: força bruta amplificada e DDoS refletido por pingback. Em 2026, o `xmlrpc.php` ainda recebe milhares de tentativas automatizadas por dia em sites WordPress expostos, o que torna o bloqueio uma decisão prática de redução de risco. O problema não é o protocolo em si, é o fato de ele aceitar centenas de tentativas de login em uma única requisição HTTP, o que fura a maioria dos limitadores por IP. A causa raiz tem nome: o método `system.multicall`. Ele empacota várias chamadas numa só, então um atacante envia uma lista de senhas e o servidor testa todas de uma vez, sem disparar o contador de tentativas. O segundo vetor é o `pingback.ping`, que transforma o seu site em amplificador: milhares de instalações WordPress são usadas para refletir tráfego contra um alvo terceiro. Quem cataloga esse tipo de falha aqui fala com autoridade técnica, já que a FULL é a única empresa brasileira CNA (CVE Numbering Authority) sob a CISA desde maio de 2022, autorizada a atribuir IDs CVE oficiais.

XML-RPC: vetores de ataque, mecanismo e camada de defesa
Vetor	Mecanismo	Camada que bloqueia
Força bruta amplificada	system.multicall testa centenas de senhas por requisição	Plugin, .htaccess ou filtro PHP
DDoS por pingback	pingback.ping usa seu site como refletor	Firewall de borda (Cloudflare) ou .htaccess
Enumeração de usuários	respostas do protocolo vazam nomes de login	Plugin de segurança ou filtro PHP

--- ## O que quebra (e o que não quebra) ao desativar o xml-rpc Desativar o XML-RPC não afeta o WordPress moderno, porque o núcleo migrou para a REST API anos atrás. Na grande maioria dos sites que passam pelo suporte da FULL, o `xmlrpc.php` pode ser fechado sem nenhum efeito visível no editor ou nos plugins. O editor, o Gutenberg, o app móvel oficial e a maioria dos plugins usam a REST API do WordPress, não o protocolo antigo. A regra causal aqui é direta: REST API moderna ativa mais `xmlrpc.php` desativado é igual a apps e Jetpack atuais funcionando normalmente. O que pode quebrar é pontual e quase sempre legado. O Jetpack em versões muito antigas usava esse protocolo para conectar ao WordPress.com, mas as versões atuais já operam pela REST. Clientes de blog desktop antigos, como o Windows Live Writer, dependem dele, embora praticamente ninguém use mais. E o pingback, que avisa quando outro site cita o seu, para de funcionar, o que tende a ser um alívio, já que ele costuma gerar mais spam do que valor. Se você não usa nenhum desses, desativar é ganho líquido de segurança. --- ## Passo a passo: Como desativar o xml-rpc em 4 camadas Existem quatro camadas independentes para desativar o XML-RPC, da mais simples à mais solida, e você escolhe conforme o seu ambiente. A camada 1 resolve para a maioria em menos de um minuto; as camadas 3 e 4 agem antes do PHP carregar, o que importa em sites sob ataque ativo. Você pode combinar mais de uma. As instruções abaixo seguem a hierarquia de quem opera servidor em escala.

Legenda: o bloqueio por plugin é a camada mais acessível para fechar o endpoint sem editar arquivos.

### Passo 1: Ative o bloqueio por plugin de segurança A forma mais rápida de fechar o endpoint é por um plugin de segurança com a opção pronta. No All in One Security (AIOS), vá em WP Security, Firewall e ative "Completely Block Access to XML-RPC". O plugin escreve a regra de bloqueio e você não toca em arquivo nenhum. O Wordfence oferece controle equivalente via firewall. Essa camada é ideal para quem não tem acesso confortável ao servidor e resolve força bruta e enumeração de usuários de imediato. ### Passo 2: Bloqueie o xmlrpc.php pelo .htaccess Em servidores Apache, bloquear o arquivo direto no `.htaccess` age antes do WordPress carregar. Adicione no topo do arquivo, na raiz do site: ```apache Require all denied ``` Esse bloqueio nega qualquer requisição ao `xmlrpc.php` na fase do servidor web, sem gastar PHP. É a camada que mais alivia o servidor sob ataque de `system.multicall`, porque o pico não chega a iniciar o WordPress. Em Nginx, a regra equivalente vai no bloco do site (`location = /xmlrpc.php { deny all; }`). ### Passo 3: Desative por filtro no PHP Se preferir manter no código, um filtro no `functions.php` do tema filho ou em um plugin de site desliga a interface pela API do próprio WordPress: ```php add_filter( 'xmlrpc_enabled', '__return_false' ); ``` Esse filtro desativa o protocolo de forma controlada e é documentado pelo núcleo. O comportamento exato está no Code Reference oficial do WordPress. A limitação honesta: o arquivo `xmlrpc.php` continua respondendo HTTP, só passa a recusar os métodos, então ele alivia menos o servidor que o bloqueio no .htaccess. ### Passo 4: Filtre no firewall de borda A camada mais solida filtra o tráfego antes de ele tocar no seu servidor. No firewall da Cloudflare, crie uma regra de WAF bloqueando o caminho `/xmlrpc.php`. Como o bloqueio acontece na borda da rede, nem força bruta nem pingback chegam a consumir recurso do seu host. Para sites que já sofreram DDoS, essa é a única camada que neutraliza o vetor de amplificação sem depender do servidor de origem. --- ## Cves reais: O que os dados de vulnerabilidade mostram A leitura honesta dos dados de CVE separa risco atual de histórico, e essa distinção muda a decisão. Plugins de segurança como o All in One Security acumulam dezenas de CVEs ao longo dos anos, segundo o perfil público do WPVulnerability, mas a quase totalidade já foi corrigida, o que sinaliza manutenção ativa, não perigo. O AIOS soma 44 CVEs históricas, com a crítica CVE-2016-10887 (CVSS 9.8), uma falha de bypass de proteção corrigida já na versão 4.0.9. Manter o plugin atualizado fecha esse histórico inteiro. O ponto de atenção do momento é a CVE-2026-8438 (CVSS 7.2), recente no AIOS e corrigida na versão 5.4.8, o que reforça a regra de ouro: o que protege você não é nunca ter tido CVE, é atualizar rápido quando ela aparece. Por isso, a recomendação técnica é tratar o XML-RPC como parte de um conjunto de hardening, e não como botão isolado. Para o passo a passo completo, veja o guia de como fazer hardening de segurança no WordPress. --- ## Como confirmar que o bloqueio está valendo Validar o bloqueio leva trinta segundos e evita falsa sensação de segurança. Acesse `https://seusite.com.br/xmlrpc.php` direto no navegador. Com a interface ativa, a resposta é "XML-RPC server accepts POST requests only" com status 405. Com o bloqueio por .htaccess ou firewall funcionando, você recebe 403 Forbidden, sinal de que o arquivo não responde mais. Se o filtro PHP estiver ativo, a página ainda abre, mas os métodos são recusados. Para um teste mais completo, ferramentas online de validação tentam executar o `pingback.ping` e o `system.multicall` e reportam se passam. Quem prefere automatizar pode rodar o FULL Scan, scanner de segurança gratuito da FULL que cruza o seu site com a base global de CVEs sem instalação. Confirmar o estado real é tão importante quanto aplicar o bloqueio: uma regra mal posicionada no .htaccess pode parecer ativa e não estar valendo. --- ## Quando manter o xml-rpc ativo faz sentido Manter o protocolo ativo só se justifica em cenários específicos e raros hoje. Se você usa um fluxo de publicação que depende exclusivamente da interface antiga, como integrações legadas que nunca migraram para a REST API, desativar quebra a automação. Nesses casos, a saída não é deixar o `xmlrpc.php` totalmente aberto, e sim restringir o acesso por IP no firewall, liberando apenas a origem confiável. O segundo caso é o Jetpack em instalações que, por algum motivo, ainda não foram atualizadas. A recomendação correta é atualizar o Jetpack para uma versão que use REST e só então desativar o XML-RPC, e não manter o endpoint aberto indefinidamente. Em ambos os cenários, vale o princípio de menor exposição: prefira liberar o mínimo necessário por IP a deixar o vetor inteiro disponível para qualquer origem na internet.

Legenda: quando há dependência legada, restringir o acesso por IP é mais seguro do que deixar o endpoint aberto.

--- ## Proteja todo o WordPress, não só um arquivo Fechar essa interface é uma camada de um conjunto maior, e é aí que o bundle da FULL muda a conta. O plano PRO da FULL reúne o All in One Security, com firewall e bloqueio de XML-RPC pronto, mais 16 plugins premium por R$849,90 ao ano, o que dá cerca de R$85 por site no plano de dez sites. Comprar AIOS, firewall e os demais plugins avulsos sai bem mais caro do que o bundle. Conheça os planos da FULL e ative a segurança completa do seu WordPress em um clique. Vale combinar esse bloqueio com outras defesas que a gente vê resolverem ataque na raiz: proteção contra força bruta, limite de tentativas de login e proteção da REST API. Para mitigar amplificação, o guia de ataques DDoS no WordPress mostra como o firewall de borda corta o pingback antes de ele chegar ao servidor. Consulte também o repositório de vulnerabilidades da FULL, atualizado com dados oficiais de CVEs.

Perguntas frequentes sobre desativar o xml-rpc no WordPress

Por que o XML-RPC é um risco de segurança no WordPress?

Porque o `xmlrpc.php` aceita o método system.multicall, que empacota centenas de tentativas de login em uma única requisição HTTP e fura o limitador de tentativas por IP. Além disso, o método pingback.ping transforma o site em amplificador de DDoS. São dois vetores reais de ataque automatizado, e o WordPress moderno já não precisa dessa interface, porque migrou para a REST API.

É possível desativar o XML-RPC sem quebrar o Jetpack e os apps móveis?

Sim, na grande maioria dos sites. O Jetpack atual e o app móvel oficial usam a REST API, não o protocolo antigo, então desativar o `xmlrpc.php` não afeta nenhum dos dois. Só quebra em versões muito antigas do Jetpack, que ainda dependiam dele. A recomendação é atualizar o Jetpack antes e só depois aplicar o bloqueio, garantindo a conexão pela REST.

Qual a diferença entre bloquear por plugin e por .htaccess?

O plugin, como o All in One Security, bloqueia dentro do WordPress, o que exige carregar o PHP a cada requisição. O `.htaccess` nega o acesso no servidor Apache, antes do WordPress iniciar, e por isso alivia muito mais a CPU sob ataque de system.multicall. Para sites sob força bruta ativa, o bloqueio no .htaccess ou no firewall de borda é tecnicamente superior.

Quando faz sentido manter o XML-RPC ativo no WordPress?

Faz sentido apenas quando há uma integração legada que depende exclusivamente do protocolo e nunca migrou para a REST API. Mesmo nesses casos, o correto não é deixar o `xmlrpc.php` aberto para a internet inteira, e sim liberar o acesso só para o IP de origem confiável no firewall. Para a esmagadora maioria dos sites, esse endpoint pode ser fechado sem nenhum efeito visível.

O que é o método system.multicall do XML-RPC?

O system.multicall é o método que executa várias chamadas em uma só requisição. Foi pensado para eficiência, mas virou arma: um atacante envia uma lista com centenas de senhas e o servidor testa todas de uma vez, sem disparar o contador de tentativas de login. Por isso ele é o vetor mais perigoso do `xmlrpc.php` e a principal razão técnica para fechar a interface.

--- ## Próximos passos para fechar o vetor Desativar o XML-RPC no WordPress é uma decisão de baixo custo e alto retorno: você fecha dois vetores de ataque ativos sem quebrar o site moderno. Comece pela camada que cabe no seu acesso, plugin para o caminho rápido, .htaccess ou firewall de borda para o bloqueio antes do PHP, e confirme o resultado abrindo o `xmlrpc.php` no navegador. Trate o bloqueio como parte de um hardening maior, com atualização em dia e firewall ativo. Para continuar aprendendo, o guia de segurança para WordPress da FULL reúne os próximos passos em um só lugar.