CVSS (Common Vulnerability Scoring System)

CVSS score é o número de 0 a 10 que define a severidade de uma vulnerabilidade de segurança. O sistema chama-se Common Vulnerability Scoring System, é mantido pelo FIRST (Forum of Incident Response and Security Teams) e está atualmente na versão 4.0, embora o CVSS 3.1 ainda seja o mais usado em fluxos práticos. Cada CVE recebe um score CVSS que orienta times de segurança sobre o quão crítica é a falha e em que ordem corrigir.

O que é CVSS

O CVSS é um framework aberto de pontuação de vulnerabilidades. Em vez de cada empresa avaliar a gravidade do próprio jeito, o sistema padroniza uma fórmula com inputs claros: vetor de ataque, complexidade, privilégios necessários, interação do usuário, escopo, e impacto em confidencialidade, integridade e disponibilidade.

A fórmula gera um número único de 0 a 10, com casa decimal. Esse número entra no registro público de cada CVE na NVD (National Vulnerability Database), na MITRE e em catálogos de empresas de segurança como Patchstack, Wordfence e WPScan.

O que é CVSS, na prática, é um vocabulário comum. Quando alguém diz “essa CVE é 9.8”, todo mundo entende a mesma coisa: vulnerabilidade crítica, exploração remota fácil, impacto severo. Antes do CVSS, descrições verbais como “alta” ou “crítica” eram subjetivas e variavam entre fornecedores.

O sistema foi proposto em 2005 e atravessou três grandes revisões. CVSS 2.0, 3.0, 3.1 e agora 4.0 trouxeram refinamentos. O CVSS 4.0 incorporou métricas ambientais e de threat intelligence, mas a maioria dos catálogos públicos ainda usa CVSS 3.1, então é o número que você vê com mais frequência em CVEs WordPress.

Como CVSS calcula score de vulnerabilidades

O cálculo combina três grupos de métricas: Base, Temporal e Environmental. A base é a parte fixa, intrínseca à falha. Temporal reflete o estado atual da exploração (existe exploit público? Existe patch?). Environmental ajusta para o contexto do site (é servidor crítico? Tem dados sensíveis?).

As métricas base perguntam coisas como: o ataque pode ser remoto via rede ou exige acesso local? Precisa de autenticação? Precisa de interação do usuário? Quebra a confidencialidade dos dados? Quebra a integridade? Derruba o serviço? Cada resposta vira um peso na fórmula.

O score vulnerabilidade resultante cai em quatro faixas: 0.1-3.9 baixo, 4.0-6.9 médio, 7.0-8.9 alto, 9.0-10.0 crítico. Score 0 indica vulnerabilidade não explorável ou meramente teórica.

O cvss 3.1 também produz um vetor textual que descreve as escolhas feitas. Algo como “CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H” significa: ataque pela rede, complexidade baixa, sem privilégios, sem interação do usuário, escopo inalterado, impacto alto em confidencialidade, integridade e disponibilidade. É exatamente o perfil de uma vulnerabilidade crítica em plugin WordPress popular.

Categorias: baixo, médio, alto, crítico

Vulnerabilidades baixas (0.1-3.9) raramente entram em radar de operação. São casos como information disclosure mínimo, que exige acesso já autenticado ou condições raras. Corrigir continua sendo recomendado, mas não tem urgência.

Vulnerabilidades médias (4.0-6.9) merecem atenção em janelas de manutenção. Inclui CSRF parcial, XSS armazenado em áreas com pouca exposição, ou vulnerabilidades que exigem privilégios elevados. Em sites com tráfego, vale aplicar dentro de dias.

Vulnerabilidades altas (7.0-8.9) são prioridade. Boa parte das CVEs em plugins WordPress de uso amplo cai nessa faixa. SQL injection com privilégio limitado, XSS armazenado em áreas públicas, escalonamento de privilégios local. Corrigir em 24-48h é o padrão recomendado.

Vulnerabilidades críticas (9.0-10.0) exigem ação imediata. RCE (Remote Code Execution) sem autenticação, autenticação bypass, SQL injection unauthenticated. Em plugins com mais de 100 mil instalações, virou norma o disclosure coordenado: a CNA segura a publicação até a versão patched estar disponível.

Combine a leitura do score CVSS com o status da vulnerabilidade no catálogo da CISA: se a falha está no KEV (Known Exploited Vulnerabilities), urgência sobe um nível independente do CVSS, porque já há exploração ativa.

Como usar CVSS para priorizar correções

Ordene a fila de patches por CVSS, mas não use só o número. Combine com três fatores: o plugin está instalado nos seus sites? A vulnerabilidade é exploitable no fluxo real do site (público vs autenticado)? Já existe exploit público circulando?

Crítica + plugin instalado + exploit público = patch hoje. Alta + plugin instalado + sem exploit público = patch nesta semana. Média + plugin instalado = janela de manutenção mensal. Baixa = monitorar.

Para portfólios grandes, automatize. Plataformas como Patchstack, WPScan e MainWP cruzam o catálogo CVE com o inventário dos sites e apontam o que precisa ser corrigido em qual ordem. Sem automação, sites grandes ficam expostos por desorganização, não por falta de patch disponível.

O score CVSS também alimenta políticas de SLA interno. Equipe de segurança madura define: críticas em 24h, altas em 72h, médias em 30 dias. Esse é o backbone de um processo de patch management profissional. Conecte com CVE e com a CNA que reportou a falha para fechar a visão completa.

Para times que precisam dessa proteção sem manter aparato próprio, a FULL Services entrega o AIOS (All-In-One Security) já licenciado e configurado dentro da stack profissional WordPress, com integração ao catálogo CVE, alertas baseados em CVSS e firewall que bloqueia exploits conhecidos antes do patch chegar. É a forma de aplicar priorização CVSS em escala sem ler boletim de segurança um por um.