CVE son las siglas de Common Vulnerabilities and Exposures y es el catálogo global de referencia de las vulnerabilidades de seguridad conocidas públicamente. El programa lo gestiona la MITRE Corporation desde 1999 y lo financia CISA, la agencia estadounidense de ciberseguridad. Cada vulnerabilidad recibe un identificador único con el formato CVE-AÑO-NÚMERO, como CVE-2021-44228 para Log4Shell, de manera que fabricantes, escáneres, investigadores y artículos de prensa se refieran todos al mismo fallo. Los identificadores los asignan varios cientos de CVE Numbering Authorities (CNA) en todo el mundo. La gravedad de un CVE se valora con el Common Vulnerability Scoring System (CVSS), una escala de 0.0 a 10.0 mantenida por FIRST: a partir de 9.0 la clasificación es Critical, de 7.0 a 8.9 High, de 4.0 a 6.9 Medium y por debajo Low. La dimensión del sistema ha crecido de forma espectacular: solo en 2024 se publicaron más de 40.000 CVE nuevos, y en el ecosistema de WordPress se divulgaron algo menos de 8.000 vulnerabilidades en 2024, cerca del 96 por ciento de ellas en plugins.
¿Qué significa CVE?
Antes de que existiera CVE, cada fabricante de seguridad describía las vulnerabilidades con sus propias palabras, y nadie podía saber si el desbordamiento de búfer de un aviso era el mismo fallo que el exploit remoto de otro. El programa Common Vulnerabilities and Exposures, iniciado por MITRE en 1999, resolvió esto con algo engañosamente sencillo: un nombre único por fallo. Un registro CVE contiene ese identificador, una descripción breve, referencias a avisos y parches, y los productos afectados.
El formato del identificador es CVE-AÑO-NÚMERO, donde el año es el de la asignación, no necesariamente el del descubrimiento, y el número tiene cuatro o más dígitos. La base de datos oficial vive en cve.org. Por encima se asienta la National Vulnerability Database (NVD), gestionada por el instituto de estándares estadounidense NIST, que enriquece los registros CVE con puntuaciones de gravedad, rangos de versiones afectadas y clasificaciones de debilidades. Cuando tu escáner de seguridad muestra datos de gravedad para un CVE, suelen venir de la NVD.
¿Cómo recibe una vulnerabilidad su identificador CVE?
Los identificadores CVE los reparten las CVE Numbering Authorities, CNA para abreviar. Son fabricantes de software, empresas de seguridad y organizaciones de investigación autorizadas a asignar identificadores para sus propios productos o para su ámbito de cobertura. La red ha crecido hasta varios cientos de CNA repartidas por decenas de países, y por eso quien encuentra un fallo en, pongamos, un producto de Cisco lo reporta directamente a Cisco, y Cisco asigna el CVE por sí misma.
El flujo habitual es este: alguien descubre una vulnerabilidad y la comunica a la CNA responsable, la CNA reserva un identificador CVE mientras se desarrolla la corrección y, una vez que sale el parche, el registro se publica junto con el aviso. Esa fase de reserva explica por qué a veces ves un identificador CVE mencionado públicamente sin ningún detalle todavía.
Para quien usa WordPress hay un detalle que conviene conocer: Wordfence, WPScan y Patchstack son todas CNA. La inmensa mayoría de los CVE de plugins y temas de WordPress los asigna una de esas tres, motivo por el cual sus bases de datos de vulnerabilidades son las fuentes más completas del ecosistema WordPress.
¿Qué es la puntuación CVSS?
Un nombre por sí solo no te dice lo grave que es un fallo. De eso se encarga el Common Vulnerability Scoring System, un estándar abierto mantenido por FIRST, la asociación mundial de equipos de respuesta a incidentes. CVSS condensa las características técnicas de una vulnerabilidad en una puntuación entre 0.0 y 10.0. La versión 2 apareció en 2007, la 3.0 en 2015, la revisión 3.1 en 2019 y la versión 4.0 en noviembre de 2023. En la práctica, la mayoría de las bases de datos y los avisos siguen hablando CVSS 3.1, y la adopción de 4.0 crece despacio.
Clasificaciones de gravedad CVSS, de None a Critical
| Clasificación | Puntuación CVSS | Significado habitual |
|---|---|---|
| None | 0.0 | Sin impacto |
| Low | 0.1 a 3.9 | Difícil de explotar o de impacto muy limitado |
| Medium | 4.0 a 6.9 | Impacto real, pero con condiciones previas como interacción de la persona usuaria o privilegios existentes |
| High | 7.0 a 8.9 | Impacto serio, a menudo exposición de datos o escalada de privilegios |
| Critical | 9.0 a 10.0 | Normalmente explotación remota sin autenticar con compromiso total |
El célebre 9.8 que ves en tantos avisos es la puntuación característica de una ejecución remota de código sin autenticar: alcanzable por red, sin privilegios y sin interacción de la persona usuaria. Un 10.0 perfecto además se escapa del componente vulnerable hacia otros sistemas, que es justo lo que logró Log4Shell.
¿Cómo se calcula una puntuación CVSS?
La puntuación base se deriva de un puñado de métricas que describen cómo se puede alcanzar un fallo y qué rompe. Por el lado de la explotabilidad: Attack Vector (red, adyacente, local, físico), Attack Complexity, Privileges Required y User Interaction. Por el lado del impacto: el efecto sobre Confidentiality, Integrity y Availability, más en la versión 3.1 la métrica Scope, que recoge si el daño se propaga a otros componentes. Las opciones concretas se registran en una cadena de vector compacta que encontrarás en cualquier entrada de la NVD:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
AV:N alcanzable a través de la red
AC:L baja complejidad de ataque
PR:N no requiere privilegios
UI:N no requiere interacción del usuario
S:U scope sin cambios
C:H/I:H/A:H impacto alto en confidencialidad, integridad, disponibilidad
Resultado: puntuación base 9.8, CriticalLo bueno del vector es que te cuenta más que el número. Un 7.5 con PR:N y un 7.5 con PR:H son animales muy distintos para tu modelo de amenazas, y leer el vector cuesta diez segundos en cuanto conoces las abreviaturas.
¿Qué novedades trae CVSS 4.0?
La versión 4.0 aborda las mayores críticas a la 3.1. La confusa métrica Scope desaparece, sustituida por valoraciones de impacto separadas para el sistema vulnerable y para los sistemas posteriores. User Interaction gana matices con variantes pasiva y activa, y una nueva métrica Attack Requirements recoge las condiciones que deben darse en el objetivo. Las antiguas métricas temporales se reformularon como métricas de amenaza, y el estándar nombra ahora de forma explícita sus variantes de puntuación: CVSS-B para la puntuación base pura, CVSS-BT con datos de amenaza y CVSS-BE con contexto de entorno. Conceptualmente todo esto es una mejora. En la práctica, el ecosistema se mueve despacio, así que cuenta con seguir leyendo vectores 3.1 durante años.
Por qué una puntuación CVSS alta no es automáticamente tu mayor riesgo
Esta es la verdad incómoda sobre CVSS: mide gravedad, no probabilidad. La inmensa mayoría de los CVE publicados no llegan a explotarse nunca en la práctica, mientras que algunos fallos de puntuación media reciben una paliza en cuestión de horas porque hay un exploit público y el objetivo está en todas partes. Dos conjuntos de datos ayudan a cerrar esa brecha. La puntuación EPSS, también de FIRST, estima la probabilidad de que una vulnerabilidad se explote en los próximos 30 días a partir de telemetría del mundo real. Y el catálogo KEV de CISA lista vulnerabilidades con explotación confirmada, que es la señal más fuerte de la que se dispone.
Una regla práctica de priorización para quien gestiona un sitio: parchea primero lo que esté en KEV o tenga una puntuación EPSS alta y viva en un componente expuesto a internet. Un 9.8 en un plugin que desactivaste el año pasado importa menos que un 7.5 en el plugin de formulario de contacto que puede alcanzar cualquier visita. La gravedad es contexto, y solo tú conoces el tuyo.
Los CVE en el ecosistema WordPress
El núcleo de WordPress es hoy un objetivo duro y supone bastante menos del uno por ciento de las vulnerabilidades divulgadas. La acción está en el ecosistema de extensiones: según Patchstack, en 2024 se divulgaron algo menos de 8.000 vulnerabilidades nuevas en el ecosistema WordPress, alrededor del 96 por ciento de ellas en plugins y la mayor parte del resto en temas. Las categorías más frecuentes son el cross-site scripting, el cross-site request forgery y el control de acceso roto. Nada de esto significa que WordPress sea inseguro: significa que la seguridad de tu sitio la deciden los plugins que instalas y la rapidez con la que los actualizas. Un plugin con 100.000 instalaciones y un fallo conocido sin parchear se convierte en objetivo de escaneo masivo en cuestión de días, a veces de horas.
Ejemplos famosos de CVE
- CVE-2014-0160, Heartbleed: filtración de memoria en OpenSSL que permitía a los atacantes leer claves privadas de los servidores. El fallo que dio a las vulnerabilidades logotipos y nombre propio.
- CVE-2017-0144, EternalBlue: el fallo en SMB que hay detrás de la oleada del ransomware WannaCry en 2017.
- CVE-2021-44228, Log4Shell: un CVSS 10.0 en la biblioteca de registro para Java Log4j. Una cadena manipulada en cualquier campo registrado llevaba a la ejecución remota de código, y medio internet registraba entradas de usuario.
- CVE-2023-4966, Citrix Bleed: fuga de tokens de sesión en Citrix NetScaler, explotada por grupos de ransomware contra miles de equipos.
¿Cómo usa InspectWP los datos CVE?
InspectWP detecta los plugins y temas de un sitio WordPress analizado y los coteja con datos de vulnerabilidades conocidas, de modo que un informe puede decirte que un componente instalado concreto tiene un CVE publicado, cómo de grave es y que hay una actualización disponible. Eso cierra la molesta brecha entre que un CVE exista en algún lugar de una base de datos y que tú te enteres de que afecta a uno de tus sitios. Combinado con informes automáticos programados, obtienes la versión práctica de la gestión de vulnerabilidades para WordPress: saber qué ejecutas, saber qué está roto y actualizar primero lo que importa.