CVE significa Common Vulnerabilities and Exposures e é o catálogo global de referência para vulnerabilidades de segurança publicamente conhecidas. O programa é mantido pela MITRE Corporation desde 1999 e é financiado pela agência de cibersegurança dos EUA, a CISA. Cada vulnerabilidade recebe um identificador único no formato CVE-ANO-NÚMERO, como CVE-2021-44228 para o Log4Shell, para que fabricantes, scanners, pesquisadores e artigos de notícias estejam todos falando da mesma falha. Os IDs são atribuídos por várias centenas de CVE Numbering Authorities (CNAs) no mundo todo. A gravidade de um CVE é classificada com o Common Vulnerability Scoring System (CVSS), uma escala de 0.0 a 10.0 mantida pelo FIRST: a partir de 9.0 a classificação é Critical, de 7.0 a 8.9 é High, de 4.0 a 6.9 Medium e abaixo disso Low. A dimensão do sistema cresceu de forma dramática: só em 2024 foram publicados mais de 40.000 novos CVEs e, no ecossistema WordPress, pouco menos de 8.000 vulnerabilidades foram divulgadas em 2024, cerca de 96 por cento delas em plugins.
O que significa CVE?
Antes de o CVE existir, cada fornecedor de segurança descrevia as vulnerabilidades com suas próprias palavras, e ninguém conseguia dizer se o buffer overflow de um aviso era o mesmo bug do remote exploit de outro. O programa Common Vulnerabilities and Exposures, iniciado pela MITRE em 1999, resolveu isso com algo enganosamente simples: um nome único por falha. Um registro CVE contém esse ID, uma descrição curta, referências a avisos e correções, e os produtos afetados.
O formato do ID é CVE-ANO-NÚMERO, em que o ano é o ano da atribuição, não necessariamente o da descoberta, e o número tem quatro ou mais dígitos. O banco de dados oficial fica em cve.org. Sobre ele fica o National Vulnerability Database (NVD), mantido pelo instituto de padrões dos EUA, o NIST, que enriquece os registros CVE com notas de gravidade, faixas de versões afetadas e classificações de fraqueza. Quando o seu scanner de segurança mostra dados de gravidade para um CVE, eles geralmente vêm do NVD.
Como uma vulnerabilidade ganha um ID CVE?
Os IDs CVE são distribuídos por CVE Numbering Authorities, CNAs para abreviar. São fabricantes de software, empresas de segurança e organizações de pesquisa autorizadas a atribuir IDs para os próprios produtos ou para a sua área de cobertura. A rede cresceu para várias centenas de CNAs espalhadas por dezenas de países, e é por isso que uma pessoa pesquisadora que encontra uma falha em um produto da Cisco, por exemplo, reporta diretamente à Cisco, e a Cisco atribui o CVE por conta própria.
O fluxo típico é assim: alguém descobre uma vulnerabilidade e a reporta ao CNA responsável, o CNA reserva um ID CVE enquanto a correção está sendo desenvolvida e, assim que o patch é lançado, o registro é publicado junto com o aviso. Essa fase de reserva explica por que às vezes você vê um ID CVE mencionado publicamente sem nenhum detalhe anexado ainda.
Para quem usa WordPress, há um detalhe que vale saber: Wordfence, WPScan e Patchstack são todos CNAs. A grande maioria dos CVEs de plugins e temas WordPress é atribuída por um desses três, o que também explica por que os bancos de dados de vulnerabilidades deles são as fontes mais completas para o ecossistema WordPress.
O que é o CVSS score?
Só o nome não diz o quão grave é uma falha. Esse é o trabalho do Common Vulnerability Scoring System, um padrão aberto mantido pelo FIRST, a associação global de times de resposta a incidentes. O CVSS condensa as características técnicas de uma vulnerabilidade em uma nota entre 0.0 e 10.0. A versão 2 apareceu em 2007, a versão 3.0 em 2015, o refinamento 3.1 em 2019 e a versão 4.0 em novembro de 2023. Na prática, a maioria dos bancos de dados e avisos ainda fala CVSS 3.1, com a adoção da 4.0 crescendo devagar.
Classificações de gravidade CVSS, de None a Critical
| Classificação | CVSS score | Significado típico |
|---|---|---|
| None | 0.0 | Sem impacto |
| Low | 0.1 a 3.9 | Difícil de explorar ou impacto muito limitado |
| Medium | 4.0 a 6.9 | Impacto real, mas com pré-condições como interação do usuário ou privilégios existentes |
| High | 7.0 a 8.9 | Impacto sério, muitas vezes exposição de dados ou escalonamento de privilégios |
| Critical | 9.0 a 10.0 | Tipicamente exploração remota não autenticada com comprometimento total |
O famigerado 9.8 que você vê em tantos avisos é a nota característica de uma execução remota de código não autenticada: alcançável pela rede, sem privilégios, sem interação do usuário. Um 10.0 perfeito ainda escapa do componente vulnerável para outros sistemas, que foi o que o Log4Shell conseguiu.
Como um CVSS score é calculado?
A nota base deriva de um punhado de métricas que descrevem como uma falha pode ser alcançada e o que ela quebra. Do lado da explorabilidade: Attack Vector (rede, adjacente, local, físico), Attack Complexity, Privileges Required e User Interaction. Do lado do impacto: o efeito sobre Confidentiality, Integrity e Availability, além da métrica Scope na versão 3.1, que captura se o dano atravessa para outros componentes. As escolhas individuais são registradas em uma vector string compacta que você encontra em toda entrada do NVD:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
AV:N alcançável pela rede
AC:L baixa complexidade de ataque
PR:N nenhum privilégio necessário
UI:N nenhuma interação do usuário necessária
S:U escopo inalterado
C:H/I:H/A:H alto impacto em confidencialidade, integridade, disponibilidade
Resultado: nota base 9.8, CriticalO bom do vetor é que ele te diz mais do que o número. Um 7.5 com PR:N e um 7.5 com PR:H são bichos muito diferentes para o seu modelo de ameaças, e ler o vetor leva dez segundos depois que você conhece as abreviações.
O que há de novo no CVSS 4.0?
A versão 4.0 responde às maiores críticas à 3.1. A confusa métrica Scope sumiu, substituída por classificações de impacto separadas para o sistema vulnerável e para sistemas subsequentes. A User Interaction agora é mais matizada, com variantes passiva e ativa, e uma nova métrica Attack Requirements captura condições que precisam existir no alvo. As antigas métricas temporais foram retrabalhadas em métricas de ameaça, e o padrão agora nomeia explicitamente suas variações de nota: CVSS-B para a nota base pura, CVSS-BT com dados de ameaça e CVSS-BE com contexto ambiental. Conceitualmente, tudo isso é uma melhoria. Na prática, o ecossistema se move devagar, então espere ler vetores 3.1 por mais alguns anos.
Por que um CVSS score alto não é automaticamente o seu maior risco
Eis a verdade incômoda sobre o CVSS: ele mede gravidade, não probabilidade. A esmagadora maioria dos CVEs publicados nunca é explorada de fato, enquanto algumas falhas com nota média são martelizadas em poucas horas porque existe exploit público e o alvo está em todo lugar. Dois conjuntos de dados ajudam a fechar essa lacuna. O EPSS score, também do FIRST, estima a probabilidade de uma vulnerabilidade ser explorada nos próximos 30 dias com base em telemetria do mundo real. E o catálogo KEV da CISA lista vulnerabilidades com exploração confirmada, que é o sinal mais forte disponível.
Uma regra prática de priorização para quem tem um site: corrija primeiro o que está no KEV ou tem EPSS score alto e fica em um componente exposto à internet. Um 9.8 em um plugin que você desativou no ano passado importa menos do que um 7.5 no plugin de formulário de contato que todo visitante consegue alcançar. Gravidade é contexto, e só você conhece o seu contexto.
CVEs no ecossistema WordPress
O núcleo do WordPress em si é um alvo difícil hoje em dia e responde por bem menos de um por cento das vulnerabilidades divulgadas. A ação está no ecossistema de extensões: segundo a Patchstack, pouco menos de 8.000 novas vulnerabilidades foram divulgadas no ecossistema WordPress em 2024, cerca de 96 por cento delas em plugins e a maior parte do restante em temas. As categorias mais comuns são cross-site scripting, cross-site request forgery e controle de acesso quebrado. Nada disso significa que o WordPress seja inseguro, significa que a segurança do seu site é decidida por quais plugins você instala e com que rapidez você os atualiza. Um plugin com 100.000 instalações e uma falha conhecida sem correção vira alvo de varredura em massa em poucos dias, às vezes horas.
Exemplos famosos de CVE
- CVE-2014-0160, Heartbleed: vazamento de memória no OpenSSL que permitia a atacantes ler chaves privadas de servidores. O bug que deu logos e nomes às vulnerabilidades.
- CVE-2017-0144, EternalBlue: a falha no SMB por trás da onda do ransomware WannaCry em 2017.
- CVE-2021-44228, Log4Shell: um CVSS 10.0 na biblioteca de logging Java Log4j. Uma string maliciosa em qualquer campo registrado levava à execução remota de código, e metade da internet registrava entrada de usuário em log.
- CVE-2023-4966, Citrix Bleed: vazamento de token de sessão no Citrix NetScaler, explorado por grupos de ransomware contra milhares de appliances.
Como o InspectWP usa dados de CVE?
O InspectWP detecta os plugins e temas de um site WordPress analisado e os cruza com dados conhecidos de vulnerabilidades, de modo que um relatório consegue te dizer que um componente instalado específico tem um CVE publicado, o quanto ele é grave e que existe uma atualização disponível. Isso fecha aquela lacuna irritante entre um CVE existir em algum lugar de um banco de dados e você de fato descobrir que ele diz respeito a um dos seus sites. Combinado com relatórios automáticos agendados, você obtém a versão prática do gerenciamento de vulnerabilidades para WordPress: saber o que você roda, saber o que está quebrado e atualizar primeiro o que importa.