Barracuda ESG sufre ataques que dan root y CISA da tres días de plazo

Basta una petición POST a /cgi-mod/index.cgi con un cambio de contraseña que falla a propósito. Con eso arranca la cadena que convierte un Barracuda Email Security Gateway sin parchear en una shell de root sin credenciales, y Barracuda reconoció en la madrugada del 10 de noviembre de 2026 (hora peninsular) que ya se usa contra «a small number of organizations» (un número reducido de organizaciones). Horas después, CISA incorporó CVE-2026-116606 y CVE-2026-111560 a su catálogo KEV con plazo hasta el 13 de noviembre para las agencias federales estadounidenses.

• Dos fallos del Email Security Gateway de Barracuda, un salto de autorización (CVE-2026-116606, CVSS 9,3) y una inyección de comandos (CVE-2026-111560, CVSS 8,6), dan root sin credenciales a quien alcance la interfaz de administración.
• Barracuda confirmó la explotación el 9 de noviembre y CISA los incluyó en KEV el 10 con plazo del 13 de noviembre. Previdian cuenta 17 intentos desde 15 direcciones IP.
• La inyección de comandos afecta también a Load Balancer ADC, WAF, Web Security Gateway, Message Archiver y WAF Control Center, con parche propio para cada uno.
• Parche BNSF-40425 o BNSF-40430 en el ESG, firmware 9.4.0.030 y consola de administración fuera de internet. watchTowr publicó el 5 de noviembre una herramienta que ejecuta la cadena completa.

Un cambio de contraseña fallido, un checksum con secreto fijo y un sed que corre como root

La cadena la reconstruyó Sina Kheirkhah, de watchTowr Labs, comparando el firmware 9.4.0.027 del ESG con el 9.4.0.029 y leyendo los dos parches en Perl que Barracuda distribuyó. Su análisis del 5 de noviembre sitúa el primer fallo en Index.pm, el módulo que atiende los cambios de contraseña de la interfaz web. Cuando el cambio falla con el error ERROR_PASSWD_CHANGE, el código anterior al parche devuelve el rol de la sesión actual en lugar de cortar la petición, y una sesión sin autenticar lleva el rol de la pantalla de login. Con ese rol en la mano, la función response() sigue ejecutando los manejadores de módulo que vienen detrás, y ahí es donde el atacante encadena la segunda pieza.

Esa segunda pieza es bayesian_upload.pm, un manejador de subida de ficheros que entrega lo que recibe a Backup2::restore_all, la rutina que desempaqueta y restaura una copia de seguridad de la configuración. Un backup del ESG es un tar con un fichero backup.xml que lista componentes, y uno de ellos, Spam_Config, carga un volcado de MySQL y lo escribe en la base de datos local del equipo. Entre las filas que restaura está system_timezone, la zona horaria del sistema.

Cada fichero del backup lleva un checksum y la restauración lo comprueba. El problema, según watchTowr, es que ese checksum es un MD5 de los bytes del fichero más una cadena secreta que está fija en el código del producto, igual en todos los equipos. Quien conozca la cadena puede firmar cualquier backup que fabrique.

El diff que publicó watchTowr muestra la última pieza. En Backup2.pm, la función finalize_restore pasaba el valor de system_timezone a una orden sed en backticks de Perl, es decir, a una shell, y el parche lo sustituye por una lectura y escritura del fichero en Perl que antes comprueba que la zona exista en /usr/share/zoneinfo. La misma variable llega a fix_tz.pl, que actualiza /etc/sysconfig/clock con otro sed y que el propio producto ejecuta a través de sudo. Kheirkhah lo resume como una inyección de comandos «one that executes as root» (que se ejecuta como root).

El valor de la zona horaria viaja por lo tanto desde un backup que nadie ha autenticado hasta dos invocaciones de shell con privilegios de root. watchTowr demostró la cadena escribiendo un fichero en el equipo como root y publicó en GitHub su generador de artefactos de detección, un script en Python que construye el backup, lo sube y ejecuta la orden que se le pase. La herramienta se presenta como detección, pero hace exactamente lo que haría un exploit, y eso explica que desde el 5 de noviembre cualquiera con acceso a la interfaz de administración de un ESG sin parche tenga el camino hecho.

