Verificar vulnerabilidades WordPress exige cruzar a versão instalada de cada plugin com bases de CVE oficiais. Segundo o WPScan (2025), 90% das falhas vêm de plugins, 6% de temas e 4% do core. A diferença que importa é risco atual sem patch versus CVE histórica já corrigida. Comece auditando plugins desatualizados hoje.

Verificar vulnerabilidades no WordPress é o processo de listar plugins, temas e o core instalados, comparar cada versão com bases públicas de CVE e isolar o que está sem correção. A maioria dos sites invadidos não cai por uma falha exótica: cai por um plugin parado em uma versão que já tem patch publicado há meses. No suporte da FULL, a gente vê esse padrão se repetir em sites que rodam um único plugin abandonado. Este guia mostra como fazer essa verificação de forma manual e com ferramentas, usando CVEs reais como referência. O hub de conteúdos de vulnerabilidades WordPress da FULL reúne o contexto completo do tema.

Primeiros passos: Visão geral da verificação

Verificar vulnerabilidades começa por um inventário: você precisa saber exatamente qual versão de cada plugin, tema e do core está rodando antes de comparar com qualquer base de CVE. Em um site WordPress médio com 25 plugins, basta um único componente desatualizado para abrir a porta. A tabela abaixo resume as três frentes de verificação e o que cada uma entrega como sinal concreto de risco.

Quem escreve aqui sobre vulnerabilidade literalmente cataloga vulnerabilidade: a FULL é a única empresa brasileira reconhecida como CVE Numbering Authority (CNA) sob a CISA desde maio de 2022, autorizada a atribuir IDs CVE oficiais. Esse contexto define o rigor deste tutorial.

O que é uma vulnerabilidade no WordPress

Uma vulnerabilidade no WordPress é uma falha de código em plugin, tema ou core que permite a um atacante executar ação não autorizada, como injetar script ou ler o banco de dados sem permissão. Cada falha confirmada recebe um identificador CVE e uma nota CVSS de 0 a 10 que mede a gravidade técnica daquela brecha.

Segundo o perfil público do WPVulnerability, o Elementor acumula 61 CVEs ao longo dos anos, das quais 3 críticas. Isso não significa que o Elementor seja inseguro hoje: a maioria absoluta já tem patch, e um histórico grande de CVEs corrigidas costuma indicar manutenção ativa e auditoria constante, não abandono. O que importa na verificação é separar o que está sem correção agora do que já foi resolvido em versões anteriores do plugin. Por isso, ler só o número total de CVEs leva a conclusão errada: o sinal de risco real é a CVE aberta sem patch cruzando a sua versão.

Como verificar vulnerabilidades WordPress passo a passo

O método manual mais confiável segue quatro passos e leva cerca de 20 minutos em um site com 20 a 30 plugins. Você levanta as versões instaladas, consulta as bases de CVE, confronta a versão afetada com a sua e aplica o patch. Cada passo abaixo é um H3 dentro deste procedimento; siga na ordem, porque pular o inventário leva a falso negativo.

Liste as versões instaladas com WP-CLI

Use o WP-CLI para extrair a versão exata de cada componente sem depender da interface. O comando wp plugin list --fields=name,version,update,status devolve, em segundos, a lista completa com a coluna update indicando quem tem versão mais nova disponível. Para o core, wp core version retorna a build em uso. Em um servidor com 30 plugins, isso substitui a checagem visual tela a tela e elimina o erro de ler a versão errada. Guarde a saída em um arquivo: ela é a base de comparação dos próximos passos.

Consulte as bases de CVE oficiais

Com a lista em mãos, consulte três bases complementares: o WPScan Vulnerability DB, o Patchstack e a NVD do NIST. O WPScan indexa mais de 51 mil vulnerabilidades específicas de WordPress e aceita busca por nome de plugin. O Patchstack catalogou, segundo seu relatório anual, mais de 64 mil vulnerabilidades do ecossistema. A NVD é a fonte primária do governo dos EUA para qualquer CVE. Cruze o nome do plugin nas três e anote cada CVE-ID retornado junto da versão afetada.

Confronte versão afetada com versão instalada

Aqui mora o erro mais comum: tratar toda CVE listada como risco atual. Cada CVE traz um campo de versão afetada, por exemplo “afeta menor que 5.3.2”. Se o seu Contact Form 7 já está em 5.9, a CVE-2020-35489 (CVSS 10.0, upload arbitrário de arquivo corrigido em 5.3.2) é histórica, não risco de hoje. O risco real é a interseção entre CVE sem patch e a sua versão instalada. Marque em vermelho só o que cruza essas duas condições ao mesmo tempo.

