WordPress seguro en 2026: checklist de lo que un atacante ve

Todo artigo de "WordPress seguro" no Brasil termina recomendando o mesmo plugin de firewall e duas mudanças no wp-config.php. Isso resolve metade do problema. A outra metade está no que um visitante anônimo da internet consegue ver sem nunca tocar no seu painel.

Esse checklist é o que um atacante chuta primeiro. Roda a lista. O que aparecer vermelho, conserta hoje.

1. Versão exposta na fonte da página

Abra o site em uma aba anônima, view-source, busque wp-content/themes/ ou wp-content/plugins/. Você verá algo como:

?ver=6.4.3
?ver=4.9.8

O ?ver= é o número de versão do plugin/theme exposto pro mundo. Atacante cruza com WPScan Vulnerability Database e sabe exatamente qual exploit testar.

Mitigação: remover a query string de versão dos assets em produção (filtro style_loader_src e script_loader_src), ou minificá-los via cache plugin que junta tudo num arquivo só.

2. /wp-json/wp/v2/users aberto

Acesse https://seusite.com.br/wp-json/wp/v2/users. Se voltar JSON com lista de usuários (incluindo o slug — que é o login do admin no WordPress), você acabou de entregar metade do brute-force.

Mitigação: desabilitar endpoints REST de users pra usuários não autenticados. Snippet:

add_filter('rest_endpoints', function ($endpoints) {
    if (isset($endpoints['/wp/v2/users'])) unset($endpoints['/wp/v2/users']);
    if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    return $endpoints;
});

3. /?author=1 revela login

https://seusite.com.br/?author=1 redireciona pra /author/seu-login-real/. Em segundos, atacante tem o usuário e parte pro brute force no /wp-login.php.

Mitigação: ou bloquear redirecionamento via template_redirect filter, ou trocar slug do usuário admin pra algo diferente do login.

4. /wp-admin/ sem rate-limit

Tente errar a senha 10 vezes seguidas. Se na 11ª você ainda consegue tentar, não tem rate-limit. Bot brasileiro padrão tenta 50 senhas por minuto até cansar.

Mitigação: Limit Login Attempts (plugin), Fail2Ban no servidor, ou Cloudflare regra de challenge pra /wp-login.php.

5. Backups esquecidos na pasta pública

A pior. Atacante chuta:

/backup.zip
/site.sql
/bd.sql
/database.sql
/wp-content/backups/
/wp-content/uploads/2024/db.sql
/.git/config
/wp-config.php.bak
/wp-config.old

Cada uma dessas dá hit em alguma loja brasileira hoje. Dump SQL exposto = banco inteiro vazado, incluindo hash de senha de cliente.

Mitigação: nunca deixar backup em pasta servida pelo HTTP. Use S3, FTP off-site, ou pasta acima do public_html. E nega *.sql, *.zip, *.bak, *.old, .git/ no .htaccess ou nginx.conf.

6. xmlrpc.php aberto

/xmlrpc.php aceita autenticação por XML-RPC. Atacante usa system.multicall pra testar 500 senhas por requisição — burlando rate-limit do /wp-login.php.

Você usa Jetpack, app mobile do WP ou pingbacks? Não? Bloqueie.

Mitigação: Deny from all em xmlrpc.php no .htaccess, ou bloqueio no Cloudflare.

7. Versão do PHP e Apache no header

curl -I https://seusite.com.br/ e veja:

Server: Apache/2.4.18 (Ubuntu)
X-Powered-By: PHP/7.2.34

PHP 7.2 está sem suporte desde 2020. Apache 2.4.18 tem CVE crítico. Esses headers gritam pro atacante "tenta isso aqui".

Mitigação: expose_php = Off no php.ini, ServerTokens Prod no Apache, server_tokens off no nginx.

8. Plugin abandonado

Veja seus plugins ativos. Algum não recebe update há mais de 2 anos? Plugin com 50 mil instalações e último commit em 2022 é vetor preferido pra ataque em massa — quando saí o exploit, todo mundo cai junto.

Mitigação: trocar por alternativa mantida. Plugin de 2 anos sem atualização não é estável, é abandonado.

9. wp-content/uploads/ com PHP executável

Faça upload de uma imagem chamada teste.php.jpg. Acesse. Se o servidor executar como PHP, você tem RCE servido na bandeja em qualquer plugin com upload furado.

Mitigação: nega execução de .php dentro de /uploads/ via servidor:

location ~* /wp-content/uploads/.*\.php$ {
    deny all;
}

10. HTTPS sem redirecionamento e sem HSTS

Site responde em http:// e https://? Não tem Strict-Transport-Security no header? Cookie de sessão pode vazar em rede pública.

Mitigação: redirect 301 de HTTP pra HTTPS no servidor, e header Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.

Como o Sentinela cobre isso automaticamente

A gente roda essa varredura toda noite no seu domínio:

• Versão de WP, plugin e theme expostas
• Endpoints REST sensíveis abertos
• Arquivos de backup chutados em 200+ paths conhecidos
• Headers de servidor e PHP vazando
• xmlrpc.php ativo
• Auth via /?author=N
• Certificado SSL e HSTS
• Match de CVE pra cada versão detectada

Quando você conecta o repositório, a gente ainda roda SAST e secret scanning só no seu código — sem afogar o relatório em ruído do WP core (que é um anti-padrão comum e já contamos a história aqui).

Tem 14 dias grátis. Coloca seu domínio e em 10 minutos você vê quantos desses 10 itens da sua casa estão abertos. Pra um mergulho maior em headers especificamente, veja 5 cabeçalhos de segurança HTTP.

A regra simples

A maioria dos sites WordPress hackeados em 2026 não cai por exploit caro. Caem por uma dessas 10 coisas. Roda a lista hoje.