Dos CVE firmados por Mandiant y un aviso que cambió de opinión sobre la autenticación

Los dos identificadores los asignó Mandiant como CNA. Sus fichas de divulgación recogen que Barracuda le comunicó la inyección de comandos el 15 de octubre y el salto de autorización el 22 de octubre, y que ambos CVE se publicaron el 2 de noviembre junto con el aviso de Barracuda. La ficha MNDT-2026-0042 describe CVE-2026-116606 como un salto de autenticación que permite a un atacante remoto sin credenciales invocar la función de importación de configuración y restaurar un backup compatible fabricado a medida. La MNDT-2026-0041 describe CVE-2026-111560 como la falta de neutralización de metacaracteres de shell en el campo de zona horaria, en código común a varios productos de Barracuda.

NVD tenía los dos registros desde el 2 de noviembre, pero el 11 de noviembre a las 05:19 UTC seguían en estado de análisis, sin puntuación propia del NIST. Las notas que aparecen son las de Mandiant en CVSS 4.0, y así las recogen el catálogo KEV y la ficha de CVE-2026-116606 en NVD, que ya incorpora la fecha de inclusión en KEV y el plazo del 13 de noviembre.

La captura que watchTowr tomó del aviso el día de su publicación muestra un detalle que Barracuda corrigió después. El 2 de noviembre la ficha de CVE-2026-116606 decía que hacía falta autenticación con acceso administrativo, pese a que el tipo de fallo que anunciaba era un salto de autorización previo a la autenticación. El 5 de noviembre a las 20:30 hora peninsular Barracuda cambió ese campo a no requerida, con la matización de que el atacante necesita alcanzar la interfaz de administración. En el comentario del instalador del parche que leyó watchTowr, la puntuación que figura es 9,8 y no 9,3, una diferencia que el laboratorio atribuye a que alguien puntuó las dos vulnerabilidades juntas, «which CVSS experts will quickly recognize as a crime» (algo que los expertos en CVSS reconocerán enseguida como un crimen).

Hay otra discrepancia que conviene tener presente al comprobar un equipo. Mandiant y el Centro Canadiense de Ciberseguridad dan por afectado todo ESG anterior a 9.4.0.030, mientras que la tabla de watchTowr sitúa la corrección en 9.4.0.029, la versión que diffearon. El aviso de Barracuda no nombra ninguna versión de firmware corregida y habla solo de parches, BNSF-40425 para los ESG en 9.4.017 o posterior y BNSF-40430 para los anteriores, y las notas de versión públicas de 9.4.0.029 y 9.4.0.030 no mencionan ninguno de los dos CVE. Si el equipo está en 9.4.0.030 o aplica BNSF-40425, las dos lecturas coinciden en que está cubierto.

Lo que Barracuda, CISA y Previdian saben de los ataques y lo que ninguno cuantifica

La nota de explotación llegó al aviso de Barracuda el 9 de noviembre a las 21:00 hora de la costa este de Estados Unidos, las 03:00 del 10 de noviembre en España. Barracuda no dice cuántas organizaciones, ni desde cuándo, ni qué hicieron los atacantes una vez dentro. The Register preguntó y obtuvo una respuesta de portavoz: la empresa trabajó directamente con los afectados y publicó parches con rapidez, sin cifra. El mismo artículo de The Register recoge la reacción de Tausif Ahmed, fundador de Purplecop Security, sobre la interfaz de administración expuesta a internet: «that's the first thing I'd close today» (es lo primero que cerraría hoy).

