40,000 CVE, NIST limita el análisis detallado

En marzo de 2024, el Instituto Nacional de Estándares y Tecnología de Estados Unidos (NIST) analizó 199 de los 3,370 registros CVE que recibió. El Programa CVE ya había asignado a cada vulnerabilidad un identificador común.

El Programa CVE puede distribuir la asignación de identificadores; NIST, los proveedores y los defensores aún deben destinar capacidad escasa a validar fallas, establecer el contexto de explotación, localizar sistemas expuestos, orientar las correcciones y verificar que estas hayan surtido efecto.

El Programa CVE escaló la nomenclatura antes de que alguien escalara la interpretación

Los identificadores comunes del Programa CVE permiten que investigadores, proveedores y operadores se refieran a la misma vulnerabilidad sin tener que conciliar nombres distintos. Para 2025, el programa de MITRE se había convertido en un sistema distribuido de reportes: CyberScoop contó 413 organizaciones que reportaban entradas. El Programa CVE registró más de 40,000 entradas en 2024, lo que llevó el total acumulado por encima de 270,000. La asignación distribuida es una fortaleza, no una parte fallida del sistema.

Un identificador establece que los participantes pueden hablar de una falla. No establece si un atacante puede explotarla, si una organización particular ejecuta el código afectado ni si un parche disponible ha llegado a esa organización. El flujo de enriquecimiento de CVE de NIST requiere un insumo distinto: tiempo de análisis aplicado después de que llega un registro.

Esa distinción se volvió cuantificable en marzo de 2024. NIST analizó 199 de los 3,370 CVE que recibió ese mes y citó un apoyo interinstitucional insuficiente. Tras una interrupción de financiamiento en 2024, su rezago creció; para julio de 2025, MIT Technology Review reportó más de 25,000 vulnerabilidades en espera de análisis, cerca de diez veces el máximo anterior de 2017. Ninguna de las dos cifras indica que se haya detenido la asignación de CVE. Juntas, muestran por qué un registro en crecimiento ya no podía implicar un análisis igual de oportuno para cada entrada.

NIST convirtió la atención analítica en una decisión de riesgo

En abril de 2026, NIST acotó el análisis detallado de la National Vulnerability Database a fallas relacionadas con software crítico, sistemas federales o explotación activa, incluidas las entradas del catálogo Known Exploited Vulnerabilities de CISA. NIST también dijo que revisaría solicitudes de detalle sobre vulnerabilidades fuera de esas prioridades. No anunció que las fallas no prioritarias perderían sus ID de CVE ni que ninguna excepción pudiera recibir análisis.

CISA ya había aportado una distinción operativa. Su catálogo Known Exploited Vulnerabilities identifica fallas que se sabe han sido explotadas y ordena a las agencias federales corregir las vulnerabilidades catalogadas dentro de plazos establecidos. Un CVE nombra una falla; una inclusión en KEV agrega evidencia de uso por atacantes y una obligación de respuesta para esas agencias. Los criterios de NIST suman otras razones para dedicar atención, incluida la importancia del software y su uso en sistemas federales.

Estos criterios también dejan un problema de juicio. La explotación conocida es evidencia sólida de urgencia, pero la ausencia de una inclusión en KEV no prueba que un sistema expuesto sea seguro. El proceso de solicitudes de NIST deja espacio para casos que sus categorías permanentes no contemplan. La cobertura proporcionada no reporta resultados comparables posteriores a la política sobre rendimiento, rezago o adopción de parches, por lo que todavía no puede establecer si la selección de NIST ha acelerado el análisis de alto impacto.

Los exploits más rápidos reducen la vida útil de un registro sin triaje

Investigadores de Anthropic dijeron que su modelo Mythos Preview podía convertir vulnerabilidades divulgadas públicamente en exploits funcionales en horas en lugar de semanas. Esa es una afirmación sobre la capacidad demostrada del modelo, no un tiempo de conversión medido para cada falla pública. Aun así, cambia la decisión de un defensor ante una vulnerabilidad recién divulgada y accesible: esperar una entrada de base de datos uniformemente completa puede consumir gran parte del tiempo disponible para aplicar un parche o aislar el sistema.

