Zammad: fallas explotadas en el helpdesk obligan a actualizar a 7.2.0
Dos vulnerabilidades de Zammad (CVE-2026-102489 y CVE-2026-102490) se usaron en cadena para tomar control total de servidores. Qué versiones están en riesgo, qué recomienda el fabricante y qué hacer hoy si tu pyme usa este helpdesk.
6 min de lectura Investigado y publicado con Claude
En este artículo
Si tu empresa usa Zammad como mesa de ayuda y lo tiene instalado en un servidor propio, revisá hoy qué versión tiene. Dos fallas, CVE-2026-102489 y CVE-2026-102490, se usaron juntas en un ataque real para pasar de secuestrar una sesión a tener control total (root) del servidor. El 5 de octubre de 2026, Zammad recomendó actualizar a la versión 7.2.0 y limitar el acceso al servidor solo a administradores de confianza. Las instalaciones en versiones anteriores a la 7.0 son las más expuestas.
Qué pasó#
El ataque lo sufrió el propio DIVD (Dutch Institute for Vulnerability Disclosure), una organización neerlandesa que coordina avisos de seguridad y que usa Zammad como helpdesk. Según el caso DIVD-2026-00015, las fallas se identificaron entre el 21 y el 23 de septiembre de 2026, se reportaron a Zammad el 24 de septiembre y desde el 26 el DIVD empezó a avisar a los dueños de instalaciones vulnerables.
El 2 de octubre, la agencia de ciberseguridad de Estados Unidos (CISA) agregó las dos fallas a su catálogo de vulnerabilidades explotadas. Ese catálogo solo incluye fallas con explotación confirmada, por eso conviene tratarlo como una señal de urgencia.
Un dato que llamó la atención: el DIVD contó que los atacantes pudieron secuestrar sesiones, ejecutar código y pasar de una cuenta común de Zammad a root en segundos, y atribuyó esa velocidad a un flujo de ataque automatizado con IA. Es decir: entre que alguien encuentra tu servidor y lo compromete puede no haber margen para reaccionar.
Las dos fallas, en simple#
CVE-2026-102489: secuestro de sesión#
Permite a un atacante remoto apropiarse de la sesión de un usuario de Zammad y, desde ahí, ejecutar comandos en el servidor con los permisos del usuario del sistema "zammad". Según el DIVD, es explotable en las versiones 6.3.0 a 6.5.4. En las versiones 7.0.0 a 7.1.3 el defecto existe, pero no se puede aprovechar por las condiciones del entorno. Zammad lo resume así: las versiones 7.0 y posteriores no están afectadas en la práctica.
CVE-2026-102490: escalada a root#
Permite que el usuario "zammad" del sistema obtenga permisos de root. El DIVD indica que afecta desde la versión 1.5.0 hasta la 7.1.0-alpha, y Zammad dice que impacta a todas las versiones. La aclaración importante del fabricante: no se puede explotar de forma remota por sí sola; el atacante necesita tener acceso previo al servidor. El problema es que la primera falla le da justamente ese acceso.
| Falla | Qué permite | Versiones en riesgo |
|---|---|---|
| CVE-2026-102489 | Secuestrar una sesión y ejecutar código como usuario "zammad" | Explotable en 6.3.0 a 6.5.4 |
| CVE-2026-102490 | Pasar del usuario "zammad" a root | Todas, según Zammad (requiere acceso previo) |
Las fuentes no coinciden en el puntaje de gravedad (CVSS): algunas publicaron 9.4 y otras 8.7. Por eso no lo usamos para decidir: lo que pesa es que hay explotación confirmada.
Por qué le importa a una pyme#
El helpdesk concentra información sensible: nombres, correos y teléfonos de clientes, historiales de reclamos, archivos adjuntos y, muchas veces, integraciones con el correo, el CRM o WhatsApp. Si alguien toma el servidor, no solo lee esos datos: puede usar las credenciales guardadas para saltar a otros sistemas.
Además, una filtración de datos de clientes puede tener implicancias legales en materia de datos personales. Por eso un incidente en el helpdesk no es solo un problema técnico.
Si tu Zammad lo administra un proveedor, la tarea es preguntarle hoy qué versión corre y si ya aplicó la recomendación del fabricante.
Qué hacer ahora#
- Identificá tus instalaciones. Anotá dónde corre Zammad, qué versión tiene (se ve en la configuración del sistema) y si es accesible desde internet.
- Guardá los registros antes de tocar nada. El DIVD publicó un script para revisar los logs de Zammad en busca de señales de compromiso. Hacé una copia de los logs y corré la revisión.
- Actualizá a Zammad 7.2.0. Es la versión que recomienda el fabricante. Si no podés actualizar ya, el DIVD aconseja directamente sacar la instalación de línea hasta hacerlo.
- Cerrá el acceso al servidor. Limitá el SSH y el panel de administración a personas e IP de confianza. Si el helpdesk no necesita estar abierto a todo internet, ponelo detrás de una VPN o de un proxy con control de acceso.
- Rotá credenciales si hubo exposición. Si tu instancia estuvo en las versiones 6.3.0 a 6.5.4 y accesible desde internet, cambiá contraseñas de administradores, tokens de API y claves de las integraciones (correo, CRM, mensajería). En nuestra guía sobre cómo proteger las claves de API de tu pyme tenés el paso a paso.
- Revisá sesiones y usuarios. Buscá administradores nuevos, sesiones raras o cambios de configuración que nadie recuerde haber hecho.
- Seguí los avisos del fabricante. Zammad remite a su aviso oficial de seguridad; si publica un cambio específico para la escalada a root, aplicalo apenas salga.
Si ya pasaste por esto con otros servicios expuestos, el procedimiento es parecido al que explicamos para actualizar n8n self-hosted por sus vulnerabilidades y para el zero-day de Citrix NetScaler: inventario, copia de registros, parche y revisión.
Preguntas frecuentes#
¿Uso Zammad 7.x, estoy a salvo?#
En la práctica, la falla de secuestro de sesión no se puede explotar desde la 7.0 según Zammad y el DIVD. Igual, el fabricante recomienda pasar a 7.2.0 y restringir el acceso al servidor, porque la escalada a root afecta a todas las versiones.
¿Qué pasa si sigo en la versión 6?#
Es el escenario de mayor riesgo, sobre todo entre 6.3.0 y 6.5.4 con acceso desde internet. Actualizá o desconectá la instalación hasta poder hacerlo, y revisá los registros por si ya hubo un acceso indebido.
¿Cómo sé si me atacaron?#
No hay indicadores públicos como IP o dominios. La herramienta disponible es el script del DIVD para revisar los logs, más la revisión manual de sesiones, usuarios y cambios recientes.
¿Tengo que avisar a mis clientes?#
Depende de si hubo acceso a datos personales. Si encontrás señales de compromiso, consultá con tu asesor legal sobre las obligaciones en materia de datos personales antes de comunicar.
¿Necesitás ayuda?#
En Mark-Co Digital revisamos y endurecemos servidores, configuramos copias de seguridad y protección de accesos y administramos la infraestructura cloud donde corren tus sistemas. Si querés que tu atención al cliente automatizada funcione sobre una base segura, escribinos.
Fuentes#
- Zammad Security Update on DIVD Case DIVD-2026-00015 (Zammad Community, 5/10/2026)
- DIVD-2026-00015: Zammad (DIVD CSIRT)
- U.S. CISA adds Zammad flaws to its Known Exploited Vulnerabilities catalog (Security Affairs)
- Zammad vulnerabilities: Find impacted installations (runZero)
- CVE-2026-102489 (Rapid7 Vulnerability Database)