CVE (Common Vulnerabilities and Exposures)

¿Qué es el Sistema CVE?

CVE (Common Vulnerabilities and Exposures) es el sistema internacional estándar para identificar, catalogar y referenciar de manera única las vulnerabilidades de seguridad en software, hardware y firmware.

Cada vulnerabilidad recibe un identificador único con formato CVE-YYYY-NNNNN, donde YYYY es el año de asignación y NNNNN es un número secuencial. Este sistema permite que investigadores, administradores y peritos forenses hablen el mismo idioma al referirse a vulnerabilidades específicas.

Historia y Gestión del Sistema

Origen y Evolución

• 1999: MITRE Corporation crea CVE con financiación del gobierno estadounidense
• 2005: Se establece el programa CNA (CVE Numbering Authorities)
• 2015: entra en vigor la nueva sintaxis del identificador, que deja de estar limitada a cuatro dígitos
• Hoy: MITRE sigue operando el programa como secretaría, con financiación federal estadounidense, mientras la asignación está descentralizada en la red de CNA
• 2026: el NVD registra 380.873 CVE (consulta de agosto de 2026); el recuento cambia a diario y se comprueba en vivo

CVE Numbering Authorities (CNA)

Un matiz que se malinterpreta a menudo: los CNA no tienen rangos numéricos públicos asignados. Reciben bloques de identificadores del programa CVE, pero el número no permite deducir qué organización lo asignó — para eso hay que consultar el propio registro en cve.org.

Anatomía de un CVE

Estructura del Identificador

CVE-2021-44228
│   │    │
│   │    └── Número secuencial único
│   └──────── Año de asignación (no de descubrimiento)
└────────────── Prefijo fijo "CVE"

Información Asociada

Cada CVE incluye:

Comprobar un CVE antes de citarlo

Que un identificador exista no acredita nada sobre lo que describe. Es el error más caro de esta ficha: dos «casos reales» de este mismo glosario citaban CVE-2026-1389 como una ejecución remota crítica en WP File Manager y CVE-2025-9847 como un fallo de WordPress. Los dos identificadores existen —y por eso pasaban cualquier comprobación de existencia—, pero el primero es un IDOR de gravedad media (CVSS 4.3) en el plugin Document Embedder y el segundo, una subida de ficheros sin restricción en un CMS inmobiliario que nada tiene que ver con WordPress.

curl -s "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-AAAA-NNNNN" \
  | jq '.vulnerabilities[0].cve | {id, published, descripcion: .descriptions[0].value}'

totalResults: 0 refuta que exista; cualquier otra cosa obliga a leer la descripción. En un informe pericial, un CVE mal atribuido es más grave que uno inventado: el inventado se cae solo, el real y mal descrito sobrevive a la primera comprobación de la contraparte y se derrumba en la segunda.

CVSS: Sistema de Puntuación

Common Vulnerability Scoring System

CVSS complementa CVE proporcionando una puntuación numérica (0.0-10.0) que indica la severidad de una vulnerabilidad.

Métricas CVSS v3.1

Base Metrics (permanentes)

• Attack Vector: Local, Adjacent, Network, Physical
• Attack Complexity: Low, High
• Privileges Required: None, Low, High
• User Interaction: None, Required
• Scope: Unchanged, Changed
• Impact: None, Low, High (para Confidentiality, Integrity, Availability)

Ejemplo de Cálculo

CVE-2021-44228 (Log4Shell):
AV:N (Network) / AC:L (Low) / PR:N (None) / UI:N (None) /
S:C (Changed) / C:H (High) / I:H (High) / A:H (High)
= CVSS Score: 10.0 (Critical)

CVE en Análisis Forense

Determinación de Vectores de Ataque

En mis análisis forenses, los CVE son fundamentales para:

1. Identificar la vulnerabilidad exacta explotada en el ataque
2. Establecer timeline de cuándo se hizo pública la vulnerabilidad
3. Determinar negligencia si no se aplicaron parches disponibles
4. Evaluar sofisticación del atacante basada en CVE explotados

Qué acredita el análisis de un CVE en un peritaje

El valor pericial no está en nombrar la vulnerabilidad, sino en fijar tres fechas y compararlas:

