En 2023 bastaba con parchear el aparato; la ficha de 2026 pide saber apagarlo

El 10 de noviembre CISA metió en su catálogo de vulnerabilidades explotadas dos fallos de aparatos Barracuda y les puso fecha límite el día 13. Tres días. El parche del fabricante existía desde el 2 de noviembre. Lo que nos ha llamado la atención no es el plazo: es lo que esa ficha exige comparado con lo que exigía la del mismo aparato en 2023. Entonces pedía una frase. Ahora pide una lista, y la última línea de esa lista contempla dejar de usar el producto si no hay mitigación disponible.

La cadena, con las palabras de la ficha

Son dos CVE y hacen falta los dos. El primero, CVE-2026-116606, afecta solo al Email Security Gateway, la pasarela que filtra el correo. La descripción del catálogo dice que es un salto de autenticación «por una vía o canal alternativos» que permite a un atacante remoto sin autenticar «invocar una función de importación de configuración y restaurar un archivo de copia manipulado y compatible», con el resultado de modificar «la configuración global del aparato». El segundo, CVE-2026-111560, es una inyección de órdenes del sistema que permite a «un administrador autenticado» ejecutar comandos con privilegios de root «cuando el valor manipulado de zona horaria se procesa después».

Encadenados, el primero te pone dentro como administrador y el segundo te da root. El aviso de Barracuda, publicado el 2 de noviembre y actualizado el 5 y el 9, lo dice sin adornos: «Si se explotan en combinación, estas vulnerabilidades podrían permitir a un atacante saltarse los controles de autorización y obtener acceso root al dispositivo». Puntuaciones del propio aviso: 9,3 y 8,6. El parche de la pasarela es BNSF-40425 para 9.4.017 o posterior y BNSF-40430 por debajo de esa versión. A los otros cinco productos de la marca que aparecen en la lista —Load Balancer ADC, Message Archiver, WAF Control Center, Web Application Firewall y Web Security Gateway— solo les toca el segundo CVE.

Nuestra lectura de la cadena, que es opinión y no cita: lo interesante es dónde están las dos puertas. La primera no es un fallo del formulario de login; es una función que acepta un fichero, y el fichero que hace de llave es una copia de configuración, o sea, un artefacto del procedimiento de recuperación. La segunda ejecuta código a partir de un campo de zona horaria. Si mañana te sientas a auditar una pasarela de correo, esos dos sitios no están en tu lista. El desplegable de la zona horaria no está en la lista de nadie.

El mismo aparato, 1.264 días antes

Esta pasarela ya había estado en el catálogo. El 26 de mayo de 2023 entró CVE-2023-2868: validación incorrecta de un fichero .tar suministrado por el usuario, que llevaba a inyección remota de órdenes. Un fichero que subes al aparato acabando en código. Lo mismo que ahora, con otro formato de fichero y tres años y medio de diferencia. Pusimos las dos fichas una al lado de la otra y lo que cambia no es el aparato.

Entre las dos entradas hay 1.264 días. En ese tiempo el regulador ha dejado de dar por supuesto que parchear resuelve el problema. Te pide además que mires si te han entrado, que sepas qué tienes asomado a Internet y que tengas un plan por si el fabricante no llega a tiempo. Eso último ya no se contesta parcheando: se contesta en el diseño.

De dónde salen los tres días

No los eligió nadie a mano. El 10 de junio de 2026 CISA publicó la directiva BOD 26-04, «Prioritizing Security Updates Based on Risk», que sustituye el plazo calculado a partir del CVSS por un modelo de cuatro variables. Las cuatro, literales de la directiva: exposición del activo («¿está el activo vulnerable expuesto públicamente?»), estado en el catálogo («¿está la vulnerabilidad en el catálogo de vulnerabilidades explotadas conocidas de CISA?»), automatización del exploit («¿puede un adversario automatizar todos los pasos necesarios para explotarla?») e impacto técnico («¿obtiene el adversario control parcial o control total del activo vulnerable?»). De ahí salen las ventanas: tres días con triaje forense, tres días, catorce, sesenta, o diferir a la próxima actualización del sistema.

Dicho de otra forma, y esta es la parte que nos parece aprovechable para cualquiera que no sea una agencia federal: el plazo ha dejado de ser solo una propiedad del CVE. Tres de las cuatro variables describen el fallo y te vienen dadas. La primera no: la exposición del activo la decides tú, el día que instalas el aparato y cada vez que alguien abre un puerto «un momento». Es la única de las cuatro que puedes mover sin esperar a nadie, y mueve la ventana entera.

Nuestro recuento: «tres días» ya no quiere decir excepcional

En agosto ya contamos esto mismo sobre el fichero del catálogo y escribimos que el tramo corto se había comido a los demás: 42 de las 48 altas posteriores a la directiva llevaban tres días. Hemos vuelto a descargar el fichero hoy (versión 2026.11.10) para ver el año entero. Son 295 entradas:

Cinco meses después, el tramo corto se lleva algo más de la mitad del año entero. Y lo que en agosto era una tendencia ya se nota en la mesa: las dos de Barracuda van a tres días y el día cero de Outlook, que entró el mismo 10 de noviembre, va al 24. El plazo del catálogo ha dejado de servir para ordenar la cola, porque la mayoría lleva el mismo número. Si buscas otra señal en la ficha, tampoco: las trece entradas de noviembre llevan «Unknown» en el campo de uso conocido por campañas de ransomware.

Las cuatro variables, convertidas en cuatro preguntas tuyas

La directiva obliga a las agencias federales de Estados Unidos y no te obliga a ti. Pero el modelo es gratis y se puede usar. Esto es lo que preguntamos nosotros cuando entra un aviso así:

De las cuatro, la segunda, la tercera y la cuarta se leen en el aviso y en la ficha: están escritas antes de que tú llegues. La primera se contesta en frío, un martes cualquiera, con un escaneo desde fuera y una fecha apuntada. Si el día del aviso tienes que empezar por averiguar si el trasto está expuesto, el plazo ya da igual: llegas tarde por un motivo que no tiene nada que ver con Barracuda.

El ajuste que decide quién llega tarde

La documentación de la pasarela describe tres modos para Apply Patches, en Advanced > Firmware Update: Automatic, que «busca parches cada hora y los aplica automáticamente»; Manual, para aplicarlos a mano; y Disable, que hace que los parches «sean visibles pero no se apliquen». Y añade, textual: «Este es el modo por defecto». Hay un segundo matiz en la misma página: incluso en automático, si hace falta reiniciar, el aparato no se reinicia solo — «se te pedirá que reinicies el aparato para completar la actualización».

Junta las fechas con eso. El parche salió el 2 de noviembre. El catálogo registró la explotación el 10. Ocho días. Para un aparato que nadie sacó del modo por defecto, ocho días son ocho días de nada: el parche estaba listado en la interfaz, visible, esperando. No lo decimos como reproche al fabricante —que una pasarela de correo no se reinicie sola a las once de la mañana es una decisión razonable, y Barracuda recomienda activar el parcheo automático—. Lo decimos porque ese ajuste es tuyo y la mayoría no sabe cuál tiene puesto. Es una pregunta de un minuto que casi nadie se hace hasta que importa.

La pregunta que casi nadie puede contestar

Volvamos a la cuarta exigencia de la ficha: «dejar de usar el producto si no hay mitigaciones disponibles». Traducida a una empresa de 60 personas, es esta: ¿puedes sacar hoy este aparato del camino? Para una pasarela de correo la respuesta es un registro MX y una decisión de media hora. Y casi nunca está escrita en ningún sitio, porque nadie la ha necesitado nunca.

Aquí es donde esto deja de ser una noticia de CVE y se convierte en la misma conversación de siempre: el fallo es inevitable, la avería es una decisión de diseño. El fallo es que un fabricante publique un 9,3 en su pasarela —pasa, y le pasa a todos—. La avería es no tener ningún camino para tu correo que no atraviese la caja comprometida. Ese ejercicio lo hemos escrito ya dos veces este año con otras cajas: con la consola que gestiona todos tus equipos y con el plano de gestión de un firewall. Es el mismo patrón y cambia solo el nombre del producto: cuanto más central es la pieza, menos preparado está nadie para apagarla.

Cuándo NO correr

Cómo lo trabajamos nosotros

No somos resellers de una plataforma concreta: diseñamos, desplegamos y mantenemos infraestructura, y recomendamos según el caso. Así que de aquí no sacamos una marca de pasarela, sacamos cuatro decisiones. Que un aparato de seguridad no se confíe por el sitio donde está enchufado, que es la idea entera de Zero Trust. Que su interfaz de administración viva en la red de gestión y no en Internet. Que el inventario sepa qué versión corre cada caja y con qué modo de parcheo. Y que alguien mire de verdad su registro de cambios de configuración, que es la que nadie hace por buena voluntad y acaba siendo trabajo de un servicio gestionado de detección y respuesta con la telemetría del aparato dentro.

Y queda lo que de verdad cambia el resultado el día del aviso: tener escrito de antemano cómo se saca cada pieza central del camino. No porque vayas a hacerlo, que casi nunca se hace, sino porque llegará un día en que haya que decidirlo en veinte minutos y nadie improvisa bien a esa hora. Escribirlo cuesta una tarde. No tenerlo cuesta la tarde que no tienes.

Fuentes (verificadas el 12-nov-2026): fichero del catálogo de vulnerabilidades explotadas conocidas de CISA, versión 2026.11.10 (descripciones literales y fechas límite de CVE-2026-116606, CVE-2026-111560 y CVE-2023-2868; el recuento de plazos de 2026 es nuestro, hecho sobre ese fichero); directiva BOD 26-04 «Prioritizing Security Updates Based on Risk», 10-jun-2026 (las cuatro variables y las ventanas); aviso de Barracuda «Pre-Authentication Authorization Bypass and Command Injection Vulnerabilities in Certain Barracuda Products», 2-nov-2026, actualizado el 5 y el 9 (puntuaciones, productos, parches y recomendaciones); documentación del fabricante sobre «Apply Patches» (los tres modos y el modo por defecto).