CISA tampoco aporta detalles. Su alerta del 10 de noviembre añadió seis entradas al catálogo KEV, y solo las dos de Barracuda reciben el plazo de tres días que la directiva BOD 26-04 reserva para fallos en activos expuestos que entregan el control total del sistema. Las otras cuatro, el zero-day de Outlook que contamos esta mañana, un use-after-free de Chromium, una XXE de Cisco BroadWorks y un fallo del transcodificador Webtop de Openwave, tienen hasta el 24 de noviembre. Es el mismo plazo corto que CISA aplicó hace una semana al actualizador de WordPress, y la descripción del catálogo deja constancia de que los dos CVE de Barracuda se encadenan entre sí. El Centro Canadiense de Ciberseguridad actualizó su aviso AV26-1112 el mismo 9 de noviembre con una frase que resume el estado de la información pública: «Open source reporting indicates that CVE-2026-116606 is exploited in the wild» (fuentes abiertas indican que se explota en la naturaleza).

La única telemetría con números la aporta Previdian, la firma que ya puso cifras a los intentos contra OpenSSH y N-central en las dos últimas semanas. Según SecurityWeek, Previdian observó 17 intentos de explotación de CVE-2026-116606 entre el 9 y el 11 de noviembre, procedentes de 15 direcciones IP de tres países. Cuando se escribió esta noticia Previdian no había publicado entrada propia sobre Barracuda en su blog, y SecurityWeek no reproduce las direcciones ni los países.

Quién está expuesto, de los seis productos con la inyección al silencio de INCIBE-CERT

El salto de autorización solo existe en el Email Security Gateway, el appliance físico o virtual que filtra el correo antes de entregarlo al servidor. Sin él, CVE-2026-111560 necesita una sesión de administrador, y así afecta a otros cinco productos que comparten el mismo código de zona horaria. Mandiant enumera como vulnerables el ESG hasta 9.4.0.27, el Load Balancer ADC hasta 6.4.0, el Web Application Firewall hasta 11.0.1, el Web Security Gateway hasta 16.1.100.100, el Message Archiver hasta 5.5.4.0 y el WAF Control Center hasta 2.2.1. El aviso de Barracuda asigna a cada uno su parche.

Lo que marca la diferencia entre un ESG atacable desde fuera y uno que no lo es no es la versión, es dónde responde su interfaz de administración. Barracuda lo dice en su aviso y en la nota de Campus del 2 de noviembre, y es la misma lección que el blog contó con los FortiGate de FortiBleed y con el RCE del Secure Email Gateway de Cisco, otra pasarela de correo atacada en octubre. Un ESG que solo exponga el puerto SMTP a internet no está al alcance de esta cadena. Uno cuya consola web sea accesible desde cualquier dirección, sí.

No hay recuento público de cuántos ESG tienen la consola a la vista. A 11 de noviembre, ni Shadowserver ni Censys ni GreyNoise habían publicado cifras sobre estos dos CVE, y los informes de los laboratorios que los han analizado tampoco las dan. En España, INCIBE-CERT y CCN-CERT no habían publicado aviso sobre el boletín de Barracuda del 2 de noviembre ni sobre su actualización del 9, aunque INCIBE-CERT sí dedicó una entrada de bitácora al zero-day del ESG de 2023. El ESG es el filtro de correo en appliance de Barracuda, el producto que elige quien mantiene el correo en servidores propios en lugar de contratarlo como servicio en la nube.

Aplicar BNSF-40425 hoy, cerrar la consola y buscar un backup que nadie subió

Para saber si un ESG concreto sigue vulnerable, el generador de artefactos de watchTowr admite una orden inocua como touch /tmp/test, aunque conviene recordar que ejecuta esa orden como root en el equipo y que cualquier prueba debe hacerse con autorización y fuera de producción.

La captura del README muestra la salida del script en una ejecución de prueba. Construye un backup de 10.240 bytes, lo sube y devuelve Done. Si eso funciona contra tu equipo, cualquiera con acceso a la consola puede hacer lo mismo, y el orden de trabajo, por urgencia, es este.

