Parchear no es remediar: medimos con qué frecuencia el parche ya llega tarde

El 14 de septiembre de 2026, Cisco publicó un aviso de seguridad por CVE-2026-76461, una inyección SQL en el análisis de correo de AsyncOS, el software detrás de Cisco Secure Email Gateway. Puntúa 9.8 sobre 10. No requiere credenciales, ni acceso administrativo, ni interacción de nadie: un mensaje preparado que entra por el gateway puede terminar en ejecución de comandos como root en el equipo. No hay mitigación alternativa. El remedio es una versión corregida.

Ese mismo día, CISA lo añadió al catálogo de vulnerabilidades explotadas conocidas, que es el gobierno de Estados Unidos diciendo que se está usando contra objetivos reales ahora mismo. Las agencias federales tuvieron hasta el 17 de septiembre de 2026 para corregirlo, 3 días.

Todos los textos sobre esto, el nuestro incluido, terminan recomendando el mismo primer paso: instala el parche. El consejo es correcto y a la vez es lo menos interesante que se puede decir, porque da por supuesto algo que nadie comprueba. Supone que existió un periodo en el que parchear te habría protegido.

Así que medimos si ese periodo existe. No para esta vulnerabilidad, para todas.

La ventana, medida

Dos registros públicos hacen la pregunta respondible. El registro CVE de una vulnerabilidad tiene una marca de publicación: el momento en que el mundo pudo saber por primera vez que existe. El catálogo de CISA tiene una fecha de alta por entrada: el momento en que el gobierno dijo que ya se está explotando. Resta una de la otra y tienes el aviso que realmente recibiste.

Lo hicimos con el catálogo completo, 1713 entradas en la versión 2026.09.16, y contamos las 846 dadas de alta desde 2023 en adelante.

Vuelve a leer la fila en negrita. En una de cada cinco entradas, el día en que la vulnerabilidad se hizo pública es el día en que ya se estaba usando. No hubo ventana. Un equipo con un proceso de parcheo impecable, con alertas sobre los avisos del fabricante y con un control de cambios capaz de sacar una versión de emergencia en una tarde, habría estado expuesto exactamente el mismo tiempo que todos los demás: todo el tiempo anterior a que alguien lo supiera.

24 entradas van más lejos y se listaron como explotadas antes de que el registro CVE fuera público siquiera. Y este año, con 228 entradas, 2026 va en 17.5% el mismo día, con una mediana de 15 días. Solo Cisco suma 17 de las entradas de este año, por detrás únicamente de Microsoft con 38.

La mediana de 18.5 días tampoco es la mitad tranquilizadora del asunto. Es el número que describe las vulnerabilidades de las que te enteraste antes de que se convirtieran en arma, y 18.5 días es menos que la mayoría de ventanas de mantenimiento trimestrales, menos que muchos ciclos de comité de cambios, y bastante menos de lo que tarda una empresa mediana en conseguir permiso para reiniciar un gateway de correo.

Lo que esta medición no es

Los límites importan más que el titular, así que aquí están.

• Una fecha de alta no es una fecha de explotación. CISA lista una vulnerabilidad después de confirmar su explotación, que siempre es después de que la explotación empezara. Cada hueco de aquí es por tanto generoso con quien defiende. El aviso real fue más corto de lo que medimos, nunca más largo.
• El catálogo es un suelo, no un censo. Contiene lo que CISA ha confirmado y ha decidido publicar. La explotación que nadie detectó no está ahí.
• 2023 es el suelo por una razón. El catálogo abrió a finales de 2021 con un histórico acumulado, así que las primeras cohortes son vulnerabilidades viejas archivadas años después: una mediana de 446 días de antigüedad al listarse para las 311 entradas de 2021 y de 1436 días para las 555 de 2022. Incluirlas mediría un trabajo de archivo y no una carrera, así que quedan fuera de todas las cifras anteriores y aparecen aquí solo como la razón.
• Un registro CVE es un sustituto del conocimiento público. Suele coincidir con el aviso del fabricante, aunque no siempre a la misma hora, así que la precisión de un solo día es aproximada. Lo que sostiene el argumento es la distribución, no una fila concreta.

