Cisco publicó el 14 de septiembre a las 16:00 GMT un aviso crítico por CVE-2026-76461, una inyección SQL en el análisis de correo de AsyncOS para Cisco Secure Email Gateway. El aviso dice tres cosas en la misma página, y las tres importan: la falla permite ejecutar comandos como root sin autenticarse, no hay ningún workaround, y el propio Cisco confirma explotación activa.
Hay un cuarto dato, en la sección de créditos, que cambia cómo se lee todo lo demás: "This vulnerability was found during the resolution of a Cisco TAC support case." La falla no la encontró un investigador ni una auditoría. Apareció mientras Cisco atendía el caso de soporte de un cliente.
| Dato | CVE-2026-76461 |
|---|---|
| Qué es | Inyección SQL en la lógica que analiza el correo entrante |
| Puntaje | 9.8, crítico, en CVSS 3.1, asignado por Cisco |
| Estado en NVD | Undergoing Analysis, sin puntaje propio todavía |
| Tipo | CWE-89 |
| Privilegios que exige | Ninguno, y sin interacción del usuario (PR:N/UI:N) |
| Qué productos | Secure Email Gateway, físico y virtual, sin importar la configuración |
| Workaround | Ninguno |
| En el catálogo de CISA | Sí, desde el 14 de septiembre, con plazo al 17 |
| Identificador interno | Cisco bug CSCwu56234, aviso cisco-sa-esa-inj-2bLVGmhX |
Las versiones que corrigen son 15.5.5-014 para la rama 15.5 y anteriores, 16.0.4-302 para la 16.0 y 16.5.0-780 para la 16.5. Cisco recomienda expresamente migrar a 16.5.0-780.
¿Cómo un correo se convierte en root en el Cisco Secure Email Gateway?
El recorrido tiene tres tramos y ninguno requiere credenciales.
El primero es el que Cisco describe: la lógica que analiza el mensaje entrante no valida lo suficiente lo que viene adentro, y el contenido del correo termina formando parte de una consulta SQL. Alguien manda un mail con sentencias SQL en el lugar correcto y esas sentencias se ejecutan.
El segundo tramo es el que convierte una consulta en un comando, y está en el indicador de compromiso que publica el propio Cisco.
Cisco indica buscar en los registros la cadena COPY.*TO PROGRAM. Esa sintaxis es de PostgreSQL: COPY ... TO PROGRAM es la instrucción que, en lugar de escribir el resultado de una consulta en un archivo, se lo entrega a un programa del sistema operativo. Es el puente clásico entre una inyección SQL y la ejecución de comandos, y exige privilegios altos dentro de la base. Cisco no dice qué motor usa AsyncOS por debajo, pero el indicador que publica es sintaxis de PostgreSQL, y explica sin rodeos por qué el resultado final es root: el comando hereda los privilegios del proceso que lo lanza.
El tercer tramo es consecuencia de los dos anteriores. Con root sobre el sistema operativo del appliance, el atacante no está dentro del correo: está dentro de la máquina que ve todo el correo.
Por qué no hay workaround para CVE-2026-76461
Cisco lo dice con una línea sola: "There are no workarounds that address this vulnerability." Y en este caso no es una omisión ni una demora, es una consecuencia del diseño del producto.
La mitigación habitual para una falla de este tipo es cortar el acceso: restringir por IP, cerrar el puerto, dejarlo detrás de una VPN. Con un gateway de correo eso no existe. La función del equipo es aceptar correo de desconocidos. Si se lo aísla de internet deja de hacer lo único que hace. No hay una lista de direcciones confiables que valga, porque el remitente legítimo de un mail nuevo es, por definición, cualquiera.
Se suma que la falla afecta al equipo "regardless of device configuration", o sea que no hay una función que se pueda desactivar para quedar fuera de alcance. Y que Cisco aclara que cubre tanto los appliances físicos como los virtuales.
Queda una sola palanca: actualizar. Para el que no pueda hacerlo en el día, lo único que corresponde es tratar el equipo como potencialmente comprometido y vigilarlo, no creer que hay una configuración que lo salva.
¿A quién afecta CVE-2026-76461 y qué productos quedan afuera?
A cualquier organización con un Cisco Secure Email Gateway, el producto que durante años se llamó IronPort ESA, en cualquier versión de AsyncOS anterior a las corregidas, física o virtual.
Cisco confirma que no están afectados dos productos que se confunden seguido con este:
- Secure Email and Web Manager, la consola de administración centralizada.
- Secure Web Appliance, el proxy web.
En la región el perfil no es la PyME de diez personas: un Secure Email Gateway aparece en universidades, organismos públicos, bancos medianos, proveedores de internet y empresas de varios cientos de empleados. Pero el impacto sí baja a la PyME por una vía indirecta y bastante común: si tu correo lo filtra el gateway de tu proveedor o de tu casa matriz, el equipo comprometido no es tuyo y el correo que pasa por ahí sí.
Para quien no tiene Cisco, la parte transferible de esta nota no es el parche sino la pregunta de la última sección: quién opera el filtro por el que pasa tu correo.
Tres gateways de correo en el catálogo de CISA, tres veces el mismo lugar
Acá aparece un patrón que se ve mejor con las fechas al lado. Los appliances de seguridad de correo entran poco al catálogo de vulnerabilidades explotadas de CISA, y cuando entran, la falla estuvo siempre en el código que analiza lo que llega.
Barracuda fue CVE-2023-2868, en el catálogo desde el 26 de mayo de 2023, descrita como validación indebida de un archivo .tar provisto por el usuario que terminaba en inyección de comandos. Libraesva fue CVE-2025-59689, desde el 29 de septiembre de 2025, inyección de comandos a través de un adjunto comprimido. Y ahora Cisco, por el análisis del mensaje.
La lógica es la misma en los tres y conviene decirla completa: para decidir si un correo es malicioso hay que abrirlo, descomprimirlo e interpretarlo. El filtro tiene que procesar contenido hostil; ese es el trabajo. Un servidor web puede rechazar lo que no entiende; un gateway de correo no puede, porque entender lo que llega es su función. Por eso el parser es el lugar donde duele, y por eso no hay configuración defensiva que reemplace al parche.
Vale además una nota sobre el tipo de falla, porque la inyección SQL tiene fama de problema resuelto y de bug de aplicación web.
Son 32 entradas de CWE-89 sobre las 1710 que tiene el catálogo, menos del 2 %. Pero 2026 ya acumula 8, más que cualquier año anterior, y no son aplicaciones web de juguete: la anterior fue Sangoma Switchvox, hace menos de dos semanas, también una inyección SQL que terminaba en ejecución de comandos sobre un appliance.
¿Cómo sé si mi Cisco Secure Email Gateway fue comprometido?
Cisco publica un indicador concreto. Sobre los registros de correo del equipo:
grep -i "COPY.*TO PROGRAM" mail_logsCualquier resultado puede indicar actividad maliciosa. Dos precisiones del aviso que es fácil pasar por alto:
- Si el equipo está en clúster, hay que revisar los registros de cada miembro, no solo el que se administra habitualmente.
- En Cisco Secure Email Cloud, quien no tenga acceso a la línea de comandos puede no estar en condiciones de comprobarlo por su cuenta. Cisco dice haber contactado directamente a los clientes de la versión cloud en cuyos equipos detectó actividad maliciosa. Si sos cliente cloud y no te contactaron, eso no es un certificado de limpieza: es la ausencia de una detección del lado de Cisco.
Y después está la advertencia que ordena todo lo demás, y que el aviso hace explícita: como la explotación termina en root, el atacante puede borrar u ocultar la evidencia y los indicadores dentro del propio equipo. Por eso Cisco recomienda cruzar con registros que estén fuera del appliance —los del firewall y los de la red— y buscar ahí lo que el equipo ya no puede contar: subidas inesperadas iniciadas desde el gateway hacia direcciones externas, o descargas desde direcciones sospechosas.
Es la misma lógica que aplicaba en MikroTrick ayer y en PaperCut hace dos semanas: cuando el atacante llega a administrador del equipo, los registros de ese equipo dejan de ser evidencia independiente.
Para quien tenga Snort o Firepower en la red, Cisco publicó además las reglas 67109 y 67110 asociadas al aviso.
¿Qué hago si tengo un Cisco Secure Email Gateway?
- Actualizá a la versión corregida de tu rama: 15.5.5-014, 16.0.4-302 o 16.5.0-780. Cisco recomienda migrar directamente a 16.5.0-780. Se hace desde la interfaz web, en System Administration > System Upgrade. No hay alternativa: no existe workaround.
- Antes de actualizar, sacá y guardá una copia de
mail_logsde todos los miembros del clúster. Si el equipo fue comprometido, esos archivos son la única reconstrucción posible, y un upgrade puede rotarlos. - Corré el grep de
COPY.*TO PROGRAMsobre esas copias, no solo sobre el equipo vivo. - Cruzá con los registros del firewall del período reciente, buscando tráfico saliente del gateway hacia destinos que no correspondan a su operación normal. Este paso es el que no depende del equipo sospechoso.
- Si aparece cualquier indicio, tratalo como un incidente de servidor comprometido, no como un parche pendiente: un equipo con root ajeno no se arregla actualizando. Corresponde aislarlo, preservar la evidencia y reconstruirlo desde una base confiable, y rotar lo que haya pasado por ahí. El correo que atravesó el gateway durante la ventana hay que considerarlo expuesto.
- Si el correo lo filtra un tercero, preguntá hoy: qué producto usa, en qué versión y si ya actualizó. El formato para pedir eso sin quedar en una discusión está en cómo responder un cuestionario de seguridad, que sirve igual en la dirección inversa.
Es la misma familia de casos que Citrix NetScaler y Cisco FMC la semana pasada: equipos de borde que concentran confianza y que, cuando caen, no dejan un problema acotado. El orden general de prioridades está en la guía de ciberseguridad para PyMEs de LATAM, los términos en el glosario, y el resto de la categoría en email y antiphishing.
¿Quién puede ignorar el aviso de Cisco?
Quien no tenga un Secure Email Gateway. Es un appliance específico: si tu correo es Microsoft 365 o Google Workspace con el filtro que viene incluido, o si usás un servicio en la nube de otro fabricante, esta falla no aplica a tu infraestructura.
Tampoco aplica a quien tenga Secure Email and Web Manager o Secure Web Appliance y no el gateway: Cisco los lista explícitamente como no afectados.
Lo que no cambia para nadie es el encuadre de fondo. Si el correo de tu empresa lo filtra un equipo —propio o de un tercero—, ese equipo es parte de tu superficie de ataque aunque no lo administres vos. La higiene básica del correo, que sí controlás, sigue siendo SPF, DKIM y DMARC bien configurados, y no depende de qué gateway haya adelante.
Preguntas frecuentes sobre CVE-2026-76461 y Cisco Secure Email Gateway
¿Sirve bloquear remitentes o filtrar adjuntos hasta poder actualizar?
No de forma confiable. La falla está en la lógica que analiza el mensaje, o sea que se dispara mientras el equipo decide si el correo es legítimo, antes de que cualquier regla de bloqueo pueda opinar. Cisco no publica ningún workaround justamente por eso. Filtrar más agresivamente no reduce la superficie: aumenta el trabajo del componente vulnerable.
Tengo el Secure Email Gateway en versión virtual, no el appliance físico. ¿Cambia algo?
No. El aviso dice que afecta al Secure Email Gateway "both physical and virtual, regardless of device configuration". La versión virtual corre el mismo AsyncOS y necesita la misma actualización.
El grep de mail_logs no devolvió nada. ¿Puedo darlo por cerrado?
No del todo, y el motivo está en el aviso de Cisco: como la explotación exitosa da privilegios de root, el atacante puede borrar u ocultar los indicadores dentro del equipo. Un grep limpio sobre un equipo potencialmente comprometido prueba menos de lo que parece. Por eso Cisco recomienda cruzar con registros externos —firewall y red— que el atacante no controla. Si el equipo estaba en una versión vulnerable y expuesto, la ausencia de rastros baja la probabilidad pero no cierra el tema.
¿Por qué CISA le puso un plazo de tres días a CVE-2026-76461?
Es el escalón más corto que usa el catálogo y lo reserva para casos con explotación confirmada y alto impacto. Acá se juntan las tres condiciones: Cisco confirma explotación activa, el resultado es root sin autenticación, y no existe mitigación temporal. El plazo obliga a los organismos federales de Estados Unidos, no a una empresa de la región, pero sirve como referencia de cuánta urgencia le asignó quien mira el panorama completo.
Mi proveedor filtra el correo con un Cisco. ¿Qué le pregunto?
Cuatro cosas, y todas tienen respuesta corta: qué versión de AsyncOS corre, si ya pasó a 15.5.5-014, 16.0.4-302 o 16.5.0-780, si revisó mail_logs en todos los miembros del clúster buscando COPY.*TO PROGRAM, y si cruzó los registros del firewall del último mes. Si la respuesta a la última es que no hizo falta porque el equipo no muestra nada, vale insistir: ese es exactamente el punto que el aviso de Cisco marca como insuficiente.
