Checklist de segurança para WordPress em 2026

Checklist de segurança WordPress 2026: atualizações, fim dos plugins piratas, 2FA, permissões, WAF/Cloudflare, backups externos, DISALLOW_FILE_EDIT e xmlrpc.

A segurança do WordPress em 2026 se resume a cinco hábitos: manter núcleo, plugins e temas atualizados; nunca usar plugin ou tema pirata; ativar 2FA para todos os administradores; ter backups automáticos fora do servidor; e colocar um firewall (WAF) na frente do site. O resto deste checklist refina esses pontos, mas se você fizer só eles, já elimina a maior parte do risco de invasão.

Os itens abaixo seguem a ordem de impacto. Cada um tem o porquê e o como, com comandos e trechos de configuração quando faz sentido.

Atenção: antes de mexer em wp-config.php, .htaccess ou permissões, faça um backup completo dos arquivos e do banco de dados. Um erro de digitação nesses arquivos pode tirar o site do ar.

Por que plugins são o ponto fraco

O núcleo do WordPress é muito revisado e tem poucas falhas. O problema está no ecossistema. Segundo o relatório State of WordPress Security in 2025, da Patchstack, foram descobertas 7.966 vulnerabilidades no ecossistema WordPress em 2024, sendo 96% em plugins, cerca de 4% em temas e apenas sete no núcleo. O mesmo relatório aponta muitas falhas em plugins abandonados, que provavelmente nunca vão receber correção.

Conclusão prática: cada plugin é uma porta. Menos plugins, mais bem mantidos, é a decisão de segurança mais barata que existe.

1. Atualizações

• Núcleo: as atualizações menores (de segurança) são automáticas por padrão. Não desative. Atualize as versões principais assim que possível, depois de testar se for um site crítico.
• Plugins e temas: ative a atualização automática pelo menos para os plugins simples e de fornecedores confiáveis. Para os críticos (loja, construtor de páginas), atualize com frequência e com backup antes.
• PHP: use uma versão de PHP ainda com suporte de segurança. Peça para a hospedagem ou troque no painel.

Com WP-CLI, para ver o que está pendente:

wp core check-update
wp plugin list --update=available
wp theme list --update=available

2. Plugins e temas piratas (nulled): a porta mais escancarada

Plugin ou tema "nulled" é a versão paga distribuída de graça em sites e grupos, com a licença removida. É uma das portas de entrada mais comuns em invasões de WordPress, por três motivos:

1. Muitas cópias já vêm com backdoor. Quem distribui tem um motivo para isso, e o motivo raramente é generosidade.
2. Não recebem atualização de segurança, porque não estão ligadas a uma licença válida.
3. Ninguém audita. Você não sabe o que foi alterado no código.

A orientação do WordPress.org é baixar plugins e temas só de fontes confiáveis, como o repositório oficial ou o site do próprio fornecedor. Se o seu site tem algum pirata, troque pela versão oficial (paga) ou por uma alternativa gratuita do repositório, e considere que o site pode já estar comprometido: rode a varredura do guia como remover malware e backdoors do WordPress.

E apague, não apenas desative, plugins e temas que você não usa. Código desativado continua no servidor e pode ser explorado.

3. Login, senhas e 2FA

• 2FA para todos os administradores e editores, com aplicativo autenticador (não SMS, se der). A documentação de hardening do WordPress.org recomenda a autenticação em duas etapas. Vários plugins de segurança oferecem isso.
• Senhas longas e únicas, guardadas num gerenciador de senhas. Senha reaproveitada de outro serviço vazado é como invasor entra sem precisar de falha nenhuma.
• Limite de tentativas de login ou CAPTCHA, pelo plugin de segurança ou pelo WAF.
• Nada de usuário admin com senha óbvia.
• 2FA também na hospedagem, no registrador do domínio e no e-mail. De nada adianta blindar o WordPress se dá para entrar no painel da hospedagem.

4. Usuários e permissões

• Revise os usuários periodicamente. Cada pessoa com o menor papel possível: quem escreve é Autor ou Editor, não Administrador.
• Remova acessos de ex-funcionários, freelancers e agências antigas.
• Liste os administradores de vez em quando:

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

• Permissões de arquivos: a documentação do WordPress.org recomenda 755 para pastas e 644 para arquivos, e o wp-config.php mais restrito (por exemplo, 440 ou 400, se a hospedagem permitir). Nunca 777.

find /caminho/do/site -type d -exec chmod 755 {} \;
find /caminho/do/site -type f -exec chmod 644 {} \;
chmod 440 /caminho/do/site/wp-config.php

Confirme com a hospedagem antes do 440: em alguns ambientes o PHP roda com outro usuário e o site deixa de ler o arquivo.

5. Endurecendo o wp-config.php

Desative o editor de arquivos do painel. Se alguém roubar um login de admin, não consegue editar PHP pelo navegador:

define( 'DISALLOW_FILE_EDIT', true );

