CISA KEV: el catálogo Known Exploited Vulnerabilities

¿Qué es el catálogo KEV de CISA?

El catálogo Known Exploited Vulnerabilities (KEV) lo mantiene la estadounidense Cybersecurity and Infrastructure Security Agency (CISA). CISA lo define como la fuente autorizada de vulnerabilidades explotadas en entornos reales, y anima encarecidamente a todas las organizaciones a priorizar su corrección.

CISA creó el catálogo en noviembre de 2021 junto con la Binding Operational Directive 22-01. Según la versión del catálogo del 24 de septiembre de 2026, contiene 1.723 vulnerabilidades. Es una parte ínfima de todas las CVE publicadas, y precisamente por eso resulta útil: una entrada de KEV no es una predicción ni una calificación de gravedad, es un registro de explotación.

Cómo se añade una vulnerabilidad

CISA añade una vulnerabilidad cuando cumple tres criterios:

1. Tiene un identificador CVE.
2. Se está explotando activamente, con pruebas fiables de que se ha explotado o se está explotando.
3. Existen instrucciones claras de corrección, una acción clara para las organizaciones afectadas, como una actualización del proveedor.

El tercer criterio importa en la práctica: una vulnerabilidad puede explotarse durante un tiempo antes de aparecer en KEV, porque no había ninguna corrección a la que remitir. Cualquiera puede proponer una vulnerabilidad mediante un formulario enlazado desde la página de KEV de CISA.

Qué contiene cada entrada de KEV

Campo	Qué contiene
cveID	El identificador CVE
vendorProject, product	Quién fabrica el software afectado y qué producto es
vulnerabilityName, shortDescription	Un nombre y una descripción breve
dateAdded, dueDate	Cuándo la añadió CISA y la fecha límite de corrección para las agencias federales de EE. UU.
requiredAction	Qué hacer: normalmente, aplicar las actualizaciones o mitigaciones del proveedor o dejar de utilizar el producto
knownRansomwareCampaignUse	«Known» si se ha utilizado en una campaña de ransomware; en caso contrario, «Unknown»
forensicTriage	«Yes» si BOD 26-04 exige un triaje forense para ella
notes, cwes	Referencias y tipos de debilidad

Actualmente, 361 entradas están marcadas como utilizadas en campañas de ransomware. Si tiene que establecer un orden dentro de KEV, esas van primero.

BOD 26-04: plazos de KEV para las agencias federales

Para las agencias civiles del poder ejecutivo federal de EE. UU., KEV no es un consejo. La Binding Operational Directive 26-04, emitida el 10 de junio de 2026, fija la rapidez con la que deben corregir. Revocó la BOD 22-01, que daba dos semanas para la mayoría de las entradas de KEV y seis meses para las CVE asignadas antes de 2021, y la BOD 19-02. Los criterios para añadir una vulnerabilidad a KEV no cambiaron.

BOD 26-04 fija cada plazo a partir de cuatro preguntas, basadas en el modelo de decisión SSVC de CISA:

• Exposición pública: ¿se puede acceder al activo desde redes públicas?
• Estado en KEV: ¿está la vulnerabilidad en el catálogo?
• Automatización del exploit: ¿puede un atacante automatizar la explotación?
• Impacto técnico: ¿la explotación da control parcial o total?

Las respuestas dan plazos que van desde 3 días, con un triaje forense para comprobar si el sistema ya estaba comprometido, hasta la corrección en la siguiente actualización del sistema. La directiva no se aplica a empresas ajenas al gobierno federal, salvo que así lo indique un contrato. Aun así, es una referencia útil para su propia política.

Cómo usar KEV si desarrolla software

La mayoría de las entradas de KEV corresponden a productos de grandes proveedores: solo Microsoft acumula 388, seguida de Cisco, Apple, Adobe y Google. También aparece código abierto y, cuando lo hace, está dentro de productos de terceros. Log4Shell (CVE-2021-44228) es el ejemplo que todo el mundo recuerda.

Los pipelines de build no están exentos. Las GitHub Actions comprometidas tj-actions/changed-files (CVE-2025-30066) y reviewdog/action-setup (CVE-2025-30154) están ambas en el catálogo: una vulnerabilidad explotada conocida puede estar en el workflow que compila su producto, no solo en el producto.

