El arreglo no pide ventana ni reinicio, y por eso puede no estar puesto

El aviso de Cisco del 14 de octubre tiene la forma de siempre: un 9,8, un aparato en el perímetro y explotación activa antes de que se publicara nada. Lo que no tiene la forma de siempre está en la tabla de versiones corregidas, en una frase que descoloca el procedimiento que tienes escrito para estos casos: «Updating the Content Scanner Tools does not require a software upgrade or a product restart».

Es una buena noticia: el arreglo no te obliga a saltar de rama, ni a parar el correo de la empresa un sábado por la noche. Y es exactamente por eso por lo que puede no estar puesto. El proceso de parcheo de casi todas las empresas que nos encontramos está hecho de cuatro piezas: un ticket, una aprobación, una ventana y un reinicio que confirma que se ha hecho. Un arreglo que no necesita ninguna de las cuatro no es que sea fácil de aplicar: es que no deja rastro de haberse aplicado ni de no haberse aplicado.

Qué dice el aviso, en corto

CVE-2026-76519, aviso cisco-sa-esa-afw-zqYJkjxp, publicado el 14 de octubre de 2026 a las 16:00 GMT en versión 1.0 final. CVSS 3.1 base 9,8, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: por red, sin credenciales, sin que nadie tenga que hacer clic. Afecta a Cisco Secure Email Gateway, físico y virtual, y el propio aviso dice que «in October 2026, the Cisco PSIRT became aware of active exploitation of this vulnerability». CISA lo metió en su catálogo de fallos explotados el mismo 14, con fecha límite federal del 17 de octubre y clasificado como CWE-23, travesía de ruta relativa.

La ficha de CISA describe la capacidad sin adornos: permite «an unauthenticated, remote attacker to write arbitrary files on the underlying operating system». La cobertura del día —BleepingComputer, The Hacker News— añade que lo que se consigue por ahí es ejecución con privilegios de root, y que el disparador es un correo con un adjunto manipulado. Es decir: no hay que entrar en ningún sitio; basta con escribir a cualquier buzón que pase por el aparato. Y el aparato es, por definición, el que ve todo el correo de la empresa.

Hay dos condiciones, y las dos tienen que darse a la vez. La primera: «the File Reputation service, which is part of Cisco AMP, is enabled and assigned to a mail policy». La segunda: «the Content Scanner Tools version is earlier than 25.3.0.5525». Mitigaciones, ninguna: «there are no workarounds that address this vulnerability». Versiones corregidas de AsyncOS: 15.5.5-014 en la rama 15.5 y 16.5.0-780 en la 16.5; para la rama 16.0 el aviso no da número, dice «Migrate to fixed release».

«¿Estamos afectados?» tiene tres respuestas, y ninguna está en el inventario

Esta es la parte que nos interesa de verdad, porque es la que se repite con cualquier otro fabricante. La pregunta parece de inventario y no lo es. Para contestarla hacen falta tres datos que viven en tres sitios distintos, y el que tú guardas no es ninguno de los tres.

• Una fila de una política de correo. El aviso te manda a mirar en Mail Policies > Incoming Mail Policies > Advanced Malware Protection (o la de salida). Alguien lo decidió un día, política por política, así que puede estar puesto en una y no en otra. Quien administra el sistema casi nunca se lo sabe de memoria.
• La versión de un motor que no es la del aparato. El aviso indica el comando exacto: «use the contentscannerstatus command at the CLI». Son dos números que no se mueven juntos: el aviso corrige ramas de AsyncOS, pero el arreglo viaja en el paquete del motor, así que la versión que tú inventarías no te dice si el motor está en 25.3.0.5525.
• Si el aparato puede salir a buscarlo. El paquete del motor se descarga de los servidores de actualización de Cisco. El fabricante publica incluso hosts estáticos «for customers that have strict firewall or proxy requirements» —updates-static.ironport.com y downloads-static.ironport.com, por el puerto 80—, lo que es tanto como reconocer que hay muchos aparatos a los que no se deja salir a la calle sin permiso. Esa regla de cortafuegos la escribió seguridad, con buen criterio, probablemente hace años.

