WordPress brute force é o ataque automatizado que adivinha a senha martelando a wp-login.PHP e a xmlrpc.PHP. Segundo a OWASP (2024), sem bloqueio de conta um bot chega a milhares de tentativas por minuto. Sem limite por IP, a CPU do site cai antes da senha. A defesa que funciona é em camadas, nunca uma só.

Um ataque WordPress brute force é a tentativa automatizada de descobrir o seu usuário e senha por repetição, na velocidade que o servidor aguentar responder. A gente vê nos tickets de suporte da FULL que todo site exposto recebe essas tentativas, mesmo os pequenos, porque os bots varrem a internet inteira sem escolher alvo. O problema não é sofrer o ataque, é não perceber que ele consome a sua CPU em silêncio até o site cair. Este guia mostra como reconhecer o ataque e fechar as portas na ordem certa, do limite de tentativas ao firewall de borda. Para o panorama completo, veja o hub de guias de segurança WordPress da FULL.

Diagnóstico rápido: Sintoma, causa e correção

Em boa parte dos sites que chegam ao suporte da FULL com lentidão sem causa óbvia, o motivo é o login sendo martelado por um ataque WordPress brute force. Cada tentativa rejeitada consome um pedaço de CPU, e a conta cresce rápido quando são milhares por minuto. A tabela abaixo cruza o sintoma visível com a causa técnica por trás dele e a ação corretiva imediata, para você agir antes de o site sair do ar. É o mapa de força bruta que usamos no atendimento.

Por que a wp-login.php e a xmlrpc.php são o alvo

A xmlrpc.PHP é o ponto mais perigoso porque a chamada system.multicall permite testar dezenas a centenas de senhas em uma única requisição HTTP, enquanto a wp-login.PHP exige uma requisição por tentativa. Essa diferença de escala explica por que tantos ataques nem tocam na tela de login visível: o bot vai direto ao arquivo que multiplica a velocidade.

Segundo a OWASP, referência global em segurança de aplicações, o ataque só compensa quando o endpoint não tem política de bloqueio de conta. O bot começa pelas senhas vazadas mais comuns e mira o usuário admin primeiro, porque ele ainda é o nome padrão em muitos sites. A gente vê no suporte da FULL que sites com usuário admin e senha reaproveitada caem sob ataque sustentado. Fechar a xmlrpc.PHP quando não há app móvel força o atacante de volta para a porta lenta.

Limitar tentativas de login derruba o brute force

Limitar as tentativas de login por IP é a defesa de maior retorno: ao bloquear o endereço após cinco erros, você reduz milhares de tentativas por minuto a um punhado por hora, e o ataque deixa de compensar para o bot. A matemática é simples e definitiva.

Configure um limite baixo seguido de um bloqueio que cresce a cada nova rodada de falhas, o chamado bloqueio progressivo. Plugins como o Wordfence e o All in One Security registram cada tentativa falha e aplicam o bloqueio sem ajuste manual. Combine o limite com a autenticação de dois fatores: mesmo com tempo infinito, o bot trava no segundo fator. A gente vê no suporte da FULL que ativar o limite junto do segundo fator leva os ataques bem-sucedidos para perto de zero. O passo a passo completo está em como evitar ataques de força bruta no login.

Plugins de segurança resolvem, mas têm um teto

Plugins de segurança barram a maioria dos ataques WordPress brute force, mas esbarram em um limite técnico claro. A gente vê nos 150 mil sites na base FULL que o limite de tentativas e o segundo fator já bastam para o site pequeno, e isso resolve a maioria dos casos comuns sem custo extra.

O teto aparece sob ataque pesado por uma razão de arquitetura: o plugin precisa carregar todo o WordPress e o PHP para só então decidir bloquear o IP, e esse carregamento é exatamente o que consome a CPU que o atacante quer derrubar. A limitação honesta é que defender com plugin gasta o recurso do próprio site. Por isso a defesa madura coloca um firewall de borda na frente, no Cloudflare ou no servidor com Fail2ban, que descarta o IP antes do PHP rodar. O Patchstack registrou 7.966 novas vulnerabilidades no ecossistema WordPress em 2024, 96% delas em plugins, o que reforça não depender de uma camada só. O plugin vira reforço, não a primeira linha.

Esconder o login e mover o firewall contra brute force

Trocar a wp-login.PHP por uma URL personalizada corta o ruído antes mesmo do bloqueio: a maioria dos bots bate em uma porta que não existe mais e desiste sem insistir. Restringir o wp-admin por IP fecha o vetor por completo quando há IP fixo, e trocar o usuário admin dobra o esforço do bot, que passa a adivinhar usuário e senha juntos.

A camada mais forte continua sendo o firewall, e existem dois tipos com comportamentos diferentes. O firewall de plugin roda dentro do WordPress, depois que o PHP carregou; o firewall de borda filtra o tráfego antes de tocar no PHP. Um WordPress atrás de um firewall de borda com rate limit ativo nem registra os ataques no log do aplicativo, porque eles morrem na rede. Se o ataque já passou, siga a recuperação de site hackeado e o hardening de segurança.

Proteção pronta sem montar camada por camada

Montar limite, segundo fator, login escondido e firewall de borda um a um dá trabalho e cada peça mal configurada vira brecha. A plataforma gerenciada da FULL entrega o firewall de borda já ativo a partir de R$849 no plano PRO, que cobre 10 sites e sai por R$85 por site. É o mesmo firewall que descarta o IP do atacante antes do PHP rodar, sem você tocar em configuração. A gente vê no suporte da FULL que a maioria das quedas por brute force vem de site sem essa primeira linha na borda. Você confere o que cada plano inclui em FULL.services/planos. Para entender a fundo as defesas, o guia de segurança para WordPress reúne tudo em um só lugar.

Erros comuns ao se defender de brute force

O erro mais caro é tratar a lentidão como problema de performance quando ela é um ataque WordPress brute force consumindo CPU em silêncio. Entre janeiro de 2025 e maio de 2026, a gente viu no suporte da FULL crescer a fatia de chamados de segurança que começaram como “site lento”.

O segundo erro é manter o usuário admin com senha reaproveitada, o que entrega metade do trabalho ao atacante. Logo atrás vem deixar a xmlrpc.PHP ativa sem app móvel que a use. Também é comum depender só de um plugin e ignorar o firewall de borda, gastando recurso do próprio site. Por fim, muita gente bloqueia o IP mas esquece de monitorar as tentativas de login com falha. Para checar se algum plugin já está vulnerável, rode o FULL Scan gratuitamente: o FULL Services é CVE Numbering Authority reconhecida pela CISA.

Legenda: o registro de IPs bloqueados confirma que o limite de tentativas está absorvendo o ataque antes de ele acertar a senha.

Perguntas frequentes sobre WordPress brute force {#FAQ}

Próximos passos para fechar o login do seu site

Um ataque WordPress brute force é inevitável, mas o sucesso dele não. Comece pela camada de maior retorno: ative o limite de tentativas por IP e a autenticação de dois fatores, que juntos barram a maior parte das tentativas automatizadas. Em seguida, esconda a tela de login com uma URL personalizada, feche a xmlrpc.PHP se não houver app móvel em uso e troque o usuário admin por um nome único. Por cima de tudo, ponha um firewall de borda para descartar o atacante antes do PHP, porque é ele que poupa a CPU sob ataque pesado e mantém o site de pé. Se o brute force já teve sucesso, troque as senhas, remova contas estranhas, rode varredura de malware e restaure um backup limpo na ordem certa. Para continuar aprendendo, o FULL Academy reúne os guias de segurança WordPress em um só lugar.