Aplique o patch e revalide

Atualize cada plugin que cruzou a verificação para a versão de patch indicada na CVE. Depois de atualizar, rode o inventário de novo e confirme que a coluna update está limpa. Para um passo a passo seguro de atualização sem quebrar o layout, consulte o guia de como atualizar corretamente os plugins do WordPress. Revalidar é o que fecha o ciclo: sem reexecutar o scan, você não tem prova de que a falha sumiu de fato.

Ferramentas para escanear vulnerabilidades automaticamente

Quatro ferramentas cobrem o escaneamento automático sem depender de checagem manual. O Wordfence faz scan de arquivos e compara com seu banco de assinaturas; o All in One Security reforça login e firewall; o WPScan roda via linha de comando contra a API de CVEs; e o FULL Scan analisa o site externamente sem instalar nada no servidor.

Segundo o perfil público do WPVulnerability, o próprio Wordfence acumula 34 CVEs históricas, todas corrigidas, com risco atual classificado como seguro: prova de que ferramenta de segurança bem mantida fecha as próprias brechas em vez de acumular dívida técnica. Para a configuração detalhada passo a passo, veja como configurar o Wordfence e o comparativo de plugins de segurança WordPress que cobre os trade-offs de cada opção.

Legenda: o relatório de scan mostra a versão afetada ao lado do patch disponível, exatamente o cruzamento que define o risco atual.

Erros comuns ao verificar vulnerabilidades

O erro que mais aparece no suporte da FULL é confundir volume histórico de CVE com risco atual. Um plugin com 61 CVEs corrigidas é mais seguro que um plugin sem CVE nenhum e sem update há dois anos, porque o segundo simplesmente nunca foi auditado por ninguém.

Outro erro é ignorar plugins abandonados sem CVE registrado: a ausência de CVE não é certificado de segurança, é só ausência de pesquisa. Um plugin parado há 18 meses no WordPress.org, mesmo sem CVE, é um risco silencioso que nenhum scanner aponta. O terceiro erro é escanear só o core e esquecer temas: a CVE-2023-48777 do Elementor (CVSS 9.9, corrigida em 3.18.2) mostra que add-ons de página carregam falhas críticas tão graves quanto o core, e por isso entram no mesmo inventário de versões.

Audite a sua base com o plano certo

Verificar um site manualmente é viável; verificar dez ou cinquenta sob gestão de agência, não. O plano PRO da FULL, por R$849,90 ao ano, inclui as ferramentas de segurança no bundle de 16 plugins, com a camada Wordfence e o monitoramento contínuo de CVE já ativados desde a instalação.

Diluído pela cobertura de até 10 sites, isso sai por cerca de R$85 por site ao ano, contra a soma das licenças avulsas de cada plugin de segurança comprado separado, que individualmente já passariam desse valor. Para quem gerencia carteira, a economia real não está só no preço: está em transformar auditoria pontual em rotina automática que roda sem depender de lembrete manual. Conheça as opções em FULL.services/planos e ative a camada gerenciada sem montar o stack peça por peça.

Como validar que a verificação foi completa

A verificação está completa quando três condições batem ao mesmo tempo: inventário fechado, scan rodado nas três bases de CVE e zero falha sem patch cruzando a versão instalada de cada plugin ativo no site. Sem as três, o diagnóstico fica incompleto.

Um site WordPress só pode se declarar verificado quando o relatório do scanner não retorna nenhuma falha aberta nos plugins ativos, nem alerta de plugin abandonado. Para uma auditoria mais profunda, com checagem de permissões de arquivo e hardening do servidor, siga o roteiro de auditoria completa de segurança no WordPress. Rode o FULL Scan gratuito para confirmar externamente o resultado e cruze com o repositório de vulnerabilidades da FULL, alimentado por dados oficiais de CVE.

Perguntas frequentes sobre verificação de vulnerabilidades WordPress

Próximos passos para blindar seu WordPress

Verificar vulnerabilidades WordPress deixa de ser tarefa pontual quando vira rotina: inventário de versões, scan nas bases de CVE, cruzamento com a versão instalada e patch imediato do que estiver sem correção. O ponto que separa um diagnóstico amador de um profissional é distinguir CVE histórica corrigida de exposição ativa, e nunca tratar plugin sem CVE como plugin seguro. Para aprofundar, o guia de segurança para WordPress reúne o passo a passo de hardening, e o guia de segurança WordPress cobre o contexto além das CVEs. Para continuar aprendendo, o FULL Academy reúne todos os tutoriais e guias em um só lugar.