Cisco Secure Email Gateway y SD-WAN Manager: verificación de correcciones y conservación de pruebas de intrusión

Qué es

Estado al 25 de octubre de 2026. Este artículo se basa en la versión 1.0 del aviso de Cisco sobre correo electrónico, del 14 de octubre de 2026, y en la versión 1.1 del aviso sobre SD-WAN, del 2 de octubre de 2026. Antes de actuar, volver a consultar ambos avisos, sus tablas de versiones corregidas y las instrucciones de recuperación del servicio de soporte.

CVE-2026-76519 afecta al tratamiento de archivos en Secure Email Gateway; CVE-2026-76504 permite eludir la autenticación en Catalyst SD-WAN Manager. CISA las añadió a su catálogo de vulnerabilidades explotadas el 14 de octubre y el 30 de septiembre de 2026, respectivamente. Entrada sobre correo electrónico, entrada sobre SD-WAN.

Por qué importa

Tomar por separado las decisiones relativas a la exposición, la instalación del parche y la investigación de una posible intrusión. El procedimiento de recuperación de SD-WAN de Cisco exige expresamente recopilar pruebas antes de actualizar y, después, someterlas al análisis del servicio de soporte. Una vez recopiladas las pruebas, no se debe esperar al resultado de esos análisis para actualizar. Aplicar el procedimiento de recuperación correspondiente al producto y al tipo de despliegue afectados; una instrucción genérica de restaurar desde una copia de seguridad no es suficiente.

Cómo aplicarlo

• Exposición y corrección del correo electrónico: comprobar si AMP File Reputation está asignado a una política de correo y si la versión de Content Scanner Tools es anterior a 25.3.0.5525. Las versiones corregidas de AsyncOS son 15.5.5-014 y 16.5.0-780; 16.0 requiere una migración. Cisco recomienda 16.5.0-780 para las ramas anteriores. Las versiones con soporte y licencia también pueden recibir el paquete corregido del escáner. Aviso sobre correo electrónico.
• Verificación del correo electrónico: ejecutar contentscannerstatus; solicitar una actualización manual con contentscannerupdate cuando sea necesario; después, volver a comprobar que la versión sea 25.3.0.5525 o posterior. Esta actualización del paquete no requiere reiniciar. En cada miembro del clúster, inspeccionar:

grep "System Security" system_logs

Remitir al soporte de Cisco los mensajes de sospecha de intrusión o de análisis incompleto. Contrastar con los registros de red externos.

• Recuperación del correo electrónico: conservar primero las pruebas. Si se sospecha que un dispositivo virtual está comprometido, desplegar un reemplazo corregido, recrear la configuración sin importar archivos antiguos y renovar las credenciales y el material criptográfico. Recuperar todos los miembros de un clúster afectado. La recuperación de dispositivos físicos requiere la intervención del soporte de Cisco. Mantener la supervisión.
• Correcciones de SD-WAN: las versiones anteriores al umbral aplicable son vulnerables con independencia de la configuración. Utilizar la tabla del proveedor con la primera versión corregida de cada rama:

Rama de versiones	Primera versión corregida
Anterior a 20.9	Migrar a una versión corregida
20.9	20.9.10.1
20.12	20.12.8.2
20.15	20.15.6.1
20.18	20.18.4.1
26.1	26.1.2.1
26.2	26.2.1

El escudo Live Protect ofrece una protección parcial y temporal, no una remediación. Restringir el acceso de administración a equipos de confianza mientras se prepara la actualización. Aviso sobre SD-WAN.

• Investigación de SD-WAN: recopilar la salida de request admin-tech de todos los Managers, incluidos los nodos del clúster y de recuperación ante desastres, antes de actualizar. Seleccionar Log y Tech. Actualizar todos los nodos y, después, enviar los paquetes al soporte de Cisco para buscar indicadores; seguir sus instrucciones adicionales de recuperación si se detecta una intrusión. Mantenerse en la versión principal actual salvo indicación contraria del soporte. Procedimiento de remediación.
• Revisión de registros de SD-WAN: correlacionar la actividad de autenticación inesperada en /var/log/nms/containers/service-proxy/serviceproxy-access.log y /var/log/nms/vmanage-server.log con direcciones no autorizadas. La guía de remediación, en cambio, escribe el nombre del directorio del contenedor como service_proxy; confirmar la ruta local con el soporte si es necesario. La ausencia de un registro no permite concluir que el sistema esté limpio. Los nombres reservados de cuentas de servicio, por sí solos, no demuestran una intrusión. Conservar los hallazgos para el soporte en vez de eliminar cuentas por una coincidencia de nombre.

Trampas

Solicitar una actualización del escáner no demuestra que la nueva versión se haya instalado. Del mismo modo, un análisis de seguridad fallido no permite concluir que el sistema esté limpio. Antes de cerrar el incidente, conservar, como registro de aceptación operativa, la versión resultante de cada nodo, la referencia a su paquete de pruebas, la conclusión de la investigación y las tareas de recuperación pendientes.