El método, en una frase, para que cualquiera pueda reproducirlo: cruza el catálogo KEV de CISA con la API de servicios CVE de MITRE por el identificador CVE, resta la fecha de publicación del registro a la fecha de alta, y cuenta. No escaneamos, sondeamos ni nos conectamos a nada, y no se nombra a ninguna organización. Las cifras de esta página se generaron el 17 de septiembre de 2026 a partir de la versión 2026.09.16 del catálogo.

Lo que cambia el significado de la palabra remediación

Si una parte significativa de las vulnerabilidades graves ya está en uso antes de que pudieras enterarte, entonces aplicar el parche no es el final del trabajo. Es el comienzo de otra pregunta: ¿ya había alguien dentro antes de que llegara el parche?

Para CVE-2026-76461 esa pregunta no es teórica. El fallo da ejecución de comandos como root, y CISA lo listó como explotado el mismo día de su divulgación, lo que significa que algunos equipos ya estaban comprometidos antes de que sus dueños tuvieran una versión corregida que instalar. Parchear una máquina así actualiza el software. No expulsa a quien llegó primero, y no deshace lo que se llevó.

Un gateway de correo es la peor máquina que puedes perder

Cualquier equipo expuesto a internet es malo de perder. Un gateway de correo es peor que la mayoría, y conviene ser concreto sobre por qué, porque el instinto es tratarlo como un filtro y no como un sistema que guarda secretos:

• Guarda credenciales de directorio. Los gateways se conectan a LDAP o Active Directory para resolver destinatarios y aplicar políticas. Esa cuenta es un punto de apoyo dentro del directorio, y suele ser más antigua y con más permisos de lo que nadie recuerda.
• Guarda credenciales de envío. Cuentas de relay, claves de API de proveedores, y la reputación asociada a ellas. Es lo más monetizable de la máquina, y por eso las campañas que buscan credenciales van justo a por esos archivos, como encontramos en nuestra propia infraestructura en una medición del tráfico de ataque de fondo.
• Guarda llaves privadas TLS de los nombres que sirve, y los certificados correspondientes.
• Ve el correo. No las cabeceras, los mensajes: facturas, contratos, restablecimientos de contraseña, documentos de dirección, todo lo que la organización envía y recibe, en claro, por diseño.
• Las máquinas de detrás confían en él. La infraestructura de correo ocupa una posición que la mayoría de los cortafuegos se configuró para confiar, y moverse lateralmente desde un relay de confianza no es una técnica exótica.

Qué implica realmente remediar

El orden importa, y el primer punto es el que más se salta porque es incómodo.

1. Decide si estás parcheando o respondiendo. Si la vulnerabilidad se explotó antes de que parchearas y no puedes descartar que alcanzaran tu equipo, estás gestionando un incidente, no una tarea de mantenimiento. Son dos cosas con presupuestos y personas distintas.
2. Mira primero fuera del equipo. Root en un dispositivo significa que sus propios registros son editables por el intruso. La evidencia fiable es la que está guardada en otro sitio: registros del cortafuegos y de flujo, logs del resolutor DNS, logs de proxy, registros de correo de lo que esté delante o detrás del gateway. Empieza ahí, no por el informe que la máquina da de sí misma.
3. Trata como público todo secreto que la máquina pudiera leer. Cuentas de directorio, credenciales de relay y de API, contraseñas de administración, llaves privadas y certificados. Rótalos dando por hecho que ya están copiados, porque rotar después de un compromiso no es una precaución, es la remediación.
4. Prefiere reconstruir a limpiar. En un equipo virtual, una instancia limpia desde una imagen corregida, con la configuración vuelta a aplicar, es más rápida y mucho más fiable que intentar demostrar que un sistema con root ajeno ya está vacío. Eso no se puede demostrar desde dentro del propio sistema.
5. Revisa todos los nodos, no aquel en el que entraste. Los equipos en clúster son alcanzables y comprometibles uno a uno.
6. Saca las interfaces de administración de internet. El camino de datos tiene que estar expuesto. Su administración no, y eso vale para todos tus equipos, no solo para este.

