Tendências de publicação de CVE

Foram publicados 47 802 registos CVE em 2025, mais 20% do que no ano anterior. 2026 já chegou a 88 746, com meses ainda por decorrer.

O volume cresceu todos os anos desde o início do CVE Program, mas o ritmo de crescimento mudou acentuadamente em 2026. Use o gráfico acima para ver a tendência por mês, trimestre ou ano.

Nesta página. O gráfico e os números acima são estatísticas de CVE reconstruídas diariamente a partir do repositório cvelistV5 do CVE Program, a mesma fonte a partir da qual o CVE Program publica.

Abrangem o volume de publicação por gravidade CVSS, por organização atribuidora e por semana, mês, trimestre ou ano, juntamente com os registos críticos mais recentes. Para o detalhe de uma vulnerabilidade, siga qualquer identificador até cve.org.

Estão a acontecer três coisas ao mesmo tempo, e os registos publicados não permitem separá-las.

Há mais organizações que podem atribuir identificadores CVE, pelo que estão a ser registadas vulnerabilidades que antes nunca o eram. A descoberta de vulnerabilidades automatizada e assistida por IA aumentou o que cada investigador consegue encontrar. E o programa de enriquecimento da CISA preencheu retroativamente detalhes em registos mais antigos, o que altera os números históricos a posteriori.

O aumento do número de CVE não é, portanto, por si só, prova de que o software esteja a ficar menos seguro.

Uma CNA é uma organização autorizada a atribuir identificadores CVE e a publicar registos dentro do seu próprio âmbito, normalmente os seus próprios produtos. Neste conjunto de dados surgem 497 CNA.

Fornecedores, projetos open source, plataformas de bug bounty e CERT nacionais atuam todos como CNA. A maior aqui é mitre, com 39 586 registos. Como a mudança de processo de uma única CNA pode alterar visivelmente os totais, o gráfico permite filtrar uma organização de cada vez.

O CVSS pontua uma vulnerabilidade de 0.0 a 10.0 e agrupa-a em faixas: Baixa (0.1-3.9), Média (4.0-6.9), Alta (7.0-8.9) e Crítica (9.0-10.0).

A pontuação descreve características técnicas intrínsecas, como a forma de chegar à vulnerabilidade e o que esta compromete. Não é uma medida do risco que corre uma organização em particular.

18.0% dos registos publicados desde 2020 não têm pontuação CVSS nem nos dados da própria CNA nem no enriquecimento da CISA.

A pontuação não foi obrigatória durante a maior parte da história do CVE Program. A cobertura melhora fortemente a partir de 2023 e é hoje quase universal, pelo que a redução da faixa Desconhecida no gráfico reflete uma alteração na prática de reporte, não uma alteração nas próprias vulnerabilidades. Qualquer análise que ignore os registos sem pontuação subestimará os anos mais antigos.

Uma vulnerabilidade é uma falha em software. Uma CVE é um identificador público atribuído a uma ocorrência específica e divulgada de uma falha.

A maioria das vulnerabilidades nunca recebe uma CVE: são encontradas e corrigidas internamente ou ficam fora do âmbito de qualquer CNA. As contagens de CVE medem, portanto, a atividade de divulgação, não a verdadeira quantidade de falhas existentes.

Todos os números são construídos a partir do repositório oficial cvelistV5 do CVE Program, com base no instantâneo obtido a 31/10/2026 UTC.

Os registos são contabilizados pela data de publicação e não pelo ano no identificador CVE, uma vez que cerca de um quinto dos registos é publicado num ano diferente do indicado no identificador. Os registos rejeitados e retirados são excluídos.

Não por si só. Uma vulnerabilidade Crítica num componente que distribui mas nunca invoca pode ser menos urgente do que uma Média na sua API pública.

Uma verdadeira priorização precisa de saber se o componente afetado está presente no seu software, se o código vulnerável é alcançável e se a vulnerabilidade está a ser explorada. O CVSS não responde a nenhuma destas questões.

O CRA exige que os fabricantes tratem as vulnerabilidades ao longo de toda a vida útil suportada de um produto, notifiquem as vulnerabilidades ativamente exploradas à ENISA no prazo de 24 horas após tomarem conhecimento e mantenham a documentação técnica atualizada.

Estas obrigações crescem com o volume deste gráfico. Fazer manualmente a triagem de dezenas de milhares de novos registos por ano face ao seu próprio software não é realista, e é por isso que o CRA pressupõe, na prática, uma SBOM e um processo de correspondência automatizado.

Precisa de um inventário exato do que o seu software contém e, depois, de uma correspondência contínua desse inventário com o feed de CVE.

O CRACI gera uma SBOM a partir do seu build, compara-a com os novos registos CVE à medida que são publicados e mostra apenas os avisos de segurança que chegam ao código que realmente distribui — juntamente com a documentação que o CRA espera que mantenha.

Veja como funciona na prática o acompanhamento de vulnerabilidades.