Como proteger seu site WordPress contra ataques: checklist de 2026

Para proteger um site WordPress de ataques, feche as portas conhecidas: mantenha núcleo, plugins e temas atualizados (de preferência no automático), use senhas fortes com autenticação em dois fatores, ajuste as permissões de arquivos, desligue o editor de arquivos do painel e o XML-RPC que você não usa, remova plugins abandonados e tenha backup com cópias de dias diferentes. Nenhuma dessas medidas sozinha resolve; juntas, elas tiram o site da lista de alvos fáceis.

Este checklist segue o guia oficial Hardening WordPress, da documentação do WordPress.org, e foi testado no WordPress 7.1.3 em português. Se o seu site já foi invadido, comece pela limpeza (o guia de remoção de malware está nos artigos relacionados) e volte aqui para fechar a porta.

Proteger o WordPress começa pelas atualizações automáticas

Versão antiga é a porta mais fácil, porque as falhas corrigidas ficam públicas. O WordPress tem três frentes de atualização:

• Núcleo: as versões de manutenção e segurança são automáticas por padrão. Em instalações feitas a partir do WordPress 5.6, as versões principais também são. Confira em Painel > Atualizações.
• Plugins e temas: não se atualizam sozinhos, salvo em casos especiais em que o próprio WordPress.org libera uma correção crítica. Você liga o automático plugin a plugin, na coluna Atualizações automáticas da tela de plugins.
• Traduções: automáticas por padrão.

Com acesso SSH e WP-CLI, dá para ligar o automático de todos de uma vez:

wp plugin auto-updates enable --all
wp theme auto-updates enable --all

Se você precisa controlar o núcleo pelo wp-config.php, a constante WP_AUTO_UPDATE_CORE aceita true (todas as versões), 'minor' (só manutenção e segurança) ou false (nenhuma). Quando definida, ela vale mais que a opção da tela de atualizações.

Atualizar o PHP também conta. A página de requisitos do WordPress.org recomenda PHP 8.3 ou mais novo e MySQL 8.0 ou MariaDB 10.11 ou mais novos; versões anteriores ainda rodam, mas já estão sem suporte.

Senhas, dois fatores e o usuário admin

O guia oficial pede senha forte e aleatória e recomenda a verificação em duas etapas. O WordPress não traz 2FA no núcleo; o caminho mais direto é o plugin Two Factor, mantido por colaboradores do WordPress.org e publicado no diretório oficial. Ele oferece aplicativo autenticador (TOTP), códigos de recuperação e código por e-mail. Depois de ativar, a configuração fica no seu perfil, em Usuários > Perfil.

Ative o aplicativo autenticador e gere os códigos de recuperação, guardando-os fora do computador. Faça isso para todos os administradores.

Sobre o usuário admin: o WordPress não deixa mudar o nome de usuário pelo painel. Para sair de um admin antigo, crie outro administrador com um nome que não seja óbvio, entre com ele, exclua o antigo e atribua os posts ao novo. Aproveite para revisar quem é administrador:

wp user list --role=administrator --fields=ID,user_login,user_email

Dê a cada pessoa o menor papel que resolve o trabalho dela: quem só escreve posts é Autor ou Editor, não Administrador.

O WordPress também não limita tentativas de login. Essa proteção vem de um firewall de aplicação (WAF) no servidor ou de um plugin de limite de tentativas.

Permissões de arquivos e wp-config.php

As recomendações da documentação oficial são diretas:

• Pastas com permissão 755 e arquivos com 644.
• wp-config.php com 440 ou 400, para que outros usuários do servidor não leiam a senha do banco.
• Nunca 777. Se um plugin pede 777, o problema é o plugin ou o dono dos arquivos.
• Os arquivos devem pertencer ao usuário da sua conta, e não ao processo do servidor web.

find . -type d -exec chmod 755 {} +
find . -type f -exec chmod 644 {} +
chmod 440 wp-config.php

No mesmo arquivo, desligue o editor de arquivos do painel. Com ele ativo, quem rouba uma senha de administrador consegue gravar código PHP direto num tema ou plugin. A linha vai no wp-config.php, antes do comentário que pede para parar de editar:

define( 'DISALLOW_FILE_EDIT', true );

