El caso principal
Esquema del caso: una puerta de correo y un motor de identidad sin autenticación, ambos al KEV en la misma semana.
El lunes 14 de septiembre, un investigador publica los detalles de CVE-2026-76461 (Fuente: SOCRadar), una ejecución remota de código con privilegios de root en Cisco Secure Email Gateway.
El vector es un correo electrónico con SQL malicioso en su interior.
No hace falta autenticarse, no hace falta interacción del usuario, no hace falta nada más que el mensaje llegue a la puerta de entrada (Fuente: helpnetsecurity.com).
Ese mismo día CISA añade la vulnerabilidad a su catálogo de explotación conocida, KEV y fija a las agencias federales de Estados Unidos un plazo de parcheo que venció ayer 17 de septiembre.
Tres días para una puerta de correo expuesta a internet.
Un administrador llega el lunes y abre el correo, ve el aviso, comprueba la versión de su Secure Email Gateway y descubre que está en la lista.
El detalle técnico que importa es la inyección SQL.
El gateway procesa el mensaje y construye una consulta contra su base de datos interna y no sanea bien la entrada.
Un atacante que controla el contenido del correo controla esa consulta.
CISA informa y no por gusto… hay una explotación confirmada en el wild.
Eso significa que ya hay alguien usándolo contra sistemas reales mientras los administradores leen el aviso.
No es un caso aislado
Este miércoles 16 en esta misma semana, aparece CVE-2026-76460 en Cisco ISE.
Bypass de autenticación remoto, sin credenciales, CVSS 10.0, explotado en el wild.
CISA lo mete en el KEV ese mismo día y fija plazo para mañana 19 de septiembre (Fuente: thehackernews.com).
ISE es el sistema que decide quién entra en la red y con qué permisos, y aparece en cualquier red corporativa grande.
Un bypass de autenticación ahí no es un fallo cualquiera suele ser la primera fase de una intrusión.
Dos productos Cisco, dos fallos sin autenticación, dos entradas en el KEV, dos plazos de días.
2+2+2+2
Sistemas de borde (EDGE) que están expuestos en red y que como consecuencia sirven de puerta de entrada.
El mismo lunes, cuatro grupos de espionaje (entre ellos APT31) usaron el mismo exploit BlueMoon contra Chrome y Windows en una sola semana.
Al parecer la extensión GemStone y las tareas programadas sobreviven al fix (FUENTE: thehackernews.com).
Durante años, la respuesta a un zero-day era parchear… además ahora toca limpiar la persistencia que el atacante dejó antes, si no se te queda el huesped dentro sin pagar el alquiler
El otro lado
El informe de amenazas de Anthropic con 154 páginas publicadas el 10 de septiembre documenta que sus agentes reescriben malware para evadir detecciones y que el botín ya son las API keys (Fuente: anthropic.com).
La IA borra la brecha de habilidad y actores pequeños ejecutan campañas de nivel estatal ya un solo operador con una API replica lo que antes requería un equipo entero.
¿El zero-day de Cisco se explota con un correo? ¿El exploit kit BlueMoon se despliega en una semana? ¿La barrera de entrada técnica baja? Puff yo no sé ustedes pero yo estoy abrumado.
Mi lectura es que estamos ante un cambio de ritmo, no de técnica.
Los fallos de borde sin autenticación siempre han existido pero esto nuevo se sale de contexto la explotación llega antes que el aviso y el atacante deja persistencia que el parche no toca.
Qué mirar
- Inventario de borde. Lista todos los Cisco Secure Email Gateway e ISE de tu red, con versión y exposición. Si alguno está en internet sin necesidad, ciérralo antes de parchear.
- Persistencia después del parche. En los sistemas afectados por BlueMoon, revisa extensiones de navegador y tareas programadas. El fix no las elimina.
- Rotación de claves. Si tienes API keys de plataformas de IA en producción, rótalas y acorta su vida. El informe de Anthropic lo señala como botín prioritario.
Cómo lo probaría en mi laboratorio
Montaría un contenedor con una versión vulnerable de un servicio de correo y le enviaría un mensaje con una carga SQL sencilla, para ver si la consulta se ejecuta.
No buscaría el exploit real, solo confirmar que la entrada no se sanea.
Después aplicaría el parche y repetiría el envío para comprobar que la misma carga ya no pasa.
Si el comportamiento cambia entre antes y después, el parche hace lo que dice. Pero ¿si no cambia?
Conclusión
La ventana entre fallo y explotación ya no se mide en semanas y el parche solo cierra la puerta pero no echa al que ya entró.