A documentação do WordPress.org lembra que isso não impede o envio de arquivos maliciosos por outras vias. É uma camada, não uma muralha.

Se quiser ir além e bloquear também instalação e atualização de plugins e temas pelo painel (útil em sites gerenciados por agência, que atualizam via deploy ou WP-CLI):

define( 'DISALLOW_FILE_MODS', true );

Atenção: com DISALLOW_FILE_MODS, o painel também deixa de atualizar plugins. Só use se tiver outra rotina de atualização.

Outros itens do wp-config.php:

• Salts únicos e regenerados se houver suspeita de vazamento (wp config shuffle-salts).
• define( 'WP_DEBUG', false ); em produção, para não exibir erros com caminhos do servidor.
• Bloqueie o acesso direto ao arquivo no Apache:

<Files "wp-config.php">
Require all denied
</Files>

6. Bloqueie PHP em uploads

A pasta wp-content/uploads só deveria ter mídia. Bloquear a execução de PHP lá impede que um arquivo enviado por uma falha vire backdoor. Crie wp-content/uploads/.htaccess (Apache):

<FilesMatch "\.(php|phtml|php[0-9]?)$">
Require all denied
</FilesMatch>

Em Nginx, o equivalente é uma regra location na configuração do servidor, que a hospedagem precisa aplicar.

7. xmlrpc.php

O xmlrpc.php é uma interface antiga de publicação remota, muito usada em ataques de força bruta porque permite testar várias senhas numa só requisição. Se você não usa nada que dependa dele, bloqueie no .htaccess da raiz:

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

Antes, verifique se algum plugin ou integração precisa dele (o Jetpack, por exemplo, usa). A maioria dos plugins de segurança e WAFs também oferece essa opção.

8. WAF e Cloudflare

Um firewall de aplicação web (WAF) filtra ataques antes que eles cheguem ao WordPress. A documentação do WordPress.org cita três caminhos, que podem ser combinados:

• WAF no servidor, como o ModSecurity, normalmente ativado pela hospedagem;
• proxy reverso como Cloudflare ou Sucuri, que fica na frente do site;
• plugin de firewall, como Wordfence, que filtra no nível do WordPress.

Para pequenos sites, o plano gratuito da Cloudflare já traz proteção contra DDoS e algumas regras de firewall personalizadas (os limites de cada plano mudam, confira no painel). Um passo simples e eficaz: criar uma regra que desafie (CAPTCHA) acessos a /wp-login.php e /xmlrpc.php vindos de fora do Brasil, se seu público é só nacional.

9. Backups fora do servidor

Backup guardado no mesmo servidor do site some junto com ele (ou é infectado junto).

• Automático, diário para lojas e sites com cadastro, semanal para sites que mudam pouco.
• Arquivos e banco. Um sem o outro não restaura o site.
• Fora do servidor: armazenamento em nuvem (S3, Google Drive, Backblaze, Dropbox) ou o backup externo da hospedagem.
• Várias versões guardadas por semanas, porque invasões podem ficar escondidas antes de aparecer.
• Teste a restauração de vez em quando, num ambiente de teste. Backup nunca testado é esperança, não backup.

10. Hospedagem

A hospedagem é a fundação. Prefira as que oferecem:

• isolamento entre contas e sites (um site invadido não contamina os outros);
• versões atuais do PHP;
• WAF e varredura de malware no servidor;
• backups automáticos com retenção;
• SSH/SFTP (em vez de FTP sem criptografia) e 2FA no painel.

Evite colocar vários sites na mesma conta compartilhada sem isolamento. Um site esquecido e desatualizado vira a porta para todos.

11. Monitoramento

Você quer saber da invasão antes do seu cliente:

• Google Search Console configurado, com alertas de e-mail: ele avisa sobre problemas de segurança.
• Monitor de disponibilidade (uptime) que alerta quando o site cai.
• Varredura periódica de arquivos (plugin de segurança ou hospedagem) e alerta de alteração de arquivos do núcleo.
• Verificação de checksums de vez em quando: wp core verify-checksums e wp plugin verify-checksums --all.
• Log de atividades (quem entrou, o que mudou), útil para investigar se algo acontecer.

Se algo parecer errado, veja os sinais de que o site foi hackeado.

Checklist resumido

Se você está planejando um site novo e quer entender onde entra o custo de manutenção e segurança, veja também quanto custa um site.

Quer que alguém cuide disso por você?

Todos os itens deste checklist podem ser feitos por quem tem um pouco de familiaridade com painel de hospedagem e WordPress. Se preferir delegar, a Mobgeek tem um plano mensal de proteção para WordPress. E se o site já foi invadido, existe o serviço de limpeza de site WordPress invadido, com remoção de malware e backdoors, hardening, pedido de revisão no Google, relatório e 30 dias de garantia contra reinfecção (a partir de R$ 790, início em até 24h). Para qualquer um dos dois, é só pedir um orçamento.