Los defensores deben mantener separadas dos señales. El catálogo KEV de CISA registra explotación conocida; la capacidad de un modelo para producir un exploit indica velocidad potencial, no prueba de que los atacantes ya estén usando uno. Que un proveedor publique una corrección, a su vez, no establece que un operador la haya instalado. Una decisión de triaje útil deja constancia de qué señal justificó la acción urgente y qué evidencia sigue faltando.

La IA aumenta la capacidad de descubrimiento y también pone a prueba la capacidad de reparación

Anthropic y sus socios del Proyecto Glasswing ilustran cuán rápido puede crecer el volumen de candidatos sin generar un conteo comparable de sistemas reparados. Reuters reportó la cifra de Anthropic de 5,500 vulnerabilidades verificadas encontradas entre abril y octubre de 2026. Los socios de Glasswing reportaron más de 129,000 hallazgos de abril a julio, más de 33,000 clasificados como de gravedad crítica o alta. Los reporteros, los periodos y los términos difieren. El registro proporcionado no establece cómo se superponen esos conjuntos, cuántos hallazgos recibieron CVE ni cuántas correcciones llegaron al software desplegado.

OpenAI ofrece un contraejemplo importante a la idea de que la automatización solo agrega elementos a la fila. Describió un canal de trabajo asistido por IA que validó y corrigió 948 vulnerabilidades de escalamiento local de privilegios en Linux, con $1.2 millones en costos de API. Es trabajo posterior a la detección, no solo detección. La factura de API no es una contabilidad completa de la revisión, la integración o el despliegue, y un parche producido no prueba que todos los operadores afectados lo hayan adoptado.

Los proveedores, mantenedores y operadores pagan por distintas etapas de ese trabajo. Un proveedor puede publicar una corrección mientras un operador asume el costo de encontrar las instalaciones afectadas y modificarlas. Para decisiones de alto impacto, una revisión humana auditable debe preservar por qué se aceptó un hallazgo, por qué un sistema recibió prioridad y quién confirmó la reparación. La automatización puede reducir el esfuerzo de investigación sin volver opcional la rendición de cuentas.

Un sistema expuesto, no un CVE, es la unidad que un defensor puede proteger

El recuento de Socket sobre el compromiso de Axios npm concreta el problema de inventario. Los atacantes introdujeron una dependencia maliciosa en versiones específicas de un paquete que, según se reportó, recibe 100 millones de descargas semanales. Ese conteo de descargas describe distribución, no el número de instalaciones comprometidas. Un operador necesitaba saber qué versiones usaban realmente sus aplicaciones. El incidente también muestra por qué el trabajo de seguridad no puede organizarse solo alrededor de registros CVE: una versión comprometida de un paquete exige una respuesta de despliegue, tenga o no un identificador de vulnerabilidad que proporcione el punto de partida.

En el otro extremo de la escala, atacantes explotaron fallas críticas en tres modelos de controladores de refrigeradores conectados a internet en un hack que afectó a aproximadamente 700 supermercados europeos. Claroty y CISA señalaron las vulnerabilidades de los modelos, pero las tiendas afectadas estaban definidas por los controladores que habían desplegado y expuesto. La identidad del producto, la accesibilidad y la capacidad de reemplazar o reparar esos controladores determinaron el trabajo.

Si los proveedores y operadores pueden llevar evidencia de explotación, detalles de las versiones afectadas y el estado de la reparación desde la divulgación hasta el despliegue, NIST puede concentrar su análisis sin pedir que el registro CVE sea más pequeño. NIST recibió 3,370 fallas nombradas ese marzo. Para un operador con un sistema expuesto, la verificación final es si aún ejecuta el código vulnerable.