La diferencia entre una vulnerabilidad teórica y una que ya está siendo usada contra ti
Todos los años se publican decenas de miles de CVE. La inmensa mayoría nunca se explota fuera de un laboratorio o una prueba de concepto académica. Un puñado, en cambio, se convierte en la vía de entrada preferida de grupos de ransomware, actores estatales y brokers de acceso inicial en cuestión de días. El problema operativo de cualquier equipo de seguridad no es identificar vulnerabilidades — las herramientas de escaneo hacen eso automáticamente y generan miles de hallazgos — sino decidir cuáles exigen una respuesta inmediata y cuáles pueden esperar el próximo ciclo de mantenimiento.
Ese es exactamente el problema que resuelve el catálogo Known Exploited Vulnerabilities (KEV) de CISA (Cybersecurity and Infrastructure Security Agency, la agencia de ciberseguridad del gobierno de Estados Unidos). El KEV no puntúa severidad teórica ni estima probabilidades: confirma un hecho. Cada entrada del catálogo representa una vulnerabilidad para la que existe evidencia confiable de explotación activa en el mundo real, contra sistemas de producción, sin autorización del propietario. Esa distinción — severidad potencial versus explotación confirmada — es la que debería gobernar la priorización de parches en cualquier organización, no solo en las agencias federales estadounidenses a las que originalmente se dirigía.
Para un CISO, la pregunta que el KEV responde no es “¿qué tan grave podría ser esto en el peor escenario?” sino “¿quién ya está usando esto hoy, y contra qué tipo de producto?”. Esa es la pregunta que determina si un hallazgo se convierte en una tarea del backlog de parcheo trimestral o en una llamada a las 11 de la noche al equipo de infraestructura.
Cómo funciona el catálogo KEV: criterios, cadencia y qué lo diferencia de CVSS y EPSS
El KEV es un catálogo público, mantenido y actualizado por CISA, que agrupa vulnerabilidades con evidencia confirmada de explotación activa. Una vulnerabilidad entra al catálogo cuando se cumplen tres condiciones simultáneas: tiene un identificador CVE asignado, existe guía de remediación clara (un parche, una actualización de configuración o una mitigación oficial del fabricante), y hay evidencia confiable de que un actor ha ejecutado código malicioso o ha comprometido un sistema explotando esa falla específica sin autorización. No basta con que un exploit exista en Metasploit o en GitHub: CISA exige indicios de explotación real, no solo de explotabilidad técnica.
La cadencia de actualización es irregular y reactiva, no calendarizada: CISA publica nuevas entradas cada vez que confirma explotación, lo que puede significar varias alertas en una misma semana o ninguna durante varios días. Cada entrada del catálogo incluye una estructura fija de campos: el identificador CVE, el proveedor y producto afectado, un nombre descriptivo de la vulnerabilidad, la fecha en que se agregó al catálogo, la acción requerida (típicamente “aplicar las mitigaciones según las instrucciones del proveedor” o “descontinuar el uso del producto si no hay parche disponible”), y una fecha límite (due date) para la remediación por parte de las agencias federales civiles.
El origen regulatorio: de BOD 22-01 a BOD 26-04
El catálogo KEV nació como instrumento de cumplimiento con la Directiva Operacional Vinculante 22-01 (Binding Operational Directive 22-01), emitida por CISA en noviembre de 2021, titulada “Reducing the Significant Risk of Known Exploited Vulnerabilities”. BOD 22-01 obligaba a todas las agencias del poder ejecutivo civil federal de Estados Unidos a remediar las vulnerabilidades listadas en el KEV dentro de los plazos fijados por CISA — originalmente hasta seis meses para vulnerabilidades más antiguas y hasta dos semanas para las más recientes, aunque en la práctica CISA ha ido comprimiendo esos plazos de forma agresiva.
Un dato relevante para cualquier lector técnico que siga este catálogo de cerca: BOD 22-01 fue formalmente derogada y reemplazada el 10 de junio de 2026 por la BOD 26-04, “Prioritizing Security Updates Based on Risk”, que además absorbe y deroga BOD 19-02 (la directiva de 2019 sobre remediación de vulnerabilidades en sistemas expuestos a internet). BOD 26-04 mantiene el KEV como pieza central, pero amplía el modelo de priorización: ya no basta con preguntar si una vulnerabilidad está en el catálogo, sino que la urgencia de remediación se calcula cruzando cuatro variables — si el activo vulnerable está expuesto públicamente, si la vulnerabilidad figura en el KEV, si el exploit es automatizable de extremo a extremo, y el impacto técnico de la explotación. Bajo este esquema, CISA ha llegado a exigir remediación en plazos de apenas tres días para las vulnerabilidades de mayor riesgo combinado. Para equipos de seguridad en Colombia y LatAm que sin obligación regulatoria igual siguen el KEV como referencia, este cambio importa: la lógica de “exposición + explotación activa + automatización” es un marco de priorización más maduro que copiar, más allá de si la organización reporta o no a CISA.
Por qué el KEV se convirtió en estándar de facto fuera del sector público estadounidense
BOD 22-01 y BOD 26-04 solo obligan legalmente a agencias federales civiles de EE. UU. Sin embargo, el catálogo se adoptó ampliamente como referencia de priorización en la industria privada global, incluida Latinoamérica, por una razón simple: es la única fuente pública, gratuita y actualizada con regularidad que certifica explotación confirmada en lugar de explotación teórica. Los principales fabricantes de plataformas de gestión de vulnerabilidades (Tenable, Qualys, Rapid7, CrowdStrike, entre otros) integran el feed del KEV directamente en sus tableros de priorización, y buena parte de los marcos de gestión de riesgo que se usan en la región — incluidos los que CIBER-TEC recomienda a clientes corporativos — usan la presencia en el KEV como criterio de escalamiento automático, independientemente de si la organización tiene o no obligación regulatoria con CISA.
Cómo se relaciona el KEV con CVSS y EPSS
Los tres marcos responden preguntas distintas y ninguno reemplaza a los otros:
- CVSS (Common Vulnerability Scoring System) mide severidad técnica potencial: qué tan grave sería el impacto si la vulnerabilidad se explotara, en función de vectores de acceso, complejidad del ataque y daño potencial. No dice nada sobre si alguien la está explotando realmente. Una vulnerabilidad con CVSS 9.8 puede llevar años sin un solo caso de explotación documentado.
- EPSS (Exploit Prediction Scoring System), mantenido por FIRST.org, es un modelo estadístico que estima la probabilidad de que una vulnerabilidad sea explotada en los próximos 30 días, expresada como porcentaje (por ejemplo, 0.92 o 92%) y como percentil respecto al universo de CVEs. Es predictivo y probabilístico, no confirmatorio.
- KEV es binario y retrospectivo: no predice ni pondera, confirma. O hay evidencia de explotación activa, o la vulnerabilidad no está en el catálogo.
El error común es tratarlos como sistemas competidores. La forma correcta de usarlos en conjunto es secuencial: KEV primero, porque representa riesgo ya materializado y exige remediación inmediata sin importar el CVSS; EPSS segundo, para priorizar dentro del universo de vulnerabilidades aún no confirmadas en el KEV pero con alta probabilidad de explotación inminente (umbrales por encima de 0.7–0.8 suelen usarse como corte operativo); y CVSS al final, como matiz de severidad técnica dentro de cada uno de esos grupos, útil para decidir el orden de remediación cuando hay varias vulnerabilidades del mismo nivel de urgencia.
Marco de decisión operativo: qué hacer cuando una entrada del KEV toca tu entorno
La secuencia que sigue es la que CIBER-TEC recomienda ejecutar cuando el equipo de threat intelligence o la suscripción a las alertas de CISA identifica una nueva entrada del KEV que involucra un producto presente en el inventario de la organización.
1. Confirmar exposición real antes de reaccionar
El primer paso no es parchear: es determinar si el producto afectado realmente existe en el entorno, en qué versión, y si el vector de explotación aplica a la configuración desplegada. Muchas entradas del KEV afectan versiones específicas, módulos opcionales o configuraciones concretas (por ejemplo, una interfaz de administración expuesta a internet). Un inventario de activos desactualizado es la causa más común de que este paso falle — si no se sabe con precisión qué versión de qué producto corre en qué segmento de red, todo lo que sigue se construye sobre una suposición.
2. Clasificar la exposición y calcular la ventana de parcheo
Con la exposición confirmada, se clasifica el activo según el marco de BOD 26-04 como referencia práctica aunque la organización no esté obligada a cumplirla: ¿el sistema está expuesto públicamente a internet? ¿El exploit conocido es automatizable (gusano, scanner masivo) o requiere interacción manual dirigida? ¿El impacto técnico incluye ejecución remota de código, escalamiento de privilegios o exfiltración de credenciales? Un activo expuesto a internet con exploit automatizable y ejecución remota de código exige una ventana de horas, no de sprints. Un activo interno, segmentado, con exploit que requiere acceso previo autenticado, admite una ventana de días.
3. Aplicar mitigaciones compensatorias si el parche no está disponible de inmediato
No siempre existe un parche el mismo día en que CISA confirma explotación — de hecho, es frecuente que la explotación activa preceda a la disponibilidad de un parche estable, especialmente en escenarios de día cero. Cuando eso ocurre, las mitigaciones compensatorias no son opcionales, son la línea de defensa principal mientras se coordina el parcheo: aislar la interfaz de administración del sistema afectado, restringir acceso por IP o VPN, desactivar el módulo o funcionalidad específica que contiene la falla si el fabricante lo permite, reforzar reglas de IDS/IPS y WAF con las firmas específicas publicadas para ese CVE, y aumentar la frecuencia de revisión de logs del sistema afectado buscando los indicadores de compromiso (IoC) que el fabricante o CISA hayan publicado.
4. Comunicar a dirección en términos de riesgo de negocio, no de CVE
Una entrada del KEV que afecta un sistema crítico amerita una comunicación breve y directa a gerencia o al CISO, sin jerga innecesaria: qué sistema está afectado, qué tan expuesto está, qué se está haciendo, y en qué ventana de tiempo se resolverá. Los tres elementos que dirección necesita para decidir son: probabilidad de que la organización ya haya sido blanco (basada en exposición y en si el sistema aparece en superficies de ataque públicas como Shodan), impacto potencial si se explota (qué datos o procesos de negocio dependen de ese sistema), y costo/tiempo de la remediación frente a la mitigación temporal. Evitar el lenguaje puramente técnico en este reporte no es simplificar de más: es traducir el hallazgo a la moneda en la que dirección toma decisiones, que es riesgo operacional y reputacional, no severidad CVSS.
5. Documentar y cerrar el ciclo con evidencia
Cada entrada del KEV que toca el entorno debe generar un registro trazable: fecha de detección, fecha de confirmación de exposición, mitigación aplicada, fecha de parcheo definitivo y evidencia de verificación post-remediación (escaneo confirmando que la versión vulnerable ya no está presente). Este registro es lo que sostiene una auditoría, una certificación o una investigación forense posterior si el sistema termina comprometido antes de que se cerrara la ventana.
Casos reales: la velocidad de explotación tras la divulgación
El patrón que justifica todo este proceso no es hipotético. Algunos ejemplos recientes, verificables, ilustran cuán corta es la ventana entre divulgación y explotación masiva:
CitrixBleed 2 (CVE-2025-5777), una vulnerabilidad de divulgación de información en Citrix NetScaler ADC y Gateway, es quizás el caso más instructivo del último año. Citrix publicó el parche el 17 de junio de 2025. La explotación activa comenzó apenas seis días después — el 23 de junio — según honeypots de GreyNoise que detectaron actividad dirigida desde direcciones IP ubicadas en China. Lo notable es que esa explotación ocurrió casi dos semanas antes de que se publicara la primera prueba de concepto pública, el 4 de julio. CISA confirmó la explotación e incorporó el CVE al catálogo KEV el 10 de julio de 2025. El caso desmiente la suposición común de que “sin PoC público no hay urgencia”: los actores más sofisticados no necesitan un PoC de GitHub para explotar una falla — la ingeniería inversa del parche es suficiente.
Ivanti Sentry generó en 2026 el primer mandato de parcheo de tres días bajo la nueva BOD 26-04, evidenciando que CISA está dispuesta a usar ventanas de remediación federal extremadamente cortas cuando la combinación de exposición pública y explotación activa lo justifica.
Otras entradas recientes del catálogo ilustran la diversidad de vectores que terminan en el KEV: CVE-2025-40602, una falla de autorización faltante en SonicWall SMA1000; CVE-2025-20393, validación de entrada inadecuada en múltiples productos Cisco; CVE-2025-59374, un caso de código malicioso embebido en ASUS Live Update; CVE-2025-32975, autenticación inadecuada en Quest KACE Systems Management Appliance, con CVSS de 10.0; y CVE-2025-48700 / CVE-2025-66376 en Zimbra Collaboration Suite, explotadas activamente por el actor UAC-0233 contra entidades ucranianas desde septiembre de 2025. El común denominador es que todas comparten productos de infraestructura crítica empresarial — VPN, gateways de acceso remoto, plataformas de gestión de endpoints, colaboración — exactamente el tipo de activo que suele estar expuesto a internet y ser high-value para un atacante que busca acceso inicial.
Errores comunes en la gestión del KEV
Tras revisar procesos de gestión de vulnerabilidades en organizaciones de distintos tamaños, los errores se repiten con la misma frecuencia:
- Parchear en modo automático sin verificar exposición real. Aplicar el parche a todo lo que coincide por nombre de producto, sin confirmar si la versión específica desplegada es vulnerable o si el vector de ataque aplica a la configuración real, consume recursos de un equipo ya sobrecargado en remediaciones que no reducían ningún riesgo real, mientras otros sistemas sí expuestos quedan sin atención inmediata.
- Ignorar las mitigaciones compensatorias cuando el parche no está disponible. Es común que un equipo registre la entrada del KEV, confirme que no hay parche todavía, y simplemente espere — sin aislar el sistema, sin restringir acceso, sin monitoreo reforzado. Ese es exactamente el intervalo, como en CitrixBleed 2, en el que ocurre la explotación real.
- No versionar ni documentar el proceso de respuesta al KEV. Sin un runbook escrito y repetible, cada nueva entrada del catálogo se gestiona de forma ad hoc, dependiendo de quién esté de turno esa semana. Esto genera inconsistencia en los tiempos de respuesta y, crucialmente, deja a la organización sin evidencia trazable si necesita demostrar debida diligencia ante un cliente, un regulador o una aseguradora tras un incidente.
- Tratar el KEV como techo, no como piso. Algunas organizaciones limitan su gestión de vulnerabilidades exploradas activamente exclusivamente al KEV, ignorando EPSS y otras fuentes de inteligencia de amenazas sectoriales. El KEV certifica lo que ya se sabe que se explota; no captura explotación activa que CISA aún no ha confirmado o que no cumple sus tres criterios formales (por ejemplo, explotación reportada solo por un proveedor privado sin CVE asignado todavía).
- No comunicar el riesgo residual mientras dura la mitigación temporal. Cuando se aplica una mitigación compensatoria en lugar del parche definitivo, dirección debe saber que el riesgo no está en cero — está reducido pero abierto. Presentar una mitigación temporal como si fuera cierre definitivo del hallazgo es un error de comunicación que puede costar caro si el sistema termina comprometido por una variante del mismo vector.
Postura de CIBER-TEC: la explotación activa, no el CVSS, debe gobernar la prioridad
La gestión de vulnerabilidades basada exclusivamente en severidad CVSS es un modelo agotado para cualquier organización que enfrenta recursos limitados de remediación frente a un volumen de hallazgos que crece cada trimestre. Un CVSS alto sin evidencia de explotación es una hipótesis de riesgo; una entrada en el KEV es un hecho de riesgo. Los equipos de seguridad — y las juntas directivas que aprueban presupuestos de ciberseguridad — deben operar con esa distinción como principio rector, no como matiz técnico secundario.
Esto no significa descartar CVSS: significa usarlo en el orden correcto, después de haber filtrado por explotación confirmada (KEV) y probabilidad de explotación inminente (EPSS). Un programa de gestión de vulnerabilidades maduro en 2026 combina las tres señales, con el KEV como gatillo de máxima prioridad y como referencia obligatoria de revisión diaria o semanal, no mensual.
La recomendación práctica para cualquier equipo de seguridad en Colombia y la región es concreta: suscribirse a las alertas del catálogo KEV de CISA, integrar el feed en la plataforma de gestión de vulnerabilidades ya existente, y construir — por escrito, versionado, con dueños claros por paso — el runbook de respuesta descrito en este artículo, antes de que la próxima entrada del catálogo obligue a improvisarlo bajo presión. La diferencia entre una organización que contiene un incidente en horas y una que lo descubre semanas después, cuando ya hay exfiltración confirmada, casi siempre se reduce a si ese proceso existía antes de que la vulnerabilidad se volviera explotación confirmada.