Segurança do WordPress: dicas práticas para proteger seu site em 2026

Para manter a segurança do WordPress em 2026, você precisa de cinco hábitos: atualizar núcleo, plugins e temas sem atraso, proteger os logins com senha forte e verificação em duas etapas, barrar ataques ao wp-login.php antes que cheguem ao site, guardar backups fora do servidor e ter um plano pronto para o dia em que algo der errado.

O maior risco raramente está no WordPress em si. Segundo o relatório State of WordPress Security in 2026, da Patchstack, foram registradas 11.334 novas vulnerabilidades no ecossistema em 2025: 91% em plugins, 9% em temas e só 6 no núcleo, todas de baixa prioridade. O mesmo estudo aponta que 46% das falhas não tinham correção do desenvolvedor quando foram divulgadas.

---

Atualizações: núcleo, plugins e temas

Atualizar é a medida de maior impacto e a mais adiada. Como a maioria das falhas está em plugins e temas, um site com o núcleo em dia, mas com extensões paradas há meses, continua exposto.

Componente	Comportamento padrão	O que fazer
Núcleo, versões menores (de manutenção e segurança)	Atualizam sozinhas desde o WordPress 3.7	Não desative
Núcleo, versões principais	Automáticas em instalações novas desde a 5.6; nas antigas, dependem de configuração	Ative se o site tem poucos plugins; se não, atualize manualmente na primeira semana
Plugins	Manuais, salvo correções críticas que o WordPress.org libera em segundo plano	Clique em “Ativar atualizações automáticas” na tela Plugins para os que você confia
Temas	Manuais	Mantenha só o tema ativo e um tema padrão de reserva; personalize com tema filho

A documentação oficial de atualização detalha essas regras. Em lojas e sites com muitos plugins, teste as versões principais antes num ambiente de testes, para que uma incompatibilidade não derrube o site em produção.

Antes de instalar qualquer plugin ou tema, confira:

• Origem: baixe só do diretório do WordPress.org ou do site oficial do desenvolvedor. Versões “nulled” (piratas) de plugins pagos são uma porta de entrada comum para malware.
• Manutenção: data da última atualização, compatibilidade com a versão atual do WordPress e se o autor responde no fórum de suporte.
• Troca de dono: popularidade não é garantia. Em 2017, o plugin Display Widgets foi vendido e passou a injetar spam nos sites até ser removido do repositório. Se um plugin muda de autor ou é fechado no WordPress.org, avalie substituí-lo.
• Necessidade: plugin desativado continua no servidor e pode ser explorado. O que não usa, exclua.

---

Usuários, senhas e verificação em duas etapas

Muitas invasões não exploram falha nenhuma: o atacante simplesmente entra com uma senha vazada, adivinhada ou roubada por phishing. A gestão de usuários fecha essa porta.

• Nada de usuário “admin”: é o primeiro nome que os robôs testam. Crie outro administrador, entre com ele e exclua o antigo, atribuindo os posts à conta nova.
• Senhas longas e únicas: use frases-senha e um gerenciador de senhas, nunca a mesma senha do e-mail ou do banco. O guia completo de senhas mostra como criar e guardar.
• Verificação em duas etapas (2FA): o WordPress não traz 2FA nativo. Ative por plugin, como o Two Factor, mantido pela comunidade, ou pelo módulo de login do seu plugin de segurança. Prefira aplicativo autenticador ou chave de acesso (passkey) a códigos por e-mail.
• Cadastro aberto só se precisar: em Configurações > Geral, desmarque “Qualquer pessoa pode se registrar” se o site não tem área de membros.
• Senhas de aplicativo: em Usuários > Perfil, revogue as que não reconhece. Elas permitem acesso à API sem passar pela tela de login.

Dê a cada pessoa o menor papel que resolve o trabalho dela:

Papel	O que pode fazer	Para quem
Administrador	Tudo: instalar plugins, mudar tema, criar usuários	Uma ou duas pessoas responsáveis pelo site
Editor	Publicar e editar o conteúdo de todos	Quem coordena o blog
Autor	Publicar e editar os próprios posts	Redatores fixos
Colaborador	Escrever, mas não publicar	Convidados e freelancers
Assinante	Só gerenciar o próprio perfil	Clientes e membros

Cuidado com e-mails “do WordPress”: golpes já copiaram o visual das mensagens oficiais para pedir uma suposta “atualização do banco de dados” e roubar as credenciais. Atualizações acontecem no painel do seu site, nunca por um link recebido por e-mail.

---

Como proteger o wp-admin e o wp-login

Os arquivos wp-login.php e xmlrpc.php recebem ataques de força bruta o tempo todo. A documentação oficial sobre força bruta recomenda filtrar esse tráfego no servidor ou num firewall de aplicação (WAF), antes que ele chegue ao PHP e consuma recursos.

