KEV 16 de abril de 2026 April 16, 2026 6 min de lectura 6 min read

Qué hacer en las primeras 24h cuando se confirma que un CVE está siendo explotado

Cuando CISA añade un CVE al catálogo de Vulnerabilidades Explotadas Conocidas, no es una alerta teórica: hay actores maliciosos usándolo activamente. Este protocolo de 24 horas te guía desde la detección hasta el parche o mitigación documentada.

What to do in the first 24 hours when a CVE is confirmed actively exploited

When CISA adds a CVE to the Known Exploited Vulnerabilities catalog, it's not a theoretical alert: there are malicious actors actively using it. This 24-hour protocol guides you from detection to a documented patch or mitigation.

¿Por qué el KEV cambia las reglas?

La mayoría de los equipos priorizan vulnerabilidades por CVSS. Es un punto de partida razonable, pero el CVSS mide gravedad teórica, no urgencia real. Un CVE con CVSS 9.8 puede llevar meses sin explotación activa. Uno con CVSS 6.5 en el KEV lleva días siendo usado contra organizaciones reales.

El catálogo KEV de CISA es la señal más directa de que una vulnerabilidad ha cruzado el umbral de lo teórico. No es una predicción, es un dato: alguien la está usando ahora. Para organizaciones con activos expuestos, eso transforma cualquier CVE listado en una prioridad de respuesta, no de planificación.

Referencia oficial: El catálogo KEV se actualiza continuamente en cisa.gov/known-exploited-vulnerabilities-catalog. CISA exige a las agencias federales estadounidenses remediar los CVEs listados en plazos de 2 a 3 semanas. Para el sector privado es una guía, pero la lógica de urgencia aplica igual.

Las 24 horas: protocolo de respuesta

El tiempo entre la publicación en KEV y la primera explotación en un entorno nuevo puede ser de horas. El objetivo no es ser perfecto, sino ser sistemático y rápido.

0 – 2 h
Comprueba tu inventario
Filtra por el vendor, producto y versión exacta del CVE. Si tienes inventario centralizado, esto debería tardar minutos. Si no lo tienes, esta es la señal más clara de que lo necesitas: sin inventario no hay respuesta rápida posible.

Preguntas clave: ¿tenemos ese componente desplegado? ¿En cuántos activos? ¿En qué entornos (producción, staging, desarrollo)?
2 – 6 h
Evalúa la exposición real
No todos los activos afectados tienen el mismo riesgo. Un servidor con el componente vulnerable pero sin acceso externo y sin datos sensibles es muy diferente a uno expuesto a internet que maneja credenciales.

Variables a evaluar: ¿el activo está expuesto a internet? ¿Qué datos o servicios aloja? ¿Cuál es su criticidad de negocio? ¿Hay compensating controls activos (WAF, segmentación de red, autenticación fuerte)?

El EPSS del CVE también aporta contexto: un score alto (por encima de 0.5) indica que los modelos predictivos estiman alta probabilidad de explotación. Combinado con la exposición del activo, define la urgencia real.
6 – 12 h
Comunica y asigna responsable
En este punto ya sabes qué activos están afectados y cuáles son prioritarios. El siguiente paso es garantizar que alguien es responsable de cada uno.

Para activos críticos o con exposición directa a internet: notifica al propietario del activo, al responsable de operaciones IT y, si la criticidad es alta, escala a dirección. Abre un caso de remediación con fecha límite explícita. Sin fecha, no hay urgencia.

Para activos de menor criticidad: asigna responsable igualmente, pero el SLA puede ser más relajado.
12 – 24 h
Actúa y documenta
Hay dos caminos, y a veces hay que combinarlos:

Opción A — Parche: Si el fabricante ha publicado una versión corregida y el proceso de testing lo permite, aplica el parche. Documenta la versión anterior, la versión instalada y la fecha.

Opción B — Mitigación temporal: Si el parche no está disponible, no ha pasado testing suficiente, o el activo no puede caer en ese momento, aplica controles compensatorios: regla de WAF, bloqueo de red, desactivación del componente afectado, aislamiento del activo. Documenta la mitigación, su alcance y sus limitaciones.

En ambos casos: registra la decisión, quién la tomó y cuándo. Eso es evidencia auditable.

Errores frecuentes en las primeras 24 horas

Esperar confirmación de que "nos afecta". Si el componente está en tu inventario, te afecta. La carga de la prueba es la contraria: demostrar que el activo no está expuesto o que hay controles suficientes.
Tratar todos los activos por igual. No todos los CVEs en KEV requieren la misma respuesta. La exposición, la criticidad del activo y los controles existentes definen la urgencia real de cada caso.
Confundir "parche aplicado" con "vulnerabilidad cerrada". El parche es el inicio del cierre, no el cierre. Sin validación posterior (escaneo de confirmación, comprobación de versión) no puedes certificar que está remediado.
No documentar las decisiones intermedias. Si decides aplicar una mitigación temporal en lugar de un parche, esa decisión necesita quedar registrada: quién la tomó, por qué, y cuál es el plan de cierre definitivo.
No actualizar el inventario. Si el CVE revelaba que tenías un componente que no sabías que tenías, actualiza el inventario. La respuesta al incidente es también una oportunidad de mejorar la cobertura.