1. Comprueba la versión del firmware y el estado de los parches en la consola del ESG. Si el equipo está en 9.4.017 o posterior aplica BNSF-40425, si es anterior aplica BNSF-40430, y en cualquier caso deja el firmware en 9.4.0.030, la versión que Mandiant y el Centro Canadiense de Ciberseguridad dan por corregida. Barracuda recuerda que, si el parcheo automático estaba desactivado, hay que aplicarlo a mano y volver a activarlo.
2. Saca la interfaz de administración de internet antes de parchear, no después. Restringe el acceso a la consola web a las redes internas de confianza con listas de control de acceso en el firewall perimetral. El tráfico SMTP puede seguir entrando, la consola no.
3. Parchea los otros cinco productos aunque en ellos el fallo requiera administrador. BNADC-16586 en Load Balancer ADC y WAF, BNMA-32468 en Message Archiver, BNWF-60060 en WAF Control Center y BNYF-24789 en Web Security Gateway.
4. Busca rastro de la cadena. La explotación pasa por una restauración de configuración que el administrador legítimo no hizo y por un valor de zona horaria que no es un nombre válido de /usr/share/zoneinfo. Revisa la zona horaria configurada en el equipo y cualquier restauración o cambio de configuración global registrado desde el 2 de noviembre.
5. Si la consola ha estado expuesta y el parche llegó después del 9 de noviembre, trata el equipo como comprometido hasta demostrar lo contrario, rota las credenciales de administración y las del servicio LDAP o Active Directory que use el ESG, y avisa a INCIBE-CERT (empresas) o al CCN-CERT (sector público).

Si la consola del ESG estaba detrás de un proxy inverso o de un firewall que registra las peticiones HTTP, este filtro saca las peticiones POST al endpoint que usa la cadena desde direcciones que no son de tu red interna. Ajusta los rangos privados a los tuyos.

grep -E 'POST /cgi-mod/index\.cgi' access.log \
  | grep -vE '^(10\.|192\.168\.|172\.(1[6-9]|2[0-9]|3[01])\.)'

Una petición de cambio de contraseña seguida de una subida de fichero desde la misma dirección externa, en el mismo minuto y sin un login correcto entre medias, es la secuencia que describe watchTowr.

Tres entradas de Barracuda en KEV y un precedente de 2023 que acabó cambiando equipos

Con estas dos, Barracuda suma tres entradas en el catálogo KEV. La primera fue CVE-2023-2868, el zero-day del mismo Email Security Gateway que CISA incluyó el 26 de mayo de 2023. Aquella campaña la atribuyó Mandiant al grupo UNC4841, que valora con alta confianza como espionaje en apoyo de la República Popular China, con una explotación que empezó en octubre de 2022 y que Barracuda no parcheó hasta el 20 de mayo de 2023. Mandiant cifró el alcance en el 5 % de los ESG del mundo y señaló que «Almost a third of identified affected organizations were government agencies» (casi un tercio de las organizaciones afectadas identificadas eran agencias gubernamentales). La respuesta entonces fue inusual: Barracuda pidió sustituir los equipos comprometidos en lugar de reinstalarlos, y el FBI respaldó la sustitución en un aviso de agosto de 2023.

Nadie ha relacionado los ataques de noviembre de 2026 con aquel grupo ni con ningún otro. Ni Barracuda, ni CISA, ni los laboratorios que han publicado análisis atribuyen la actividad, y los 17 intentos de Previdian son demasiado pocos y demasiado recientes para dibujar un patrón. Lo que sí comparten las dos historias es el producto, el vector y el tipo de organización que lo compra, y en 2023 la explotación llevaba siete meses en marcha cuando llegó el parche. Esta vez el aviso salió antes que los ataques conocidos y entre el parche y la explotación confirmada pasaron siete días. Es la secuencia que el blog ha contado este otoño con los zero-days de Ivanti Connect Secure y con el fallo de BeyondTrust Remote Support, appliances de perímetro cuyo aviso del fabricante llegó cuando alguien ya los estaba usando.

La parte que no está resuelta es la del secreto fijo del checksum. El parche de Barracuda valida la zona horaria y corta el cambio de contraseña fallido, y con eso cierra la cadena publicada. No consta que haya cambiado la forma de firmar los backups, y mientras ese secreto siga siendo el mismo en todos los equipos, cualquier otra ruta que permita colar un fichero en Backup2::restore_all heredará el problema. A primera hora del 11 de noviembre (05:19 UTC) NVD seguía sin puntuar ninguno de los dos CVE, y Barracuda seguía sin decir a cuántos clientes ha tenido que atender.