Cuando leés que una falla "tiene 9,8" y decidís si trabajás el fin de semana, estás confiando en un número. Esta nota es sobre quién calculó ese número, y la respuesta cambió en abril de 2026.
El dato corto: de las altas del catálogo de fallas explotadas de CISA cuyos CVE se publicaron desde el 15 de abril de 2026, solo el 28,8% tiene un puntaje calculado por NVD. De las publicadas antes de esa fecha, lo tiene el 66,7%. Son 140 fichas medidas una por una el 26 de octubre.
Lo que no es: esto no es un incumplimiento ni un descuido. Es la política anunciada, y conviene decirlo antes que nada porque es fácil contarlo al revés. El mismo comunicado de NIST que puso a los CVE del catálogo KEV como máxima prioridad de enriquecimiento anunció también que NVD dejaría de poner su propio puntaje cuando el CNA ya puso uno.
Lo que sí es, y por eso vale la nota: el número que usás para priorizar lo produce, cada vez más, la parte interesada. Y la ficha sigue diciendo "Analyzed", que suena a que alguien lo revisó.
Qué cambió en abril de 2026, en palabras de NIST
El comunicado del 15 de abril de 2026 tiene dos partes que conviene no mezclar, porque juntas explican todo lo demás.
Una fija prioridades de enriquecimiento, y ahí el catálogo de fallas explotadas va primero: dice que la meta es enriquecer esas fichas dentro de 1 día hábil desde su recepción —"within one business day of receipt"— y que "el atraso no incluye ningún CVE del catálogo KEV". Conviene leer eso como lo que dice: una meta, no un compromiso contractual, y el reloj arranca cuando NVD recibe el CVE, no cuando CISA lo suma al catálogo.
La otra se titula "Streamlining Severity Scores" y dice, textual: "Hasta ahora, NIST ha provisto su propio puntaje de severidad para todos los CVE enviados, incluso si la Autoridad de Numeración de CVE que lo envió ya había provisto un puntaje de severidad. En adelante, no proveeremos de forma rutinaria un puntaje de severidad separado para esos CVE."
Las dos cosas son del mismo documento, que lleva poco más de 6 meses en vigencia. Por eso que una falla del catálogo no tenga puntaje de NVD no prueba que NVD la haya desatendido: prueba que el CNA ya la había puntuado.
Y hay evidencia directa de que el enriquecimiento sí ocurre: de las 140 fichas, 139 están en estado "Analyzed" —que es la etiqueta con la que NVD marca su proceso de enriquecimiento como completo— y 139 tienen declaraciones de aplicabilidad CPE, que es trabajo propio de NVD. La única excepción es CVE-2026-110447, la falla de Collabora que cubrimos el 24 de octubre, en estado "Deferred" —y que había entrado al catálogo 3 días antes de esta medición, así que no sirve como ejemplo de nada sistemático.
Por qué NVD puntuó 17 fichas y se abstuvo en 42
Acá está lo que más me sorprendió al medirlo: la regla es casi determinista.
De las 59 fichas cuyos CVE se publicaron desde el 15 de abril, NVD agregó su propio puntaje en 17. En 15 de esos 17 no existía ningún puntaje en la escala 3.x: tenían solamente un CVSS 4.0 del tercero. O sea que NVD no apareció a dar una segunda opinión, apareció a llenar el casillero del 3.1 que faltaba.
Y de las 42 en las que se abstuvo, en 41 ya había un 3.x de un tercero. Exactamente lo anunciado.
Hay un detalle que se desprende de eso y que vale para leer cualquier ficha: en las 140 que medí, NVD no emitió ni un solo puntaje en CVSS 4.0. Cero. Cuando puntúa, puntúa en 3.1. Así que cuando ves dos números distintos en una misma ficha, muchas veces no son dos mediciones del mismo hecho sino dos escalas diferentes, y compararlas no significa nada. Es el mismo punto que ya apareció con los dos puntajes de F5 y Arista y con los puntajes del kernel de Linux.
Quién puso el número cuando no lo puso NVD
De las 140 fichas, 69 no tienen puntaje de NVD. En 56 lo puso el CNA de la ficha, que es lo que uno espera: el fabricante. Pero en 13 el único puntaje lo puso CISA, y eso merece separarse en dos mecanismos distintos porque no son lo mismo.
En 4 casos, CISA es directamente el CNA del registro y además lo puntúa. Son las cuatro fallas de Plex Media Server del 20 de octubre: el identificador de fuente de esas fichas resuelve, contra la API de fuentes de NVD, a "Cybersecurity and Infrastructure Security Agency (CISA) U.S. Civilian Government".
Acá me corrijo a mí mismo. Cuando cubrí esas cuatro fallas de Plex el 22 de octubre escribí que "los cuatro puntajes los puso el CNA". Es literalmente cierto —CISA es el CNA de esos registros— pero cualquier lector entendió "Plex", y no fue Plex: los puso CISA. La frase no era falsa, era engañosa, y la precisión correcta es esta.
En los otros 9 casos el fabricante sí es el CNA, pero no publica ningún CVSS, y entonces lo suple CISA-ADP, que es un publicador de datos autorizado. Pasa con dos fallas de Apple, tres de Google —dos de ellas de Chrome—, dos de SonicWall, una de WordPress cuyo CNA es HackerOne y una de Synacor cuyo CNA es MITRE.
Queda una ironía que conviene notar sin exagerarla: en esas 13 fichas, la agencia que dice "esto se está explotando, parchen antes de tal fecha" es también la que pone el número de gravedad. No hay nada impropio en eso —alguien tiene que poner un número y CISA tiene el contexto—, pero no es una segunda opinión independiente, y ahí está el punto de toda la nota.
¿A quién le cambia algo que NVD ya no calcule el puntaje?
Si priorizás parches por el número, te cambia el procedimiento. El 9,8 de una ficha reciente probablemente lo calculó el fabricante del producto, sin que nadie externo lo haya revisado. Eso no lo vuelve falso; lo vuelve una sola fuente.
Si tenés que justificar una ventana de mantenimiento ante un jefe o un cliente, te conviene saber de dónde sale el número que estás citando, porque la pregunta "¿quién dice que es 9,8?" ahora tiene una respuesta más interesante que "NVD". Cómo se contestan esas preguntas por escrito está en cómo responder un cuestionario de seguridad de un cliente.
Si comparás puntajes entre productos para decidir qué atender primero, el riesgo es concreto: podés estar comparando un 4.0 del fabricante A contra un 3.1 de NVD del producto B. No son la misma vara.
Si administrás pocos equipos y no vivís de esto, la versión corta alcanza: el número orienta, no decide. Lo que decide es si el producto está expuesto y si hay explotación confirmada, que es el criterio que usa el propio catálogo. El encuadre general está en la guía de ciberseguridad para PyMEs de LATAM, y los términos en el glosario.
¿Quién puede ignorar quién calculó el puntaje CVSS?
Quien no use el puntaje para decidir. Si tu criterio es "está en el catálogo de explotadas y lo tengo instalado, entonces lo parcheo", el número es decorativo y esta nota no te cambia nada. Es, además, un criterio razonable.
Y quien trabaje con fallas viejas: las fichas publicadas hace más de 6 meses, antes del cambio, tienen puntaje de NVD en dos de cada tres casos, así que ahí la foto es la de siempre.
Lo que no corresponde concluir es que NVD dejó de trabajar, ni que los CVE del catálogo quedaron abandonados. Los datos dicen lo contrario: 139 de 140 fichas enriquecidas y con aplicabilidad CPE puesta por NVD.
¿Cómo sé quién calculó el puntaje de un CVE?
Está en la ficha, y se puede ver sin herramientas:
- En la web de NVD, la sección de métricas CVSS muestra la fuente de cada puntaje. Si dice
nvd@nist.gov, lo calculó NVD. Si dice el correo del fabricante —psirt@arista.com,security@atlassian.com,productcert@siemens.com— lo calculó el fabricante. - En la API, cada entrada de
metricstrae un camposource. Ese campo es la respuesta. Un ejemplo que podés pegar en el navegador, cambiando el identificador:https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-114625. - Si la fuente es un UUID en lugar de un correo, se resuelve contra la API de fuentes de NVD, que devuelve el nombre de la organización. Es lo que hice para identificar a las dos entidades de CISA de esta nota.
Un detalle técnico para quien vaya a repetir la medición: en cada entrada de métricas hay también un campo type, con valores Primary o Secondary, y es tentador usarlo para identificar a NVD. No sirve para eso: type describe el rol de ese puntaje dentro de su propia versión de escala, no quién lo escribió. Un CNA puede figurar como Primary y NVD puede figurar como Secondary. Lo que identifica al autor es source, y nada más.
¿Qué hago distinto el lunes al leer un puntaje CVSS?
Tres cosas chicas, en orden de cuánto rinden:
- Antes de citar un puntaje, mirá el campo
source. Es un clic y cambia el peso de la frase: "el fabricante lo puntúa 9,8" no es lo mismo que "NVD lo puntúa 9,8". - No compares números de escalas distintas. Si uno es 4.0 y el otro 3.1, no hay comparación posible. Y si un fabricante publica los dos, usá el que coincida con la escala del otro producto que estás evaluando.
- No uses el puntaje como único criterio de prioridad. Lo que mejor ordena el trabajo sigue siendo: está expuesto a internet, hay explotación confirmada, y qué pasa si cae ese equipo. Las notas de esta semana sobre Plex, Siemens Software Center y el orquestador de Arista son tres casos donde el puntaje era lo menos informativo del aviso.
Una aclaración sobre el método y sus límites, porque esta nota es una medición y conviene poder auditarla. Universo: las 140 altas del catálogo KEV de CISA de enero a marzo de 2026 y de septiembre a octubre de 2026 —una ventana de 3 meses bastante anterior al cambio y otra de 2 meses posterior—, con su ficha de la API de NVD 2.0 descargada el 26 de octubre de 2026; las 140 tenían ficha legible. Criterio: un puntaje es "propio de NVD" si el campo source de la entrada CVSS es nvd@nist.gov; solo se miraron las claves cvssMetricV*, nunca ssvcV203, que no es un puntaje de severidad y en estas fichas viene siempre de CISA. Corte: por fecha de publicación del CVE frente al 15 de abril de 2026, no por fecha de alta en el catálogo. Límites, los tres que más pesan: el universo son dos ventanas y no una serie completa, así que no mide el momento exacto del cambio; con 59 y 81 fichas por grupo el margen de error es de varios puntos y no conviene leer un mes aislado como señal; y los campos vulnStatus y las métricas cambian con el tiempo, así que una ficha sin puntaje hoy puede tenerlo más adelante —NIST acepta pedidos de puntaje por correo—. Lo que no pude leer: la página de proceso de NVD que describe en detalle qué incluye el enriquecimiento devuelve una página vacía desde este entorno, así que el mecanismo que describo sale de la medición y del comunicado, no de esa página. Los dos textos de NIST que cito son del listado de novedades de NVD, consultado hoy.
Preguntas frecuentes sobre el puntaje CVSS y NVD
¿Significa que NVD abandonó los CVE que se están explotando?
No, y los datos de esta medición dicen lo contrario. De las 140 fichas, 139 están en estado "Analyzed", que es la etiqueta con la que NVD marca su propio proceso de enriquecimiento como completo, y 139 tienen declaraciones de aplicabilidad CPE, que las produce NVD. Lo que falta en la mayoría de las fichas nuevas es el puntaje, no el enriquecimiento. Y falta porque NIST anunció en abril de 2026 que no iba a duplicar un puntaje que el CNA ya había puesto.
Entonces, ¿el puntaje del fabricante no sirve?
Sirve, y en general es el que mejor conoce el producto. El punto no es que esté mal, es que es una sola fuente y la parte interesada. Antes de abril de 2026 lo habitual era tener dos números calculados por separado sobre el mismo hecho; ahora, en las fichas nuevas, lo habitual es tener uno. Para el 28,8% de los casos donde NVD sí puntuó, vale la pena mirar si los dos números coinciden: cuando no coinciden, la diferencia te dice algo.
¿Por qué algunas fichas nuevas sí tienen puntaje de NVD?
Casi siempre porque faltaba el de la escala 3.1. De las 17 fichas publicadas desde abril que tienen puntaje de NVD, en 15 no había ningún CVSS 3.x de un tercero, y esos 15 tenían solo un CVSS 4.0. NVD vino a cubrir ese hueco. Visto al revés: de las 42 fichas en las que NVD no puntuó, en 41 ya existía un 3.x ajeno. La presencia del puntaje de NVD depende más de qué escala usó el CNA que de cualquier otra cosa.
¿Cómo veo quién puso el puntaje, sin instalar nada?
Mirá el campo source de cada métrica CVSS, que está tanto en la página web de NVD como en la respuesta de su API. Si dice nvd@nist.gov, es de NVD; si dice el correo de un fabricante, es del fabricante; si es un UUID, se resuelve contra la API de fuentes de NVD. Lo que no hay que usar es el campo type: sus valores Primary y Secondary describen el rol del puntaje dentro de su versión de escala, no el autor. Un CNA puede aparecer como Primary y NVD como Secondary.
¿Esto cambia cómo debería priorizar los parches?
Cambia el peso que le das al número, no el orden general. Lo que sigue ordenando mejor el trabajo es si el equipo está alcanzable desde internet, si hay explotación confirmada —que es justamente lo que significa estar en el catálogo de CISA— y qué se cae si ese equipo se cae. El puntaje es un insumo más, y ahora sabés que en las fichas nuevas suele venir de una sola fuente. Lo que conviene abandonar es comparar un 4.0 contra un 3.1 como si fueran la misma vara.