No son fallos viejos: son clases de fallo viejas. Hicimos la cuenta al catálogo de CISA

Esta semana ha circulado un titular cómodo: que lo que más se explota son fallos que deberían estar erradicados desde hace décadas. Nos lo creímos a medias, así que hicimos lo único sensato con un tema que se puede medir: descargar el catálogo entero y contarlo. Son 1.685 entradas. De las 201 que CISA ha añadido en lo que llevamos de 2026, 123 tienen identificador de 2026 y la mediana del desfase con el año de alta es cero. Eso responde a una pregunta que el titular no estaba haciendo, y por el camino apareció otra cosa que sí cambia el trabajo de mañana.

El catálogo se llama Known Exploited Vulnerabilities, KEV para los amigos, y es la lista que CISA mantiene con las vulnerabilidades de las que existe prueba de explotación real. De los más de cuarenta mil CVE que se publican cada año, aquí solo entra lo que alguien ha visto usarse. Y se publica en un fichero JSON abierto, sin registro y sin API de pago, así que cualquiera puede hacer la cuenta en lugar de fiarse del resumen de otro.

La cuenta, para que puedas rehacerla

Trabajamos sobre la versión 2026.08.27 del catálogo, publicada el 27 de agosto a las 17:00 UTC. Son dos órdenes:

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json -o kev.json

jq -r '[.vulnerabilities[] | select(.dateAdded >= "2026-01-01") | (.cveID|split("-")[1])]
       | group_by(.) | map("\(.[0]): \(length)") | join(", ")' kev.json

Un aviso antes de que alguien nos escriba: el curl descarga siempre el fichero vigente, no la foto que usamos nosotros. Si lo ejecutas dentro de un mes te saldrán más entradas y otros porcentajes, y estará bien. Esta es la foto de la versión del 27 de agosto, con las 201 entradas que CISA añadió entre el 1 de enero y esa fecha, repartidas por el año de su identificador CVE (la orden las devuelve de más antigua a más reciente; aquí las ordenamos al revés):

123 de 201 son de este mismo año, y otras 34 del anterior: el 78 % de lo que CISA ha confirmado explotado en 2026 tiene identificador de 2025 o 2026. La media del desfase sale en 1,76 años, y esa media la estiran unas pocas entradas muy antiguas; la mediana, que describe el caso típico, es cero. El grueso de lo que se explota hoy es material fresco.

Entonces, ¿de dónde sale lo de las décadas?

De dos cosas que se parecen y no son lo mismo. Un CVE es una instancia: este fallo concreto, en el producto de un fabricante concreto, en un rango de versiones. Un CWE es la clase, la manera de equivocarse que lo produjo. Los titulares hablaban de clases. El artículo que lo originó lo explica con cuidado; es el titular el que se presta al malentendido, y nosotros picamos como todo el mundo.

Lo bueno es que esa parte también se puede medir con el mismo fichero, porque cada entrada del catálogo trae un campo cwes. Lo traen 1.510 de las 1.685. Contándolo, las clases que más aparecen entre las vulnerabilidades con explotación confirmada son estas:

No hay una sola sorpresa en esa tabla, y esa es exactamente la noticia. La primera es no comprobar lo que te llega. La tercera y la quinta son escribir fuera del sitio reservado en memoria, que es el error que enseñan en segundo curso. Todas estaban descritas y con nombre propio mucho antes de que existiera la mitad del software que hoy las contiene.

Eso encaja con lo que dice el Vulnerability Review que CISA publicó el 28 de agosto, un análisis de los registros CVE y KEV de sus años fiscales 2024 y 2025: siete de los diez CWE más frecuentes de 2025 seguían siendo defectos que MITRE ya calificó de imperdonables en 2007. El informe atribuye a la familia de las inyecciones 7.701 CVE en 2024 y 21.019 en 2025. Esa segunda cifra hay que cogerla con pinzas: casi triplicar en un año se explica mejor por una mejor asignación de clases que por una explosión real de inyecciones, y son años fiscales, no naturales.

La cola larga existe, y mide otra cosa

De esas 201 entradas de 2026, 35 llevan un identificador de 2023 o anterior, 16 son de 2019 o anterior y 10 de 2012 o anterior. Ahí hay piezas de museo. El 20 de mayo entró en la lista CVE-2008-4250, el fallo del servicio Server de Windows que Microsoft parcheó fuera de ciclo en octubre de 2008 con el boletín MS08-067 y por el que se propagó el gusano Conficker. El 26 de agosto entraron CVE-2015-3246 y CVE-2015-5287, dos fallos de Red Hat de hace once años, en la misma tanda que CVE-2026-8452 de NetScaler, del que hablamos el viernes. El identificador más antiguo del catálogo entero es CVE-2002-0367.

