Zammad: dos fallas en cadena, CVE-2026-102489 y 102490

El 2 de octubre CISA agregó al catálogo de vulnerabilidades explotadas dos fallas de Zammad, la mesa de ayuda de código abierto que muchas organizaciones instalan en su propio servidor en lugar de pagar un servicio. El plazo vence el 5 de octubre, y las dos entradas dicen algo que no es habitual leer en ese catálogo: que se encadenan entre sí.

Son las primeras entradas de Zammad en toda la historia del catálogo.

Cómo se encadenan CVE-2026-102489 y CVE-2026-102490

Cada ficha del catálogo nombra a la otra, lo que es poco frecuente y en este caso es el dato central.

Ese último punto es la lección transferible de la nota, y vale más que el caso puntual. Un puntaje describe una vulnerabilidad. Cuando dos se completan, el riesgo real es el de la combinación, y no hay casilla donde eso figure. Por eso conviene desconfiar del reflejo de ordenar una lista por puntaje y atender de arriba hacia abajo: una falla "media" que es la pieza que faltaba puede importar más que una "alta" aislada.

DIVD, que reportó las fallas, dice que las usaron para entrar a DIVD

Acá está lo que le da peso a la afirmación de explotación activa, y es inusual. Las dos fallas las reportó DIVD, el instituto neerlandés de divulgación de vulnerabilidades, que además figura como la autoridad que numeró los CVE. Y en su propia ficha del caso, DIVD anota como hecho del 21 de septiembre: "Vulnerability abused to breach DIVD".

O sea que quien reporta no está describiendo un hallazgo de laboratorio: describe cómo entraron a su propia casa.

Eso explica también por qué DIVD se movió como se movió: a los 2 días de reportarlo al fabricante ya estaba notificando a dueños de instancias vulnerables, sin esperar a que hubiera corrección. Es una decisión discutible y de hecho está discutida, como se ve enseguida.

Zammad y DIVD no dicen lo mismo sobre CVE-2026-102490

Esta parte hay que contarla con cuidado, porque son afirmaciones de partes distintas y conviene que se sepa cuál es cuál. No es la primera vez que el sitio se encuentra con esta situación: ya pasó con la falla de SharePoint que CISA catalogó y Microsoft discutió. Lo que sigue es quién dijo qué, no una conclusión mía.

Dos aclaraciones de método sobre esa tabla, porque importan.

La primera: las dos citas atribuidas al foro salen de respuestas en el foro de la comunidad de Zammad, y en la página no se muestra ninguna insignia de rol junto a los nombres de quienes las escribieron. Están redactadas en primera persona del plural y en nombre del proyecto, pero no pude confirmar desde esa página que quienes publican lo hagan en calidad oficial, así que no las presento como un comunicado de la empresa. Las presento como lo que verifiqué que son: posiciones publicadas en el foro del propio proyecto.

La segunda, y es la que cambia la lectura: ese mismo 1 de octubre, más tarde, otra respuesta del foro dice que DIVD ya entregó los detalles técnicos y que empezaron a trabajar, y agrega que la falla de escalada "cannot be exploited remotely on its own. An attacker would already need access" al servidor. O sea que la discrepancia sobre la segunda falla se destrabó en horas. Lo dejo anotado porque publicar la pelea sin publicar el desenlace sería quedarse con la mitad.

Y ese detalle encaja con lo que ya se vio arriba: la escalada necesita acceso previo, y la primera falla de la cadena es la que lo provee.

Qué corrige la 7.2.0 de Zammad y qué queda sin parche

Esa es la buena noticia dentro de un caso incómodo: lo que hay que hacer es lo mismo según las dos partes. DIVD dice pasar a la versión 7 o sacar el sistema de línea; el foro del proyecto dice actualizar a la 7.2.0. Coinciden. Y la 7.2.0 no es una versión que haya que esperar: se publicó el 23 de septiembre, 7 días antes de que se publicaran los CVE.

Que la escalada a root no tenga corrección es un problema real, pero es el segundo problema. Mientras nadie pueda ejecutar código como el usuario zammad, no hay desde dónde escalar.

¿A quién afecta la cadena de Zammad?

A quien tenga Zammad instalado en su propio servidor en una versión de la rama 6, sobre todo entre la 6.3.0 y la 6.5.4. Conviene tener presente una fecha: la 6.5.4 es del 8 de abril de 2026, así que una instalación que no se tocó desde entonces está en el rango.

Es un perfil concreto y bastante común: la organización que necesitaba una mesa de ayuda, eligió software libre para no pagar licencias por agente, lo instaló una vez y lo dejó andando. Lo mismo que el sitio planteó en Zimbra y TrueConf: el software que instalás vos deja el parche en tus manos, y esa es la parte del costo que no aparece en la comparación inicial.

Un agravante propio de este tipo de sistema: una mesa de ayuda guarda las conversaciones con los clientes, con lo que haya en ellas, y los agentes tienen permisos elevados sobre esos datos. Si además el objetivo final de la cadena es root en el servidor, lo que está en juego no es solo el sistema de tickets sino la máquina donde corre, con lo demás que haya ahí. Y si la máquina quedó comprometida, el camino es el largo, como en la nota de NetScaler de esta semana.

¿Quién puede ignorar las fallas de Zammad?

Quien no use Zammad, y quien use la versión alojada por el proveedor en lugar de una instalación propia, porque ahí la actualización no pasa por el usuario.

Quien ya esté en 7.2.0 está cubierto de la mitad que se explota por red, que es la que importa hoy.

Lo que no alcanza para ignorarlas: estar en la rama 7 pero por debajo de la 7.2.0. Según DIVD la primera falla está presente en 7.0.0 a 7.1.3, aunque no explotable por condiciones del entorno, y según el foro del proyecto el endurecimiento del código recién llega en la 7.2.0. Con dos descripciones que no coinciden del todo sobre tu rama, lo prudente es ir a la versión donde las dos coinciden en que está resuelto.

