CVSS 3.1 y 4.0: cómo se calcula la severidad de una vulnerabilidad

CVSS (Common Vulnerability Scoring System) es el estándar global para asignar un número del 0 al 10 a cualquier vulnerabilidad. Lo usan NVD (National Vulnerability Database), los CERTs, los equipos de product security de todos los grandes vendors, los pentesters al redactar informes, los programas de bug bounty para decidir pagos y los equipos defensivos para priorizar parches. Conocer CVSS bien no es opcional para nadie que trabaje en seguridad: es el lenguaje común con el que se comunica urgencia.

Esta lección cubre CVSS 3.1 (la versión dominante en 2026) y las novedades de CVSS 4.0 (publicada noviembre 2023, aún en adopción). Aprenderás qué significa cada métrica, cómo construir un vector string, cómo calcular el score, cuándo usar las métricas temporal y ambiental, y los errores típicos que llevan a scores inflados o deflactados en informes.

Es la primera lección metodológica del bloque reporting-y-gobernanza de la Tanda 5, continuación natural de la lección de metodología de pentesting de la Tanda 3.

CVSS es un estándar público, usable por todos. Esta lección te enseña a aplicarlo correctamente a tus propios hallazgos en labs o auditorías autorizadas.

Las tres familias de métricas#

CVSS tiene tres tipos de métricas:

• Base: características intrínsecas de la vulnerabilidad. No cambian con el tiempo. Son las que aparecen en el CVE.
• Temporal: cambian con el tiempo (madurez del exploit, nivel de remediación, confianza en el reporte).
• Environmental: dependen del entorno específico (importancia de CIA en tu caso, versiones afectadas en tu infraestructura).

El score más usado y publicado es el base score. Temporal y environmental refinan en escenarios específicos.

Métricas Base#

Attack Vector (AV)#

Dónde tiene que estar el atacante:

• Network (N): remoto por internet. Peor.
• Adjacent (A): misma red local (LAN, Bluetooth, WiFi).
• Local (L): acceso al equipo (sesión activa, SSH).
• Physical (P): tocando el hardware.

Attack Complexity (AC)#

Dificultad del ataque:

• Low (L): directo, repetible.
• High (H): requiere condiciones específicas (race, MitM, config especial).

Privileges Required (PR)#

Qué privilegios necesita el atacante antes del ataque:

• None (N): sin autenticar.
• Low (L): usuario normal.
• High (H): admin.

User Interaction (UI)#

Si la víctima tiene que hacer algo:

• None (N): sin interacción.
• Required (R): click, abrir archivo, etc.

Scope (S)#

Si el impacto cruza límite de autoridad:

• Unchanged (U): afecta a lo que el atacante controlaba.
• Changed (C): compromete componente distinto (XSS que afecta a otros usuarios, container escape a host).

Confidentiality, Integrity, Availability (C, I, A)#

Impacto en cada una:

• High (H): pérdida total.
• Low (L): pérdida limitada.
• None (N): sin impacto.

El vector string#

Se escribe como CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Ejemplo:

• Log4Shell (CVE-2021-44228): AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H → CVSS 10.0 (máximo).
• Heartbleed (CVE-2014-0160): AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N → 7.5.
• Spectre (CVE-2017-5753): AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N → 5.6.

El score sale de una fórmula matemática aplicada a las métricas. Calculadoras oficiales: FIRST.org, NVD, inSTALLDown.

Rangos de severidad#

En informes se suele reportar score + severidad + vector string completo.

Ejemplos guiados#

SQLi no autenticada en API pública#

• AV:N (remoto), AC:L (directa), PR:N (sin login), UI:N (sin interacción), S:U (misma BD), C:H (datos filtrados), I:H (puede modificar), A:L (puede caer BD por mal query).
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L → 9.4 Critical.

XSS reflected que requiere click#

• AV:N, AC:L, PR:N, UI:R (requiere click), S:C (afecta a otros usuarios), C:L (session token), I:L, A:N.
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N → 6.1 Medium.

LPE local con SUID#

• AV:L (necesita sesión), AC:L, PR:L (usuario normal), UI:N, S:U, C:H, I:H, A:H.
• Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H → 7.8 High.

Métricas temporales#