La lectura fácil sería que hay gente sin parchear desde 2008. Puede que la haya, pero el dato no dice eso. La fecha de alta mide cuándo CISA confirma que hay explotación, no cuándo esa explotación empezó. Un fallo de 2008 que entra en 2026 no ha resucitado: lo más probable es que lleve años usándose contra sistemas que nadie miraba y que este año alguien lo haya documentado por fin en términos que permitan anotarlo. La cola larga mide lo tarde que llega la prueba. Es nuestra lectura, no un dato del catálogo.

Lo que no íbamos buscando: en junio cambiaron las reglas

Cada entrada del catálogo trae una fecha límite de corrección. Al contar la diferencia entre la fecha de alta y esa fecha límite en las 201 entradas de 2026 nos salió un promedio raro, así que partimos la lista por meses. Y la raya aparece sola en junio:

Hasta el 9 de junio los plazos se repartían entre 21 días (44 entradas), 14 días (55) y 3 días (31). Desde el 10 de junio solo quedan dos valores: 55 entradas con tres días y 13 con catorce. Nada más. La explicación no está en el fichero, está en el Boletín Oficial de allí: el 10 de junio de 2026 CISA emitió la directiva BOD 26-04, «Prioritizing Security Updates Based on Risk», que deroga expresamente la BOD 22-01 de 2021 y la BOD 19-02 de 2019. En vez de un plazo único para todo el catálogo, la nueva monta una matriz que puntúa exposición del activo, evidencia de explotación, capacidad de automatización del atacante e impacto técnico; lo peor de la matriz se corrige en tres días y además con triaje forense obligatorio.

Conviene decir a quién obliga eso antes de que nadie se asuste: a las agencias civiles federales de Estados Unidos. A tu empresa no la obliga nadie. Pero es la mejor señal pública que existe sobre la velocidad a la que el organismo que mantiene la lista cree que hay que moverse, y esa señal se ha multiplicado por tres y medio este verano. Nosotros lo vimos por primera vez el viernes, en el propio texto del catálogo para el fallo de NetScaler, que ya exigía BOD 26-04 más los requisitos de triaje forense.

Aquí está el nudo, y lo decimos sin adornos porque es lo que vemos en empresas reales: una pyme no tiene un proceso de parcheo que gane esa carrera de forma sostenida. Tres días laborables incluyen a la persona que lo tiene que hacer de vacaciones, la ventana de parada que hay que negociar con quien factura, y el proveedor del software vertical que aún no ha certificado la versión nueva. Quien te diga que la solución es «parchear más rápido» no ha mirado el calendario de una empresa de cuarenta personas.

Lo que la cuenta NO dice (y donde nos equivocaríamos)

Si agrupas las 201 entradas de 2026 por fabricante, el reparto es tentador. Van los doce con cuatro o más, de 88 fabricantes distintos: Microsoft 36, Cisco 14, Apple 8, Fortinet 6, y con 5 cada uno Google, Ivanti, Linux y Synacor, y con 4 cada uno Adobe, Langflow, Oracle y SolarWinds. La tentación es publicar eso como ranking de malos fabricantes. Sería un error, y lo decimos sabiendo que un titular así funcionaría mejor. Ese conteo mide superficie instalada, atención de los investigadores y disposición del fabricante a reconocer sus fallos. Microsoft encabeza la lista porque su software está en todas partes y porque, cuando algo se explota, se sabe. Si dejas de comprarle por esta tabla, has leído mal la tabla.

Hay una segunda cosa que la cuenta no dice, y es más importante: el catálogo es un suelo, no un techo. Solo recoge lo que alguien ha visto, confirmado y comunicado. Lo que falta de la lista es lo que todavía nadie ha pillado. En la misma línea, 352 de las 1.685 entradas —el 21 %— están marcadas con uso conocido en campañas de ransomware, y en 2026 son 24 de 201. Las demás figuran como Unknown, que quiere decir «no consta».

Lo que sí puedes decidir

No puedes parchear una clase de fallo, y no puedes hacer que tu proveedor de software valide sus entradas. Lo que sí controlas son cuatro decisiones, todas de arquitectura. Ninguna es nueva ni brillante; siguen funcionando cuando el parche llega tarde, que es su mérito entero.

