WordPress Admin Bloqueado Antes do Login: Diagnóstico Forense e Correção via WP-CLI

WordPress Admin Bloqueado Antes do Login: Diagnóstico Forense e Correção via WP-CLI

Quando a segurança vira o problema, o incidente escala rápido. Você tenta abrir /wp-admin/ e recebe:

You do not have permission to access this page. Please log in and try again.

O ponto crítico: não aparece formulário de login. Nesse cenário, reset de senha por banco/e-mail não resolve nada, porque o fluxo morreu antes da autenticação.

---

1) Cenário do incidente e hipótese correta

Se o wp-login.php nem carrega, sua investigação precisa focar em camada de bloqueio:

• servidor web/WAF (403, mod_security, regras Nginx/Apache);
• plugin de segurança encerrando execução no bootstrap do WordPress;
• regra persistida em .htaccess após ativação de hardening.

O erro “parece permissão”, mas a causa real costuma ser interceptação de request antes do fluxo normal de auth.

---

2) Diagnóstico por camadas (forense objetivo)

2.1 Teste HTTP com cURL

curl -I https://domain.com/wp-admin/

Leitura operacional:

• HTTP 403: bloqueio na camada de servidor/WAF.
• HTTP 200 com mensagem de bloqueio: WordPress está vivo, plugin interceptou pipeline.

No incidente que tratei, o WordPress carregava, mas o plugin de firewall abortava a execução.

2.2 Validar se o core está íntegro

wp core is-installed

Se retornar OK, banco e core estão íntegros e você deve concentrar no ecossistema (plugins/rules).

---

3) Incident response com WP-CLI

3.1 Listar plugins com slug real

wp plugin list

O erro comum é tentar desativar por nome “amigável”. O WP-CLI usa slug técnico.

No caso do All In One WP Security, o slug correto é:

all-in-one-wp-security-and-firewall

3.2 Desativação cirúrgica

wp plugin deactivate all-in-one-wp-security-and-firewall

Se o plugin estiver interferindo no próprio comando:

wp plugin deactivate all-in-one-wp-security-and-firewall --skip-plugins

Esse parâmetro é essencial em incidente grave, porque ignora carregamento de plugins durante a execução do WP-CLI.

---

4) Plano de contingência quando WP-CLI falha

Quando o ambiente está muito quebrado, use fallback manual no filesystem:

mv wp-content/plugins/all-in-one-wp-security-and-firewall \
   wp-content/plugins/all-in-one-wp-security-and-firewall.bak

Ao renomear o diretório, o WordPress deixa de carregar o plugin no bootstrap.

---

5) O rastro oculto no .htaccess

Mesmo com plugin desativado, o bloqueio pode continuar se ele deixou regras ativas no .htaccess.

Inspecione blocos como:

# BEGIN All In One WP Security
...
# END All In One WP Security

Se necessário, remova o bloco e revalide acesso.

Dica de operação

Sempre faça backup do arquivo antes de editar:

cp .htaccess .htaccess.bak.$(date +%F-%H%M%S)

---

6) Ambientes com proxy/WAF: X-Forwarded-For como vilão silencioso

Em stack com Cloudflare/Nginx reverse proxy, plugin pode interpretar IP errado e disparar falso positivo.

Cenário típico:

• plugin lê IP de origem incorreto;
• whitelisting falha;
• lockout contínuo mesmo para admin legítimo.

Por isso, em produção com proxy, validar cadeia de headers (X-Forwarded-For, CF-Connecting-IP) é parte obrigatória da configuração de segurança.

---

7) Toolbox de recuperação rápida

7.1 Validar URLs base (redireciono anômalo)

wp option get siteurl && wp option get home

7.2 Reatribuir papel admin

wp user set-role MEU_USUARIO administrator

7.3 Criar admin temporário com senha forte

wp user create fixadmin admin@domain.com --role=administrator --user_pass="$(wp eval 'echo wp_generate_password(18);')"

---

8) Pós-incidente: prevenção e governança

Lições que viraram padrão no meu runbook:

1. Segurança com saída de emergência: todo controle de firewall precisa ter plano de rollback por CLI.
2. SSH é requisito de produção: sem terminal, incident response vira loteria.
3. Documente slug técnico dos plugins críticos: acelera resposta e reduz erro humano.
4. Checklist pós-hardening: validar /wp-admin, wp-login.php, REST/AJAX e headers de proxy.

---

Conclusão

Bloqueio no /wp-admin antes do login não se resolve com tentativa aleatória. Resolve com análise de camada, evidência e ação cirúrgica.

Quando você identifica onde a requisição morreu (HTTP vs app), o tempo de recuperação cai drasticamente. Isso é operação madura: menos achismo, mais método.

Este post está licenciado sob CC BY-NC.