Ajustan según estado del ecosistema:

• Exploit Code Maturity (E): Not Defined / Unproven / Proof-of-Concept / Functional / High.
• Remediation Level (RL): Not Defined / Official Fix / Temporary Fix / Workaround / Unavailable.
• Report Confidence (RC): Not Defined / Unknown / Reasonable / Confirmed.

Un CVE recién publicado con PoC público pero sin exploit funcional ni parche tiene score temporal más bajo que uno con exploit funcional disponible pero sin parche. Con parche oficial, el temporal baja.

Métricas ambientales#

• Confidentiality / Integrity / Availability Requirements (CR/IR/AR): importancia específica en tu entorno. Low / Medium / High.
• Modified Base Metrics: ajustes a las base según tu entorno (p. ej. MAV:N → A si tu servicio está solo en LAN).

Ejemplo: un CVE con AV:N en base, pero tu servicio solo escucha en LAN → MAV:A en environmental, bajando el score.

CVSS 4.0: novedades#

Publicada en noviembre 2023. Cambios clave:

• Supplemental metrics: nuevas métricas opcionales (Safety, Automatable, Recovery, Value Density, Vulnerability Response Effort, Provider Urgency).
• Nomenclatura distinta: CVSS-B (base), CVSS-BT (base + threat), CVSS-BE (base + environmental), CVSS-BTE (todo).
• Threat metrics reemplazan a Temporal: Exploit Maturity.
• Attack Requirements (AT): nueva métrica base que separa condiciones del atacante (antes mezcladas en AC).
• Mejora de granularidad: scores más distribuidos, menos clustering en 9-10.

En 2026 muchos CVE siguen con CVSS 3.1; NVD y CISA están migrando. Ambas versiones coexistirán varios años.

Calculando paso a paso en labs#

Para fijar el procedimiento de puntuación, el flujo canónico frente a un hallazgo nuevo:

Paso 1 — AV: ¿el atacante necesita estar en la máquina? En la LAN? En Internet?

Paso 2 — AC: ¿basta con lanzar el exploit o hay ventanas, condiciones especiales?

Paso 3 — PR: ¿necesita credenciales previas? ¿Admin?

Paso 4 — UI: ¿basta con enviar el payload o hay que convencer a alguien?

Paso 5 — S: ¿el impacto se queda en el componente o cruza a otro?

Paso 6 — CIA: ¿qué pierde el sistema en cada eje?

Un error frecuente de novato es mezclar scope con impacto. Scope C:changed no significa «afecta a muchas cosas»: significa que la vulnerabilidad en el componente A permite afectar al componente B que opera bajo autoridad distinta (XSS en una app afecta a cookies del navegador → scope changed; SQL injection que lee datos de la BD de la misma app → scope unchanged).

Comparación con EPSS#

EPSS (Exploit Prediction Scoring System) es complementario a CVSS, publicado también por FIRST.org. Modelo estadístico entrenado con datos históricos que estima la probabilidad (0-1) de que un CVE sea explotado en los próximos 30 días. Ejemplos:

• Log4Shell en primera semana: EPSS 0.98 (casi seguro que será explotado).
• Un CVE 9.8 teórico sin PoC público ni exploit observado: EPSS 0.02.

Usar los dos:

• CVSS alto + EPSS alto → parchea ya.
• CVSS alto + EPSS bajo → importante pero puede esperar al ciclo normal.
• CVSS medio + EPSS alto → peligroso por explotación real.

CISA recomienda esta combinación en su framework Stakeholder-Specific Vulnerability Categorization (SSVC) para programas de gestión de vulnerabilidades maduros.

Casos famosos#

Observar estos casos ayuda a calibrar la intuición al puntuar hallazgos nuevos.

Errores comunes#

• Inflar score: poner Critical a hallazgos que son Medium para asustar cliente. Daña credibilidad.
• Deflatar score: subestimar Critical reales por miedo a alarma. Peor.
• No documentar el vector string: solo poner número sin justificar.
• Confundir scope: S:C es solo cuando cruza límite de autoridad, no «afecta a más cosas».
• Reportar temporal sin contexto: un base 9.8 con parche oficial debería reportarse con temporal rebajado si aplica.
• Olvidar environmental en casos específicos: un CVE 9.8 remoto importa menos si tu servicio no está expuesto.