1. Limite as tentativas de login. Todo plugin de segurança da tabela abaixo faz isso; um WAF na hospedagem ou na nuvem faz melhor, porque bloqueia antes.
2. Coloque um desafio contra robôs (CAPTCHA ou Cloudflare Turnstile) no login e nos formulários.
3. Restrinja o login por IP se a equipe trabalha de endereços fixos, com o bloco abaixo no arquivo .htaccess (servidores Apache ou LiteSpeed).
4. Não proteja a pasta wp-admin inteira com senha. A documentação oficial considera essa prática ultrapassada, porque quebra plugins que usam AJAX. Se quiser uma senha extra, aplique só ao wp-login.php.

<Files wp-login.php>
    Require ip 203.0.113.10 198.51.100.25
</Files>

Troque os números pelos IPs da sua equipe. Se a sua internet tem IP dinâmico, essa regra vai trancar você do lado de fora: nesse caso, fique com o limite de tentativas e o 2FA.

E renomear a URL de login? Plugins como o WPS Hide Login trocam o endereço /wp-login.php e reduzem o barulho dos robôs nos logs. Mas é só esconder a porta: não substitui senha forte, 2FA e limite de tentativas. Anote a nova URL: se esquecer, desativar o plugin pelo FTP devolve o endereço padrão.

---

Plugins de segurança: comparação honesta

Escolha um plugin principal. Dois firewalls ou dois scanners no mesmo site costumam conflitar e deixam tudo mais lento. Lembre também que o plugin roda dentro do WordPress: num ataque pesado, ele trabalha usando os recursos do próprio servidor que está sendo atacado.

Plugin	Ponto forte na versão grátis	Só na versão paga	Atenção
Wordfence Security	Firewall na aplicação, scanner de malware, 2FA, CAPTCHA e limite de login	Regras de firewall e assinaturas de malware em tempo real, bloqueio por país, log de auditoria	No plano grátis, regras e assinaturas chegam com 30 dias de atraso
Sucuri Security	Log de atividades, verificação de integridade dos arquivos, scan remoto, monitoramento de listas de bloqueio, recomendações de hardening	Firewall em nuvem (WAF) e limpeza de malware	O plugin grátis não tem firewall
Kadence Security (antigo Solid/iThemes Security)	2FA, proteção contra força bruta, detecção de mudança de arquivos, scan quatro vezes ao dia	reCAPTCHA, login sem senha, correção virtual de vulnerabilidades, log de usuários	Mudou de nome duas vezes; confira se a sua instalação recebe atualizações
All-In-One Security (AIOS)	Regras de firewall em PHP, bloqueio de login, 2FA, opções para XML-RPC	Scan de malware e monitoramento de disponibilidade	Muitas opções; ative uma de cada vez e teste
Jetpack Protect	Varredura diária de vulnerabilidades conhecidas em núcleo, plugins e temas (base WPScan)	Scan de malware e firewall	No plano grátis, avisa sobre falhas, mas não bloqueia ataques

Recursos conferidos nas páginas oficiais dos plugins no WordPress.org em outubro de 2026. Se você quer um pacote completo sem pagar, o Wordfence é o mais abrangente. Se prefere bloquear o tráfego antes que ele chegue ao servidor, um WAF em nuvem (Sucuri Firewall, Cloudflare) ou a proteção da hospedagem complementa melhor do que um segundo plugin.

---

Backup: a camada que salva quando o resto falha

Nenhuma proteção é perfeita. O backup é o que transforma uma invasão ou uma atualização desastrada em algumas horas de trabalho, em vez de semanas.

• Arquivos e banco de dados: um sem o outro não restaura o site.
• Fora do servidor: backup guardado na mesma hospedagem pode ser apagado ou criptografado junto com o site.
• Várias versões: malware pode ficar semanas escondido. Com uma única cópia, você restaura o site já infectado.
• Antes de mudanças grandes: faça uma cópia manual antes de atualizar o núcleo, trocar de tema ou instalar plugins pesados.
• Restauração testada: uma vez por trimestre, restaure num ambiente de testes e confira se tudo abre.

Plugins de backup resolvem, mas dependem do próprio WordPress estar funcionando. O Backup em nuvem da SAN guarda as cópias na AWS com criptografia, mantém até 30 versões, restaura em um clique e funciona com qualquer hospedagem.

---

HTTPS, permissões de arquivos e wp-config.php

Com o certificado SSL instalado, use HTTPS no site inteiro, não só no checkout: confira se os dois endereços em Configurações > Geral começam com https://. Sem isso, a senha de login pode trafegar sem criptografia.

As permissões abaixo seguem o guia oficial de hardening do WordPress:

Item	Permissão	Por quê
Pastas	755	Só o dono grava; o servidor lê e entra
Arquivos	644	Só o dono grava; o servidor lê
wp-config.php	400 ou 440	Guarda a senha do banco; só sua conta e o servidor leem
Qualquer item	Nunca 777	Permite que qualquer processo do servidor altere o arquivo