La ventana entre la segunda y la tercera es el dato que decide, y es medible con registros, no con opinión. Sobre esa ventana se pronuncia la autoridad aplicando los criterios de graduación del art. 83.2 RGPD: duración de la infracción, intencionalidad o negligencia y medidas técnicas aplicadas.

Las sanciones concretas que se hayan impuesto en supuestos así son públicas y se consultan una a una, con su número de expediente PS/NNNNN/AAAA, en el buscador de resoluciones de la AEPD.

Herramientas de Análisis CVE

Bases de Datos Oficiales

Herramientas de Scanning

Nessus Professional

• Escaneo automático de vulnerabilidades
• Mapping directo a CVE IDs
• Reportes forenses detallados

OpenVAS

• Scanner open source
• Base de datos NVT vinculada a CVE
• Exportación de evidencia

Nmap con NSE Scripts

nmap --script vuln target.com
## Detecta CVE específicos en servicios expuestos

APIs Programáticas

NVD Data Feeds API v2

curl "https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228"

CVE API de MITRE

curl "https://cveawg.mitre.org/api/cve/CVE-2021-44228"

Metodología Forense CVE

Fase 1: Identificación de la Vulnerabilidad

Fase 2: Timeline Reconstruction

Timeline real de Log4Shell (CVE-2021-44228):
2021-11-24: Alibaba Cloud notifica el fallo a Apache
2021-12-09: divulgación pública y primer exploit en circulación
2021-12-10: CVE-2021-44228 publicado; Apache libera 2.15.0
2021-12-14: 2.16.0 (la 2.15.0 resultó incompleta)
2021-12-28: 2.17.1 cierra la serie
[fecha del incidente]: se sitúa aquí la intrusión concreta con los logs del sistema

Fase 3: Análisis de Negligencia

Criterios de evaluación:

• ¿Cuánto tiempo pasó entre CVE público y ataque?
• ¿Estaba disponible un parche?
• ¿Se envió notificación de seguridad?
• ¿Es una vulnerabilidad crítica (CVSS >7.0)?
• ¿Había medidas de mitigación disponibles?

CVE en Contexto Legal Español

Marco Normativo

RGPD y Ley Orgánica 3/2018

• Art. 32: Seguridad del tratamiento
• Art. 83.4: es el tramo aplicable a la infracción del art. 32 — multas de hasta 10 millones de euros o el 2 % del volumen de negocio anual global. El tramo superior (20 M€ o 4 %) es el del art. 83.5, reservado a los principios y derechos de los interesados
• Criterio: Medidas técnicas adecuadas al estado de la técnica

Esquema Nacional de Seguridad (ENS)

• Real Decreto 311/2022
• Anexo II: Gestión de vulnerabilidades
• Control op.pl.2: Gestión de cambios y actualizaciones

Qué pesa cuando una vulnerabilidad sin parchear acaba en sanción

No hace falta jurisprudencia específica sobre CVE para saber qué se valora: está en el art. 83.2 del RGPD, que enumera los criterios de graduación de las multas. Tres son los que un informe pericial puede acreditar con registros:

• La duración de la infracción (letra a). Aquí es donde entra la fecha de publicación del CVE frente a la fecha de aplicación del parche: la ventana es medible y queda en los logs.
• La intencionalidad o negligencia (letra b). Un parche disponible y no aplicado durante meses se documenta con el registro de actualizaciones, no con una opinión.
• El grado de responsabilidad, «habida cuenta de las medidas técnicas u organizativas» aplicadas en virtud de los arts. 25 y 32 (letra d). Es decir: si existía o no un proceso de gestión de vulnerabilidades, no si una concreta se escapó.

El CVSS no aparece en esa lista. Es una herramienta de priorización técnica, útil para justificar por qué algo debió parchearse antes, pero el criterio jurídico es la diligencia acreditable, no la puntuación.

Casos de Uso Forense Específicos

1. Determinación de Autoría

Escenario: Identificar si un ataque fue oportunista o dirigido.

Análisis CVE:

• CVE recién publicado (0-7 días) → Atacante sofisticado
• CVE con exploit público (>30 días) → Posible script kiddie
• CVE crítico sin parchar (>6 meses) → Negligencia víctima

2. Cálculo de Daños