Preguntas frecuentes#

¿CVSS determina si parchear?#

No por sí solo. CVSS es uno de los inputs de una decisión de priorización que debería considerar también: exposición de tu infraestructura, explotabilidad real, presencia del exploit público, tus controles compensatorios, impacto de negocio.

¿Hay alternativas a CVSS?#

• EPSS (Exploit Prediction Scoring System): probabilidad de que un CVE sea explotado en 30 días. Muy útil combinado con CVSS.
• SSVC (Stakeholder-Specific Vulnerability Categorization): árbol de decisión en vez de número. CISA lo recomienda.
• VPR (Tenable), Qualys VMDR: scoring propietario que mezcla CVSS + threat intel.

En 2026 la tendencia es CVSS + EPSS + context para decisiones de parcheo.

¿Un CVE con CVSS 9.8 debe parchearse en 24 horas?#

Depende de la exposición. Un 9.8 de un software no desplegado en tu organización es 0 de prioridad. Un 7.5 de algo en tu perímetro expuesto es prioridad crítica. Siempre contextualizar.

¿Las empresas inventan sus propias métricas?#

Microsoft tiene su propia severity (Critical/Important/Moderate/Low). Apple similar. Es un atajo para su propio producto, suele mapear a CVSS pero no exactamente. Para interoperabilidad, CVSS sigue siendo la referencia.

¿Dónde practico?#

El laboratorio ad-junior de whoami-labs incluye cinco CVEs reales a los que tienes que asignar vector CVSS y justificar. Comparas con el score oficial del NVD para ver dónde acertaste y dónde estabas off.

¿Un reporte de bug bounty se paga por CVSS?#

Depende del programa. Algunos pagan por tier (critical/high/med/low) basados en CVSS, otros tienen rúbrica propia (HackerOne severity, Bugcrowd VRT). En general, un CVSS 9+ bien justificado paga como «critical» en la mayoría. Lo importante es presentar el vector string con justificación clara en el reporte.

¿Por qué un CVSS no refleja el impacto real?#

Porque CVSS no sabe de tu negocio: un 9.8 de un servicio no crítico es menos urgente que un 7 en tu core. Y no modela el valor de los datos filtrados. Por eso en reporting responsable se añade contexto del negocio junto al número CVSS.

¿Cómo justifico mi CVSS si el cliente discute?#

Vector string público + racional por métrica + referencia a FIRST specification. Los argumentos subjetivos («me parece crítico») se pierden; la rúbrica estándar con cada métrica motivada defiende cualquier score.

¿CVSS 4.0 incluye privacy impact?#

No directamente, pero las métricas supplemental incluyen Safety y Value Density que cubren parte. Para privacy específico, GDPR y marcos regulatorios tienen scoring propio. CVSS sigue siendo técnico.

Resumen#

• CVSS 3.1 sigue siendo dominante en 2026; CVSS 4.0 se adopta progresivamente.
• Base metrics: AV, AC, PR, UI, S, C, I, A. Determinan el score principal.
• Vector string como CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H es obligatorio junto al score.
• Rango: Critical (9-10), High (7-8.9), Medium (4-6.9), Low (0.1-3.9).
• Temporal ajusta por exploit maturity y remediation level.
• Environmental ajusta por tu entorno específico.
• Combinarlo con EPSS y contexto de exposición para priorizar parcheo real.

Un profesional de seguridad calibrado en CVSS entrega informes consistentes, defiende sus hallazgos ante clientes técnicos y no técnicos, y contribuye al ecosistema público reportando vectores que otros pueden revisar. Aprenderlo bien es inversión de una semana que rinde durante años en cualquier rol de ciberseguridad, desde el pentester que entrega informes hasta el analista de vulnerabilidad que prioriza parches corporativos cada día.

Esos dos roles ven CVSS desde ángulos opuestos (producción de hallazgos frente a consumo de alerts) pero igualmente importantes para la organización, y manejar la métrica con soltura mejora drásticamente la comunicación con el otro lado del puente defensivo.

Fuentes y lecturas recomendadas#

• FIRST CVSS Calculator
• CVSS v4.0 Specification
• EPSS
• CISA SSVC