• Qué está publicado en internet. Mira otra vez la tabla de clases: la validación de entrada, la inyección de comandos y el salto de directorio necesitan que alguien llegue a la entrada. Un panel de gestión accesible solo desde la red interna o desde VPN recorta el catálogo a la parte que te afecta de verdad. Es la medida más aburrida de todas y la que más disgustos nos ha ahorrado.
• Con qué privilegios corre cada servicio. El mismo fallo vale un susto o vale el dominio entero según la cuenta bajo la que se ejecute el proceso. Lo escribimos ayer a cuenta de PaperCut: la criticidad de un servidor la fija con qué privilegios corre y a qué está conectado, no lo que hace de cara al usuario.
• Qué ve ese servicio si se lo llevan. En las redes que nos encontramos, segmentar suele ser una tarde de firewall, y decide si un servidor comprometido es un incidente o una reconstrucción.
• Qué pasa cuando falle igualmente. Porque va a fallar. Detección por comportamiento en lugar de por firma, que es lo que delata a un binario legítimo haciendo algo que no hace nunca. Y una copia que hayas restaurado de verdad alguna vez: nuestro último simulacro de recuperación completa duró catorce minutos, y lo contamos como prueba, no como promesa. Un backup sin probar no es un backup: es un amuleto.

Y hay una quinta decisión que casi nadie toma y que es la única que ataca la clase en lugar del caso: qué le exiges al software antes de comprarlo. El conteo bruto de CVE del fabricante ya hemos visto que no sirve. Su comportamiento sí: si publica identificadores de sus propios fallos en lugar de arreglarlos en silencio, si tiene un canal de divulgación, si entrega inventario de componentes, si documenta con qué privilegios corren sus servicios. Son cuatro preguntas y caben en un pliego. En nuestra consultoría las hacemos siempre, y no somos resellers de ninguna plataforma: eso es lo que nos permite responder «este no» cuando toca.

Cuándo esto no va contigo

Si no tienes nada publicado en internet salvo la web corporativa en casa de un tercero, y todo el acceso remoto pasa por VPN con segundo factor, buena parte de este catálogo no te aplica y no merece que pierdas la mañana con él. Si además tu proveedor de IT te manda cada mes qué versión corre cada cosa, contrastada contra esta lista, esto es un artículo y no una tarea pendiente. Y si tienes equipo de seguridad propio, esta cuenta ya la habías hecho; nos gustaría ver tus números, porque los nuestros salen de un rato de esta mañana y un solo fichero.

Nuevo el fallo, viejo el modo

Lo que se explota es de este año. La manera de conseguirlo lleva descrita desde 2007, y las seis clases de la tabla lo confirman con el propio fichero de CISA. Encima, desde el 10 de junio el 81 % de lo que entra en la lista llega con tres días de plazo, así que la vía de la velocidad está cerrada para una empresa normal. Queda la otra: qué expones, con qué privilegios lo corres, qué ve si te lo toman y qué has probado que puedes restaurar. Descargar la lista cuesta un segundo y contarla, veinte minutos; empieza por ahí, sobre todo si al terminar descubres que tu defensa se puede apagar con un reinicio.

Fuentes (consultadas el 30 de agosto de 2026): todos los recuentos de este artículo son nuestros, calculados con jq sobre la versión 2026.08.27 del catálogo Known Exploited Vulnerabilities de CISA, publicada el 27 de agosto a las 17:00 UTC. Salen de ahí: las 1.685 entradas, las 201 de 2026, el reparto por año del identificador, las 35 con identificador de 2023 o anterior, la tabla de clases CWE (1.510 entradas con el campo cwes relleno), el corte de plazos del 10 de junio, el reparto por fabricante, las 352 entradas con uso conocido en ransomware y las fechas de alta de CVE-2008-4250, CVE-2015-3246 y CVE-2015-5287. El fichero está en cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json y las órdenes están arriba para que cualquiera pueda contradecirnos. La derogación de la BOD 22-01 y la BOD 19-02, la fecha del 10 de junio de 2026, la matriz de priorización y el triaje forense obligatorio, en BOD 26-04, «Prioritizing Security Updates Based on Risk». Que siete de los diez CWE más frecuentes de 2025 ya estaban en la lista de defectos imperdonables de MITRE de 2007, y las cifras de inyecciones (7.701 CVE en 2024 y 21.019 en 2025), proceden del CISA Vulnerability Review del 28 de agosto de 2026, a través de la cobertura de The Register y de otras coberturas del informe: lo señalamos porque el servidor de CISA nos devolvió un 403 al intentar leer esa página de forma automática y no hemos podido contrastar esas dos cifras absolutas contra el documento original, a diferencia de todo lo demás. La atribución de CVE-2008-4250 al boletín MS08-067 y al gusano Conficker, en el registro público del CVE. Son nuestras, y las marcamos como criterio y no como hechos publicados: la lectura de la cola larga como retraso de la prueba, la advertencia de no usar el conteo por fabricante como ranking de calidad, la sospecha de que el salto de 7.701 a 21.019 sea de clasificación y no de realidad, y las cinco decisiones del final. El dato de los catorce minutos es interno, de nuestro último simulacro de recuperación completa, y lo damos como prueba y no como compromiso contractual.