Lo que tú guardas, en cambio, es la versión de AsyncOS. Es el número que sale en el informe, el que se mira en la auditoría y el que se compara con el aviso. Y en este caso concreto no contesta la pregunta.

La columna que puede decir «Never updated»

En la guía de referencia de la CLI de AsyncOS, el ejemplo de salida que el propio fabricante pone para ese comando es este:

mail.example.com> contentscannerstatus
Component                           Version    Last Updated
Content Scanner Engine              1.0        Never updated

Es un ejemplo de manual, no una medición de nada: no dice que haya aparatos ahí fuera sin actualizar nunca. Dice algo más modesto y más útil: que «Last Updated» es una columna que existe y que puede decir «nunca». Alguien diseñó ese campo porque hacía falta. En el mismo sitio donde averiguas si estás expuesto está la fecha que te dice cuánto hace que ese motor no cambia, y esa fecha es, en la práctica, la auditoría de un canal de actualización que nadie firma.

Y la hora importa: parcheado no es limpio

Aquí es donde un arreglo silencioso deja de ser una comodidad y pasa a ser un problema de orden. El fallo permite escribir ficheros. Actualizar el motor cierra la puerta por la que se escriben; no toca lo que ya se escribió. Un aparato corregido puede ser un aparato comprometido, y las dos cosas son compatibles sin contradicción.

La ficha de CISA para este CVE lleva marcado el campo de triaje forense. La guía de implantación de la directiva BOD 26-04, que es la que lo regula, lo escribe sin rodeos: «do not alter or remediate systems prior to evidence/artifact collection when possible», y explica el motivo con una frase que conviene releer: «patching may jeopardize the availability of artifacts». La secuencia que marca no es lenta —recogida en 2-24 horas, parche en 2-24 horas, priorizando lo volátil: el registro del sistema, la caché y la memoria RAM—, pero es una secuencia: primero se mira, después se cierra.

Conviene decirlo con precisión: esa directiva obliga a las agencias federales estadounidenses, no a una empresa de Manresa ni de Barcelona. No la citamos como obligación, la citamos como procedimiento razonado por gente que responde a estos incidentes a diario y que tuvo que escribir por qué el parche va después. Y si el parche entra solo, por un canal automático, sin ticket y sin reinicio, ese orden no se rompe por una mala decisión: se rompe porque no hubo ninguna decisión.

El motor que inspecciona también es superficie de ataque

La primera condición del aviso es incómoda. El aparato es explotable cuando el servicio de reputación de ficheros —la parte que analiza los adjuntos buscando malware— está activada y asignada a una política. Dicho de otro modo: la pieza por la que entra el ataque es la pieza que compraste para que no entraran ataques.

Lo decimos para que nadie lo lea al revés: esto no es un argumento para apagar el análisis de adjuntos. El aviso dice que no hay mitigaciones, y nosotros no vamos a vender como arreglo apagar un control de seguridad; el día que lo apagas pasas a estar expuesto a todo lo demás, que es mucho más frecuente que un cero-day en el motor. Lo que sí dice es otra cosa: cualquier motor que inspecciona es código que abre contenido hostil con privilegios altos. Antivirus, analizador de contenido, sandbox, firmas de IDS, el agente del EDR. Todos. Cuando diseñas el camino del correo, ese motor va en la columna de «controles» y también en la de «cosas que pueden ser atacadas». De ahí sale la consecuencia práctica: que la pasarela no sea tu único punto de detección, porque el día en que la atacada es ella, la telemetría que te queda es la del puesto.

El correo que mandamos hoy, y la foto que pedimos con él

La mayoría de las pymes que tienen una de estas pasarelas no la administran: la administra un tercero, o un compañero que se fue, o el que la montó hace seis años. Así que el entregable de hoy es un correo de tres preguntas, con la respuesta que esperas recibir escrita al lado para que no te contesten «está todo correcto».

