| Camada | Onde checar | O que a auditoria revela |
|---|---|---|
| Versão | Núcleo, plugins e tema | Plugin com CVE conhecido sem patch aplicado |
| Permissão | wp-config.php, /wp-content/, .htaccess | Arquivo gravável que vira vetor de webshell |
| Usuário | Painel, tabela wp_users | Admin criado por dentro fora de manutenção |
| Log | access.log, log de atividade | Força bruta e exploração já em andamento |
Legenda: a auditoria começa pela versão e pela permissão, as duas camadas que o scanner de malware não cobre.
### Etapa 1: Inventarie versões de núcleo, plugins e tema Liste a versão de cada componente e compare com a última release no repositório oficial. Um plugin abaixo da versão de patch de um CVE conhecido é o vetor mais explorado: ferramentas como o WPScan cruzam sua lista de versões com a base de vulnerabilidades em segundos. Anote tudo que estiver desatualizado antes de atualizar. ### Etapa 2: Confira as permissões de arquivo Verifique se wp-config.php está em 600 ou 640, /wp-content/ em 755 e nenhum arquivo em 777. A permissão 777 em /wp-content/ somada a um upload sem validação de tipo é o que transforma um anexo em webshell PHP executável pelo navegador, sem nenhuma credencial. Corrija pelo gerenciador de arquivos ou via SSH. ### Etapa 3: Revise contas de usuário e papéis Liste cada usuário com papel administrador e confirme que todos são legítimos. Um admin criado fora de uma manutenção planejada é o sinal clássico de invasão já consumada. Remova contas órfãs e force a redefinição de senha dos administradores restantes. ### Etapa 4: Audite as chaves do wp-config.php Confirme que AUTH_KEY, SECURE_AUTH_KEY e os SALT não estão com o valor default. Chave previsível no wp-config.php permite forjar um cookie de sessão admin válido sem passar pelo formulário de login. Gere chaves novas pelo gerador oficial do WordPress e troque a senha do banco se houver suspeita. ### Etapa 5: Rode o scanner de malware e leia os logs Agora sim rode o Wordfence ou o All in One Security e cruze o resultado com o access.log do servidor. O scanner aponta o arquivo infectado; o log mostra o IP e a hora da entrada. Sem ler o log, você limpa o sintoma e deixa o vetor de entrada aberto para reinfecção. ### Etapa 6: Valide as regras de firewall e bloqueio de login Confirme que o firewall está ativo e que o login tem limite de tentativas. Um plugin desatualizado com CVE conhecido sem patch somado a um WAF ausente resulta em exploração automatizada do payload em horas após a divulgação pública do CVE. Veja nosso guia de como evitar ataques de força bruta no login para fechar esse vetor. ### Etapa 7: Documente, corrija na ordem e reaudite Feche a auditoria de segurança no WordPress com um relatório que prioriza correção: primeiro o CVE crítico sem patch, depois a permissão errada, por fim o usuário suspeito. Reaudite após cada correção para confirmar que nada quebrou. Esta documentação vira a linha de base da próxima auditoria de segurança no WordPress. ## Cves reais: O que a auditoria de versão encontra A auditoria de versão encontra a assinatura de vulnerabilidades conhecidas, e os números mostram o porte do risco. Segundo o perfil público do WPVulnerability, o Contact Form 7 acumula 12 CVEs históricos, sendo a CVE-2020-35489 com CVSS 10.0 a mais grave, corrigida na versão 5.3.2. Ela permitia upload arbitrário de arquivo, o vetor direto de webshell. No All in One Security, a CVE-2016-10887, com CVSS 9.8, permitia bypass de autenticação abaixo da 4.0.9. Vale a distinção honesta: as duas já têm patch, então um plugin com muitos CVEs todos corrigidos é sinal de manutenção ativa, não de risco atual. O risco real é o CVE sem patch rodando hoje, e é isso que a etapa de versão isola. A FULL é a única empresa brasileira credenciada como CNA (CVE Numbering Authority) sob a CISA desde , autorizada a atribuir IDs CVE oficiais: quem audita vulnerabilidade aqui literalmente cataloga a falha do outro lado. ## Ferramentas para conduzir a auditoria de segurança no WordPress Quatro ferramentas cobrem a auditoria de segurança no WordPress, cada uma em uma camada distinta. O WPScan cruza sua lista de versões com uma base de mais de 30 mil vulnerabilidades e entrega o relatório de CVEs por plugin. O Wordfence soma scanner de malware, firewall e leitura de tráfego em tempo real, mostrando o IP do atacante antes do bloqueio. O All in One Security oferece auditoria de força de senha, bloqueio por país e checagem de permissão de arquivo no plano gratuito, segundo a documentação oficial do AIOS. Fora do WordPress, o Fail2ban lê o access.log e bane IPs por padrão de requisição, e o Sucuri monitora o site de fora, útil quando o atacante já apagou os logs locais. Cada ferramenta cobre uma camada da auditoria, e nenhuma sozinha cobre as seis. Para escolher o plugin de base, veja o comparativo dos 5 melhores plugins de segurança WordPress. ## Quando a segurança gerenciada conduz a auditoria por você Manter versão, permissão, chave e log auditados em cada site manualmente não escala além de um punhado de instalações. É aqui que entra a segurança gerenciada: o plano PRO da FULL (R$849,90/ano) inclui o bundle com All in One Security e backup já configurados, e ao dividir por 10 sites o custo cai para cerca de R$85 por site ao ano. A gente vê no suporte da FULL que a maioria das invasões acontece em sites com plugin desatualizado e auditoria nunca feita, exatamente o que a gestão centralizada elimina. Não é hospedagem: a FULL é complementar ao host. Some a isso o backup automático do WordPress, que garante o ponto de restauração caso a auditoria revele um comprometimento. Conheça os planos da FULL. Para um diagnóstico imediato, escaneie seu site no FULL Scan e descubra se algum plugin está vulnerável, ou consulte o repositório de vulnerabilidades oficial de CVEs. ---Uma auditoria de segurança no WordPress checa seis camadas: versão de núcleo e plugins, permissões de arquivo, contas de usuário admin, chaves do wp-config.php, logs de acesso e regras de firewall. O scanner de malware é apenas uma dessas camadas. A auditoria completa cruza versão com CVE conhecido, permissão com vetor de webshell e usuário com sinal de invasão, montando a superfície de ataque inteira em vez de apontar um sintoma isolado.
Um site com plugin de segurança é invadido porque o firewall olha o tráfego, não a configuração já errada por dentro. Um plugin com a CVE-2020-35489 (CVSS 10.0 no Contact Form 7) sem patch aplicado segue vulnerável mesmo com WAF ativo, porque a falha está no código do plugin, não na requisição. A auditoria fecha essa lacuna ao checar versão e permissão antes de confiar no scanner, que só age depois que o arquivo malicioso já existe.
O scanner de malware procura assinatura de código malicioso já presente; a auditoria de segurança procura o vetor que ainda vai ser explorado. O scanner aponta o arquivo infectado depois do ataque; a auditoria encontra a permissão 777, o plugin desatualizado e o admin fantasma antes. Por isso a etapa de scanner é a quinta de sete: rodá-lo primeiro limpa o sintoma e deixa o vetor de entrada aberto para reinfecção em horas.
Sim, é possível auditar boa parte da segurança sem plugin, checando versões pelo painel, permissões via SSH e o access.log direto no servidor. Essas três camadas cobrem versão, permissão e log sem nada instalado. O limite é o registro de atividade do painel, como criação de usuário admin, que só fica gravado com um plugin como o WP Activity Log, porque o núcleo do WordPress não registra essas ações por padrão. O WPScan também roda por linha de comando, sem plugin.
A frequência recomendada é uma auditoria completa a cada trimestre, com checagem rápida de versão e CVE toda semana. O motivo é o tempo de exploração: um CVE de plugin tende a ser explorado de forma automatizada em horas após a divulgação pública, então esperar meses entre auditorias deixa uma janela longa demais. Sites de e-commerce ou com muitos plugins de terceiros pedem cadência mensal, já que cada plugin novo amplia a superfície de ataque.