Checklist de las 24 horas

CVE identificado y comparado contra inventario
Activos afectados listados con entorno y criticidad
Exposición evaluada (internet-facing, EPSS, controles existentes)
Propietario asignado para cada activo prioritario
Caso de remediación abierto con fecha límite
Parche o mitigación temporal aplicada en activos críticos
Decisión documentada: qué se hizo, quién, cuándo y por qué
Validación programada (escaneo post-parche o revisión de mitigación)

Nota sobre SLAs: Si tu organización tiene SLAs de remediación definidos (por ejemplo, 24h para KEV en activos críticos, 72h para el resto), este protocolo debe encajar dentro de ellos. Si no los tienes, este tipo de respuesta es precisamente el argumento para definirlos.

¿Tu inventario puede responder en 2 horas?

vulloop correlaciona CVEs con tu inventario real para que el primer paso de este protocolo tarde minutos, no días.

Why KEV changes the rules

Most teams prioritize vulnerabilities by CVSS. It's a reasonable starting point, but CVSS measures theoretical severity, not real urgency. A CVE with CVSS 9.8 can go months without active exploitation. One with CVSS 6.5 in KEV has been used against real organizations for days.

CISA's KEV catalog is the most direct signal that a vulnerability has crossed the threshold from theoretical. It's not a prediction — it's a fact: someone is using it right now. For organizations with exposed assets, that transforms any listed CVE into a response priority, not a planning item.

Official reference: The KEV catalog is continuously updated at cisa.gov/known-exploited-vulnerabilities-catalog. CISA requires US federal agencies to remediate listed CVEs within 2–3 weeks. For the private sector it's guidance, but the urgency logic applies equally.

The 24 hours: response protocol

The time between a KEV publication and the first exploitation in a new environment can be hours. The goal isn't to be perfect — it's to be systematic and fast.

0 – 2 h
Check your inventory
Filter by the exact vendor, product, and version of the CVE. If you have centralized inventory, this should take minutes. If you don't, this is the clearest signal that you need it: without inventory, fast response is impossible.

Key questions: Do we have that component deployed? On how many assets? In which environments (production, staging, development)?
2 – 6 h
Assess real exposure
Not all affected assets carry the same risk. A server with the vulnerable component but no external access and no sensitive data is very different from one exposed to the internet that handles credentials.

Variables to evaluate: Is the asset internet-facing? What data or services does it host? What is its business criticality? Are compensating controls active (WAF, network segmentation, strong authentication)?

The CVE's EPSS score also adds context: a high score (above 0.5) indicates that predictive models estimate a high probability of exploitation. Combined with asset exposure, this defines real urgency.
6 – 12 h
Communicate and assign ownership
At this point you know which assets are affected and which are priority. The next step is ensuring someone owns each one.

For critical assets or those with direct internet exposure: notify the asset owner, the IT operations manager, and if criticality is high, escalate to leadership. Open a remediation case with an explicit deadline. Without a deadline, there is no urgency.

For lower-criticality assets: still assign an owner, but the SLA can be more relaxed.
12 – 24 h
Act and document
There are two paths, and sometimes you need to combine them:

Option A — Patch: If the vendor has published a fixed version and the testing process allows it, apply the patch. Document the previous version, the installed version, and the date.

Option B — Temporary mitigation: If the patch isn't available, hasn't passed sufficient testing, or the asset can't go down at that moment, apply compensating controls: WAF rule, network block, disabling the affected component, asset isolation. Document the mitigation, its scope, and its limitations.

In both cases: record the decision, who made it, and when. That's auditable evidence.

Common mistakes in the first 24 hours

Waiting for confirmation that "it affects us." If the component is in your inventory, it affects you. The burden of proof is reversed: demonstrate that the asset isn't exposed or that sufficient controls are in place.
Treating all assets equally. Not every CVE in KEV requires the same response. Exposure, asset criticality, and existing controls define the real urgency of each case.
Confusing "patch applied" with "vulnerability closed." The patch is the start of closure, not the closure. Without subsequent validation (confirmation scan, version check) you can't certify it's been remediated.
Not documenting intermediate decisions. If you decide to apply a temporary mitigation instead of a patch, that decision needs to be recorded: who made it, why, and what the definitive closure plan is.
Not updating inventory. If the CVE revealed a component you didn't know you had, update the inventory. Incident response is also an opportunity to improve coverage.

24-hour checklist

CVE identified and compared against inventory
Affected assets listed with environment and criticality
Exposure assessed (internet-facing, EPSS, existing controls)
Owner assigned for each priority asset
Remediation case opened with deadline
Patch or temporary mitigation applied to critical assets
Decision documented: what was done, who, when, and why
Validation scheduled (post-patch scan or mitigation review)

Note on SLAs: If your organization has defined remediation SLAs (for example, 24h for KEV on critical assets, 72h for the rest), this protocol should fit within them. If you don't have them, this type of response is precisely the argument for defining them.

Can your inventory respond in 2 hours?

vulloop correlates CVEs against your real inventory so the first step of this protocol takes minutes, not days.