1. ¿Qué devuelve hoy contentscannerstatus? Respuesta esperada: la salida pegada tal cual, con la versión y la fecha de la columna «Last Updated». No vale «sí, está actualizado». Si la versión es anterior a 25.3.0.5525, estamos en la segunda condición del aviso.
2. ¿En qué políticas de correo está activado el servicio de reputación de ficheros? Respuesta esperada: la lista de políticas de entrada y de salida en las que está asignado. Si se dan las dos condiciones, el aparato es explotable mientras el motor siga por debajo de 25.3.0.5525; el aviso dice que de esa versión en adelante está corregido.
3. ¿Cuándo se actualizó el motor y quién lo comprueba? Respuesta esperada: una fecha y un nombre. Si la respuesta es «se actualiza solo», la pregunta siguiente es desde cuándo y contra qué servidor, porque un aparato sin salida a Internet no se actualiza solo: se queda quieto y no avisa.

Y con ese correo va una petición más, la que casi nunca se hace: antes de tocar nada, guardad una copia de los registros de correo de las últimas semanas y anotad la versión que corre ahora mismo. No es paranoia ni es retrasar el arreglo —el arreglo se pone hoy—: es que en cuanto el motor cambie de versión —lo haga solo o lo haga alguien—, la respuesta a «¿qué versión teníamos el día que esto se estaba explotando?» deja de estar en ningún sitio. Dos minutos. Lo que cuesta es acordarse, y por eso va escrito.

Lo que no estamos diciendo

• No sabemos cuántos aparatos están sin actualizar, ni hemos medido ninguno que no sea de nuestros clientes. El «Never updated» del principio es un ejemplo del manual de Cisco, no una estadística.
• No hemos reproducido el fallo ni tenemos detalles del ataque. Cisco no publica indicadores en el aviso y nosotros no vamos a inventarnos ninguno; si administras uno de estos aparatos, los registros que tengas valen más que cualquier regla que te podamos sugerir desde fuera.
• Y no decimos que Cisco lo haya hecho mal al distribuirlo así. Un arreglo que entra sin reiniciar el correo de una empresa es, técnicamente, lo mejor que te pueden dar. El canal está bien. Lo que no está es en tu procedimiento.

Hace una semana escribíamos sobre otra pasarela de correo, otro fabricante y el mismo descuadre al revés: el parche llegó y tu mitigación sigue puesta, con el apaño temporal ahí plantado meses después. Y hace dos semanas, que tu política de parcheo no contempla que no haya parche. Los tres casos dicen lo mismo desde ángulos distintos: el procedimiento solo sabe reconocer una forma de parche —la que pide ventana— y todo lo que no tenga esa forma pasa de largo sin que nadie lo mire. Un motor que se actualiza solo, una mitigación provisional que se queda, un fallo sin parche. Tres huecos del mismo tamaño.

Fuentes (consultadas el 15-10-2026): el CVE, la puntuación 9,8 con su vector, la fecha y hora de publicación, las dos condiciones, el comando contentscannerstatus, la ruta de la interfaz, la ausencia de mitigaciones, las versiones corregidas y la frase sobre que actualizar el motor no requiere actualización de software ni reinicio salen del aviso cisco-sa-esa-afw-zqYJkjxp de Cisco. El ejemplo de salida con la columna «Last Updated» es de la guía de referencia de la CLI de AsyncOS 16.0.1. Los hosts estáticos de actualización y la frase sobre cortafuegos y proxy, de la nota técnica 117854 del propio fabricante. La entrada del catálogo —fecha de alta 14-10-2026, plazo 17-10-2026, CWE-23, marca de triaje forense y la descripción de la escritura arbitraria de ficheros— del catálogo KEV de CISA (versión 2026.10.14). Las dos frases sobre no remediar antes de recoger evidencias y sobre que parchear puede comprometer los artefactos, de la guía de implantación de BOD 26-04. El detalle de la ejecución como root y del adjunto manipulado, de la cobertura de BleepingComputer y The Hacker News. Lo nuestro, y lo acotamos: la lectura del canal de distribución del arreglo contra cómo está montado un proceso de parcheo normal, el orden «mirar antes de cerrar» aplicado a un arreglo que entra solo, y las tres preguntas del correo.