No wp-config.php, acrescente as linhas abaixo antes do comentário que pede para parar de editar. Elas desativam o editor de arquivos do painel, obrigam HTTPS no login e garantem as atualizações automáticas do núcleo:

// Remove o editor de temas e plugins do painel
define( 'DISALLOW_FILE_EDIT', true );

// Obriga HTTPS no login e na área administrativa
define( 'FORCE_SSL_ADMIN', true );

// Atualizações automáticas do núcleo: 'minor' (só as menores) ou true (todas)
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

Na instalação, troque o prefixo padrão das tabelas (wp_) por outro: o guia oficial observa que isso bloqueia parte das injeções de SQL que presumem o padrão. E mantenha as chaves de segurança (salts) preenchidas com valores únicos.

---

Desative o editor de arquivos e o XML-RPC que você não usa

A linha DISALLOW_FILE_EDIT do bloco anterior remove os menus de edição de código de temas e plugins. Ela não impede o envio de arquivos, mas fecha um caminho comum: quem rouba uma senha de administrador não consegue colar código malicioso direto pelo painel.

O XML-RPC (xmlrpc.php) é um protocolo antigo de publicação remota, hoje substituído quase sempre pela REST API, e segue como alvo frequente de força bruta. Se nenhum serviço seu depende dele, bloqueie o arquivo no .htaccess:

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

O filtro add_filter( 'xmlrpc_enabled', '__return_false' );, muito citado em tutoriais, desliga só os métodos que exigem login, como explica a referência oficial do hook. Pingbacks continuam ativos. O bloqueio no servidor é mais completo.

Antes de bloquear: a documentação oficial lembra que aplicativos móveis, o Jetpack e alguns logins únicos (SSO) podem depender do XML-RPC. Teste essas integrações logo depois da mudança.

---

Monitoramento e auditoria de segurança: checklist mensal

Segurança não se configura uma vez e pronto. Reserve meia hora por mês para esta auditoria:

1. Abra Painel > Atualizações e Ferramentas > Saúde do site. Não deve haver nada pendente nem alerta crítico.
2. Revise a lista de plugins: exclua os desativados e troque os que não recebem atualização há mais de um ano.
3. Filtre os usuários por Administrador e remova ex-funcionários, agências antigas e contas que você não reconhece.
4. Rode uma varredura completa de malware e de integridade dos arquivos do núcleo no seu plugin de segurança.
5. No Google Search Console, abra Segurança e ações manuais > Problemas de segurança.
6. Confira o log de logins e de atividades: tentativas em massa, acessos fora do horário, plugins instalados sem aviso.
7. Verifique a data de validade do certificado SSL e se o último backup foi concluído.

Para um roteiro mais técnico, com ferramentas de varredura externa, veja como analisar a segurança no WordPress.

---

Site invadido: o que fazer, passo a passo

Os sinais mais comuns são redirecionamentos para outros sites, aviso do Google de site perigoso, páginas de spam aparecendo na busca, administradores que ninguém criou e alerta da hospedagem sobre envio de spam. Se viu algum deles, siga esta ordem:

1. Guarde uma cópia do estado atual (arquivos e banco). Ela ajuda a descobrir por onde o invasor entrou.
2. Tire o site do ar com código HTTP 503 (manutenção) e avise a hospedagem. O suporte tem acesso aos logs do servidor e pode isolar a conta.
3. Troque todas as senhas: painel da hospedagem, FTP/SFTP, banco de dados (atualize o wp-config.php), todos os administradores e o e-mail ligado a eles. Revogue as senhas de aplicativo.
4. Gere novas chaves de segurança no gerador oficial do WordPress e substitua as do wp-config.php. Isso derruba todas as sessões abertas, inclusive a do invasor.
5. Limpe ou restaure. Reinstale o núcleo, os plugins e os temas a partir de cópias oficiais, procure arquivos PHP dentro de wp-content/uploads e remova usuários desconhecidos. Ou restaure um backup anterior à invasão. O passo a passo detalhado está no guia site com vírus ou malware: como remover e prevenir.
6. Feche a porta de entrada. Atualize tudo e corrija a causa (plugin vulnerável, senha vazada, tema pirata). Sem isso, o invasor volta pelo mesmo caminho.
7. Peça revisão ao Google se o site foi marcado como perigoso, pelo relatório Problemas de segurança do Search Console. Segundo o Google, a análise leva de alguns dias a algumas semanas.
8. Avalie a LGPD: se dados pessoais de clientes foram expostos, a empresa pode ter de comunicar o incidente à ANPD e aos titulares.

Na SAN: a Proteção Avançada acrescenta à hospedagem anti-malware e anti-phishing com inteligência artificial, uma camada no servidor que não depende só dos plugins instalados no seu WordPress.

---

Perguntas frequentes