Factores CVE relevantes:

• CVSS Score: Impacto potencial máximo
• Tiempo de exposición: Días entre CVE público y ataque
• Disponibilidad de parche: ¿Era evitable?
• Complejidad de exploit: ¿Requería conocimiento avanzado?

3. Responsabilidad Civil

Elementos probatorios:

• CVE específico explotado
• Fecha de publicación del CVE
• Disponibilidad de parches o mitigaciones
• Notificaciones de seguridad recibidas
• Políticas internas de actualización

Tendencias CVE 2026

Dónde mirar las cifras

El recuento de CVE publicados cambia cada día y no tiene sentido congelarlo en una tabla. Las dos fuentes que lo publican con método declarado:

• Estadísticas del programa CVE — recuento oficial de identificadores asignados.
• NVD Dashboard — publicados, analizados y pendientes de análisis, que es el matiz que más se omite: un CVE publicado no está necesariamente puntuado todavía.

Nuevos Vectores

Supply Chain Attacks

• CVE en bibliotecas de terceros
• Dependencias comprometidas
• Package managers vulnerables

AI/ML Vulnerabilities

• Model poisoning
• Prompt injection
• Data exfiltration via models

Son categorías de vulnerabilidad, no CVE concretos: conviene no ponerles identificador si no se tiene uno delante. La referencia habitual para nombrarlas es el OWASP Top 10 for LLM Applications, que las clasifica sin necesidad de inventar un CVE.

Comprobar un CVE cuesta una petición: https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-AAAA-NNNNN. Si totalResults es 0, el identificador no existe — y la apariencia no sirve de guía: CVE-2024-12345, que parece un ejemplo de manual, es real.

Herramientas Forenses Especializadas

CVE Analysis Toolkit

Vulndb - Base de datos comercial con contexto forense

vulndb search --cve CVE-2021-44228 --format forensic

CVE Binary Tool - Análisis de binarios

cve-bin-tool /path/to/software --format json

Grype - Scanner de vulnerabilidades en contenedores

grype dir:/path/to/source --output json

Scripts de Automatización

Timeline Generator:

#!/usr/bin/env python3
def generate_cve_timeline(cve_id):
    nvd_data = fetch_nvd_data(cve_id)
    exploit_dates = check_exploit_db(cve_id)
    patch_dates = check_vendor_advisories(cve_id)
    
    timeline = [
        f"{nvd_data['published']}: CVE published",
        f"{patch_dates['released']}: Patch available",
        f"{exploit_dates['first_public']}: Public exploit",
        f"{incident_date}: Attack occurred"
    ]
    return timeline

Futuro del Sistema CVE

El formato de registro 5.0 ya está en uso

No es una previsión: el CVE Récord Format 5.0 es el que sirve hoy la API del programa —la misma cveawg.mitre.org que se usa en los ejemplos de arriba— con esquema JSON estructurado y lectura automatizable. Lo que sigue evolucionando es el enriquecimiento del registro: quién añade la puntuación, la categorización CWE y los datos de explotación conocida cuando el CNA no los aporta.

Integration con AI

• Automatic CVE detection: IA que identifica vulnerabilidades
• Impact prediction: Modelos que predicen exploitabilidad
• Forensic correlation: Linking automático CVE-incident

Conclusión

El sistema CVE constituye la piedra angular de la investigación forense de vulnerabilidades. Su comprensión profunda permite a peritos informáticos:

• Identificar vectors exactos de compromiso
• Establecer timelines precisos de ataques
• Demostrar negligencia técnica cuando corresponda
• Evaluar sofisticación de atacantes
• Cuantificar responsabilidades civiles y penales

Para abogados especializados en ciberseguridad, el dominio de la terminología CVE y su implicación legal es esencial para construir casos sólidos en litigios relacionados con:

• Violaciones de datos
• Negligencia técnica empresarial
• Reclamaciones de seguros cibernéticos
• Disputas contractuales sobre seguridad
• Responsabilidad por ataques a terceros

El análisis CVE ya no es opcional en la pericia informática moderna; es una competencia fundamental para determinar hechos técnicos con precisión forense.

Última actualización: 27 de agosto de 2026 Categoría: Técnico
Código: CVE-001