O guia oficial lembra que isso não impede o envio de arquivos maliciosos, mas corta um caminho comum. No teste, os itens Editor de arquivos de tema e Editor de arquivos de plugin sumiram do menu Ferramentas.

Com o wp-config.php em 440, plugins de cache e o próprio WP-CLI não conseguem mais gravar nele. Se precisar mudar alguma constante, volte a permissão para 640 ou 644, edite e retorne para 440.

XML-RPC: desligue se você não usa

O arquivo xmlrpc.php atende o Jetpack, ferramentas de publicação remota e alguns aplicativos. Ele também aceita o método system.multicall, que permite testar várias senhas numa única requisição, por isso aparece tanto em tentativas de força bruta.

O filtro xmlrpc_enabled, do próprio WordPress, não resolve sozinho: segundo a documentação, ele desliga só os métodos que exigem login, e não o XML-RPC inteiro. Se você não usa nada que dependa dele, bloqueie o arquivo no servidor. No Apache, acrescente ao .htaccess, fora do bloco # BEGIN WordPress:

<Files "xmlrpc.php">
    Require all denied
</Files>

Usa o Jetpack ou alguma ferramenta que publica pelo XML-RPC? Então não bloqueie: proteja o login com 2FA e um WAF.

Plugins abandonados e o Diagnóstico do site

Cada plugin é código de terceiro rodando com acesso total ao site. O guia oficial recomenda manter os plugins atualizados, apagar os que não usa e instalar só de fontes confiáveis, como o diretório do WordPress.org. Na prática:

• Apague o que está desativado. Plugin desativado continua no servidor e pode ter falha explorável.
• Antes de instalar, olhe a data da última atualização e o aviso de compatibilidade. O diretório avisa quando um plugin não foi testado com as três últimas versões principais do WordPress, e mostra quando um plugin foi fechado.
• Nunca use plugin ou tema nulled (versão pirata de um produto pago). É uma das formas mais diretas de colocar um backdoor no próprio site.

O WordPress tem uma tela que aponta parte disso sozinha: Ferramentas > Diagnóstico (Site Health, no WordPress em inglês). No teste, ela pediu para remover plugins e temas desativados e avisou que o site não usava HTTPS.

HTTPS não é opcional: sem ele, senha e cookie de login trafegam abertos. As senhas de aplicação do WordPress, por exemplo, nem são liberadas em sites sem HTTPS.

Backup e o plano para quando algo der errado

Proteção reduz o risco, não zera. O guia oficial pede backups regulares, incluindo o banco, com cópias de datas diferentes, para que exista uma versão anterior à invasão. Guarde as cópias fora do servidor do site e teste a restauração de vez em quando: backup que nunca foi restaurado é uma aposta.

Mantenha também os registros de acesso e de erro. Depois de um incidente, são eles que mostram por onde o ataque entrou.

Parte desse checklist depende do servidor, e não do WordPress. A hospedagem para WordPress da Hospedagem Segura inclui Imunify360 contra malware e com WAF, isolamento de cada conta com CloudLinux e CageFS, SSL automático e backups periódicos conforme o plano. As atualizações, os plugins e os usuários do site continuam sendo responsabilidade de quem administra o WordPress.

Perguntas frequentes

Qual é o melhor plugin de segurança para WordPress?

Não existe um que resolva tudo. O básico é atualização automática, 2FA (o plugin Two Factor, do diretório oficial, cobre isso) e um WAF, que pode vir do servidor ou de um plugin. Evite somar vários plugins de segurança que fazem a mesma coisa.

Qual permissão usar no wp-config.php?

440 ou 400, segundo a documentação oficial do WordPress. Pastas ficam em 755 e os demais arquivos em 644. Nunca use 777.

Devo desativar o XML-RPC do WordPress?

Se você não usa o Jetpack nem ferramentas de publicação remota, sim. Bloqueie o xmlrpc.php no servidor, porque o filtro xmlrpc_enabled desliga só os métodos que exigem login.

Atualização automática pode quebrar o site?

Pode acontecer, principalmente com plugins mal mantidos. Por isso a atualização automática anda junto com backup recente e com plugins de autores que atualizam com frequência. Site desatualizado é um risco maior.

Mudar a URL do wp-admin deixa o WordPress seguro?

Ajuda a reduzir tentativas automáticas de login, mas não substitui senha forte, 2FA e atualizações. Trate como medida extra, nunca como a principal.