Para esta vulnerabilidad concreta, los datos operativos son breves: las ramas corregidas están publicadas en el aviso de Cisco (confirma la cadena exacta de versión de tu rama contra el aviso mismo y no contra ningún artículo, este incluido, porque la cobertura secundaria ni siquiera coincide entre sí), y hay publicaciones que señalan que las entradas del registro de correo que coincidan con COPY ... TO PROGRAM merecen una búsqueda como señal de ejecución de comandos. Ninguna de las dos sustituye a decidir, primero, si estás en el caso de mantenimiento o en el de incidente.

Las defensas que no dependen de la velocidad

La conclusión incómoda de la medición es que la velocidad tiene un techo. Puedes bajar tu ciclo de parcheo de treinta días a tres y aun así perder contra esa entrada de cada cinco que ya estaba en uso antes de la divulgación. Lo que sí ayuda es el conjunto de controles que siguen funcionando mientras no te has enterado:

• Credenciales de vida corta. Un secreto robado vale lo que le quede de validez. Rotar con calendario convierte el robo en una fecha límite para el atacante.
• Control de salida. Casi toda la post-explotación necesita salir hacia fuera. Un equipo que solo puede hablar con los pocos destinos que de verdad necesita es un premio mucho peor que uno con salida abierta.
• Telemetría guardada fuera del equipo. Si el único registro de lo que hizo una máquina vive en esa máquina, entonces root en ella significa que no hay registro. Es el control más barato de la lista y el que más falta.
• Segmentación que asume que el equipo cae. La pregunta de diseño no es si el gateway puede ser comprometido, es a qué llega un atacante desde él.
• Copias de seguridad que el atacante no alcance desde la red comprometida. La versión cara de estos incidentes siempre es aquella en la que el intruso encontró las credenciales de las copias.

144 de las 846 entradas desde 2023 constan en el catálogo con uso conocido en campañas de ransomware, es decir un 17%. La mediana del plazo que CISA da para corregir una vulnerabilidad listada es de 21 días desde el alta. Esos dos números juntos describen bastante bien el ritmo al que ocurre esto.

Si operas algo de esto

El consejo concreto para Cisco Secure Email Gateway es ir al aviso del fabricante, instalar la versión corregida de tu rama como cambio de emergencia, y después decidir con honestidad si puedes descartar que llegaran antes. Si no puedes, la rotación de credenciales no es opcional.

El consejo general es la parte que sobrevive a este CVE. Escribe qué equipos expuestos a internet tienes y quién es el responsable de cada uno, porque las máquinas del borde suelen ser las que no tienen dueño con nombre ni cadencia de parches. Asegúrate de que sus registros se envían a un sitio que no se pueda editar desde el propio equipo. Rota con calendario las credenciales que guardan, en lugar de hacerlo después de un incidente. Y cuando llegue el próximo aviso, trata la frase “parchea de inmediato” como el primer paso del trabajo y no como todo el trabajo, porque una de cada cinco veces los atacantes empezaron antes que el aviso.

Fuentes y método: los detalles de la vulnerabilidad provienen del aviso de seguridad de Cisco para CVE-2026-76461 y del catálogo de vulnerabilidades explotadas conocidas de CISA. La medición cruza ese catálogo (versión 2026.09.16, publicada el 16 de septiembre de 2026, 1713 entradas) con la API de servicios CVE de MITRE por el identificador CVE y compara la fecha de alta en el catálogo con la fecha de publicación del registro CVE. Las entradas anteriores a 2023 quedan excluidas por ser histórico acumulado del catálogo, por la razón explicada arriba. Cifras generadas el 17 de septiembre de 2026. No escaneamos, sondeamos ni nos conectamos a nada, y no se nombra a ninguna organización como vulnerable o comprometida.