1. Compare KEV con lo que distribuye, no con lo que declaran sus repositorios. Una biblioteca vulnerable incorporada de forma transitiva, o descargada por un script de build, sigue estando en el producto.
2. Trate una coincidencia como un incidente, no como un elemento del backlog. Corríjala, o mitíguela y registre el motivo.
3. Compruebe su periodo de exposición. ¿Qué lanzamientos distribuyeron la versión vulnerable y desde cuándo? Eso es lo que preguntan los clientes.
4. Vigile el plazo de notificación. Con arreglo al Cyber Resilience Act de la UE, una vulnerabilidad explotada activamente en un producto activa para el fabricante la obligación de alerta temprana en 24 horas.
5. Clasifique todo lo demás con EPSS y CVSS. Priorización de vulnerabilidades explica el método.

Cómo obtener los datos de KEV

• CISA: la página del catálogo, además de CSV, JSON y un esquema JSON.
• GitHub: cisagov/kev-data replica los archivos de datos y se actualiza cuando lo hace el catálogo.
• Correo electrónico: CISA ofrece una suscripción a las actualizaciones del catálogo.
• Sus herramientas: muchos escáneres y plataformas de gestión de vulnerabilidades señalan las entradas de KEV, entre ellos Grype, Tenable, Qualys y Rapid7.

Cómo ayuda CRACI

KEV le dice qué vulnerabilidades se explotan. CRACI le dice dónde están. Ejecuta sus jobs de GitHub Actions y registra los paquetes que cada job descargó realmente, incluidas las dependencias transitivas, los paquetes en caché y las dependencias ocultas que ningún lockfile enumera, y reevalúa de forma continua las SBOM monitorizadas.

• Qué builds están afectados. El historial de builds muestra qué builds anteriores contenían la dependencia vulnerable, directa o transitiva, de modo que usted conoce el periodo de exposición.
• Quién la corrige. Los equipos de seguridad hacen el triaje de los hallazgos y envían cada uno al equipo responsable de la corrección.
• Evite que se vuelva a distribuir. Los controles de política pueden bloquear un build que contenga una CVE concreta.
• Notifíquela. Para las vulnerabilidades explotadas activamente conforme al CRA, CRACI presenta las notificaciones a las autoridades en nombre del fabricante.

CISA KEV: preguntas frecuentes

¿Qué es CISA KEV?

El catálogo Known Exploited Vulnerabilities (KEV) es la lista de CISA de vulnerabilidades que se han explotado en entornos reales. CISA lo define como la fuente autorizada de vulnerabilidades explotadas y anima a todas las organizaciones a priorizar su corrección.

¿Cuántas vulnerabilidades hay en el catálogo KEV?

1.723 según la versión del catálogo del 24 de septiembre de 2026, de entre cientos de miles de CVE publicadas. 361 de ellas están marcadas como utilizadas en campañas de ransomware conocidas.

¿Qué hace que una vulnerabilidad se añada a KEV?

Tres criterios: tiene un identificador CVE, hay pruebas fiables de que se ha explotado o se está explotando, y existen instrucciones claras de corrección, como una actualización del proveedor.

¿Las empresas privadas tienen que cumplir las fechas límite de KEV?

No. Las fechas límite vinculan a las agencias civiles del poder ejecutivo federal de EE. UU. en virtud de la Binding Operational Directive 26-04. Los demás pueden usar el catálogo como señal de priorización, y muchos clientes y auditores lo esperan.

¿Qué sustituyó a BOD 22-01?

BOD 26-04, emitida el 10 de junio de 2026, revocó BOD 22-01 y BOD 19-02. En lugar de un plazo fijo de dos semanas para las entradas de KEV, fija plazos que van desde 3 días hasta la siguiente actualización del sistema, según el estado en KEV, la exposición pública, si la explotación se puede automatizar y el impacto técnico.

¿Cuál es la diferencia entre KEV y EPSS?

KEV registra vulnerabilidades que ya se han explotado. EPSS estima la probabilidad de que cualquier CVE publicada se explote en los próximos 30 días. Use primero KEV y después EPSS para clasificar todo lo demás.