¿Cómo sé qué versión de Zammad tengo y si entraron?

1. La versión se ve en el panel de administración, en la sección de información del sistema, y también desde la consola del servidor. Si empieza con 6, estás en la rama vieja.
2. Si el sistema es alcanzable desde internet. Una mesa de ayuda suele estarlo a propósito, porque los clientes cargan tickets. Eso es parte de su función, así que acá no aplica el consejo habitual de sacarla de internet: lo que aplica es actualizar.
3. Si quedó algo. La cadena termina en root, así que lo que hay que buscar no está solo en Zammad: hay que mirar el servidor. Procesos, tareas programadas y claves de acceso agregadas que nadie reconozca, y accesos de la cuenta del sistema en horarios raros. Si encontrás cualquiera de esas cosas, el camino ya no es actualizar, y vale el mismo razonamiento que en la nota de GitLab: el parche cierra la puerta, no echa a quien entró.

Una advertencia sobre las fuentes, porque en este caso circuló información confusa: el mensaje que abrió el hilo del foro afirmaba rangos de versiones y condiciones de ataque que no coinciden con lo que dicen la ficha del caso de DIVD ni los registros de los CVE, y citaba notas de prensa. Para decidir qué hacer con tu instalación, las fuentes son la ficha del caso de DIVD y las publicaciones del proyecto, no un resumen de tercera mano.

¿Qué hago si tengo Zammad en mi servidor?

1. Averiguá la versión. Es una pantalla y define todo lo demás.
2. Si estás en la rama 6, actualizá a la 7.2.0. Es el único paso que cierra la mitad explotable por red, y es lo que recomiendan las dos partes. Tené en cuenta que pasar de la rama 6 a la 7 es un salto de rama, así que corresponde copia de seguridad previa y una prueba de que los tickets siguen ahí después.
3. Si estás en la rama 7 por debajo de la 7.2.0, actualizá igual a la 7.2.0, que es una actualización menor.
4. Si no podés actualizar hoy, la recomendación de DIVD es explícita y vale leerla aunque incomode: "upgrade to version 7 of Zammad or to take it offline". Para una mesa de ayuda, sacarla de línea tiene costo operativo real, y es una decisión de negocio que conviene tomar con el número de versión a la vista.
5. Revisá el servidor, no solo la aplicación, por el final de la cadena.
6. Seguí las publicaciones de seguridad del proyecto para la segunda falla, que al momento de escribir esto no tiene versión corregida según DIVD.

Los términos están en el glosario, y otros casos recientes de equipos y aplicaciones expuestas, en las notas de Fortinet FortiMail y Cisco SD-WAN Manager.

Preguntas frecuentes sobre CVE-2026-102489 y Zammad

Si la escalada a root no tiene parche, ¿sirve de algo actualizar?

Sirve, y es lo principal que hay que hacer. Las dos fallas funcionan como una cadena: la primera da ejecución de código como el usuario del sistema, y la segunda convierte ese acceso en root. Si cerrás la primera, nadie llega al punto desde el cual se escala. Una respuesta en el foro del proyecto dice además que la escalada "cannot be exploited remotely on its own" y que haría falta acceso previo, lo que es coherente con ese razonamiento. La escalada sigue siendo un problema a resolver, pero no es la vía de entrada.

¿Por qué CISA dice que está explotada y el fabricante no lo confirmaba?

Porque son dos cosas distintas. CISA cataloga a partir de evidencia de explotación, y en este caso quien reportó las fallas es una organización que dice que las usaron para entrar a su propia infraestructura el 21 de septiembre. Del otro lado, una respuesta en el foro del proyecto del 1 de octubre decía que todavía no había recibido los detalles técnicos de la segunda falla y que no podía verificar lo que no le habían mostrado. Más tarde ese mismo día, otra respuesta en el mismo foro dice que los detalles llegaron y que se pusieron a trabajar. No es una contradicción sobre los hechos: es el reflejo de dos organizaciones en distintos momentos de información.

Tengo la rama 7, ¿tengo que hacer algo?

Si estás por debajo de la 7.2.0, sí: actualizá. La ficha de DIVD dice que la primera falla está presente de la 7.0.0 a la 7.1.3 aunque no sea explotable por condiciones del entorno, y la posición publicada en el foro del proyecto dice que el endurecimiento del código llega en la 7.2.0. Cuando las dos descripciones no coinciden exactamente sobre tu rama, la salida sensata es moverse a la versión donde ninguna de las dos deja dudas.

¿Esto significa que el software libre es menos seguro?

No es la conclusión que se puede sacar de acá. Esta semana el sitio cubrió fallas explotadas en productos comerciales de Cisco, Fortinet, Citrix y Apple, todos con contrato y soporte pago. La diferencia no está en la licencia sino en quién queda a cargo de aplicar la corrección: en un servicio alojado lo hace el proveedor, y en algo que instalaste en tu servidor lo hacés vos, sea libre o pago. Lo que conviene mirar al elegir no es el precio de la licencia sino si tenés a alguien que vaya a actualizarlo.

Mi Zammad es interno, no lo ve internet. ¿Estoy tranquilo?

Estás mejor, pero una mesa de ayuda puramente interna es menos común de lo que parece, porque el valor del sistema está en que los clientes puedan cargar tickets. Si de verdad solo es alcanzable desde tu red, la mitad remota de la cadena necesita que el atacante ya esté adentro, lo que baja bastante la urgencia. No la elimina: cualquier equipo comprometido de tu red cumple esa condición, y la cadena termina en root en el servidor donde corre.