La CISA añadió el 2 de octubre de 2026 a su catálogo de vulnerabilidades explotadas (KEV) dos fallas de Zammad, uno de los sistemas de tickets de código abierto más usados para mesas de ayuda: CVE-2026-102489, que permite secuestrar sesiones y ejecutar código sin credenciales, y CVE-2026-102490, que lleva al atacante hasta root. Encadenadas, dan control total del servidor.
Lo que hizo noticia no fueron solo las fallas, sino quién las usó y cómo. La víctima fue el DIVD, el instituto holandés que se dedica precisamente a avisar a empresas de vulnerabilidades, y según su propio análisis el ataque lo condujo un agente de IA autónomo.
Qué pasó, día por día
De acuerdo con la cronología que publicaron el DIVD y SecurityOnline:
| Fecha | Qué ocurrió |
|---|---|
| 21 sep | Ataque contra el servidor Zammad del DIVD |
| 22 sep | El DIVD lo detecta e inicia el análisis forense |
| 24 sep | Reporta las dos fallas a Zammad |
| 26 sep | Empieza a avisar a dueños de instalaciones expuestas |
| 30 sep | Lo hace público; BleepingComputer y SecurityWeek lo publican ese día |
| 1 oct | Zammad publica su postura en su foro oficial |
| 2 oct | La CISA añade ambas fallas al catálogo KEV |
| 5 oct | Zammad publica su aviso de seguridad formal |
Según BleepingComputer, en cuestión de segundos el atacante pasó de secuestrar una sesión a ejecutar código y escalar a root. Después leyó y se llevó datos; SecurityOnline reporta que entre ellos hay correos y posiblemente datos de contacto de los voluntarios del instituto, útiles para suplantarlos. Lo que impidió que llegara más lejos fue que la red estaba segmentada: la mesa de ayuda no tenía camino libre hacia lo demás.
El dato incómodo: el atacante era una máquina
El DIVD describe el ataque como "ruidoso y muy desordenado": el agente decidía solo cada paso, a toda velocidad y con lógica descuidada. Llegó a estorbarse a sí mismo mezclando un ataque de intermediario con intentos masivos de contraseñas, y dejó en sus scripts comentarios que justificaban cada decisión, lo que ayudó a los investigadores a reconstruirlo. No se ha atribuido a ningún grupo conocido.
No es un caso aislado. El 1 de octubre, BleepingComputer publicó la investigación de Transluce sobre agentes de IA que hicieron más de 200,000 peticiones a un sitio del Departamento de Educación de Estados Unidos el 17 de junio, con intentos rudimentarios de inyección SQL, y que hicieron sondeos parecidos en Biblioteca y Archivos de Canadá. Ahí no hubo intrusión. En el DIVD, sí.
La lección para una PyME no es que la IA sea invencible —este agente fue torpe—, sino que el tiempo entre que se descubre una falla y que alguien la explota se está encogiendo, y ya no hace falta un equipo de hackers sentados frente al teclado. Ya lo habíamos visto del lado del hackeo ético con modelos de IA.
Las versiones, con una advertencia
Las fuentes no coinciden del todo, así que va lo que dice cada una:
| Falla | Qué permite | Afectadas | Corrección |
|---|---|---|---|
| CVE-2026-102489 | Secuestro de sesión y ejecución de código sin credenciales | Rama 6: de 6.3.0 a 6.5.x (las fuentes difieren en si 6.5.4 está incluida) | Zammad: "la 7.0 y posteriores no están afectadas" |
| CVE-2026-102490 | Escalada del usuario zammad a root | De 1.5.0 a 7.1.0-alpha | Sin corrección definitiva al 7 oct; Zammad trabaja en ella |
Las calificaciones también varían: 8.7 y 8.5 por separado, 9.4 en el escenario crítico, según el registro que cita hol.org. Zammad, en su foro, precisó que la escalada a root no se puede explotar a distancia por sí sola: el atacante necesita estar ya dentro del servidor, que es justo lo que da la primera falla. Y pidió dejar de usar la 6.5 y anteriores.
El 5 de octubre Zammad publicó su aviso de seguridad formal. Ahí confirma que el cambio contra CVE-2026-102489 va incluido en la 7.2.0, pero sobre la escalada a root dice que la sigue analizando como prioridad, que está relacionada con una vulnerabilidad confirmada en packager.io (el servicio con el que se generan sus paquetes de instalación) y que trabaja en una solución. Su recomendación por ahora: actualizar a Zammad 7.2.0 y dejar el acceso al servidor solo a administradores de confianza.
Un día después, el 6 de octubre, Zammad publicó la 7.2.1, una actualización de seguridad que corrige 27 fallas distintas (entre ellas un salto de la autenticación de dos factores, ejecución remota de código e inyección SQL). Sus notas de versión no mencionan CVE-2026-102490, y en un análisis publicado ese mismo día Sysdig indicaba que, al 5 de octubre, la escalada a root seguía sin corrección. Al 7 de octubre, el aviso de Zammad seguía sin actualizarse y su página de versiones no mostraba nada posterior a la 7.2.1. En resumen: la 7.2.1 es la versión a instalar, pero no cierra la escalada.
Qué hacer esta semana
- Averigua si tienes Zammad. Muchas empresas no lo instalaron ellas: lo puso el proveedor de soporte, el integrador o el área de sistemas de un corporativo. Pregunta por escrito.
- Si está en la rama 6, actualiza o apágalo. Es lo que recomienda el DIVD. Zammad pide dejar de usar la 6.5 y anteriores.
- Si ya estás en la 7, sube a 7.2.1 (la versión de seguridad del 6 de octubre) y limita quién entra al servidor. La corrección de la escalada a root todavía no sale: revisa el aviso de Zammad hasta que la publique.
- Corre el script de revisión del DIVD sobre los registros para buscar señales de intrusión desde el 21 de septiembre.
- Si encuentras algo, cambia todas las contraseñas de agentes y administradores, revisa qué datos guardaba la mesa de ayuda (con frecuencia hay contraseñas que los usuarios mandaron en un ticket) y sigue tu plan de incidentes; si no tienes uno, el kit de ciberseguridad básico es un punto de partida.
- Sácala de internet si no necesita estar ahí. Si solo la usan empleados, ponla detrás de una VPN o de un acceso de confianza cero.
- Sepárala del resto de la red. Fue la segmentación lo que salvó al DIVD de un daño mayor.
En contexto
Octubre, el mes de la ciberseguridad, arrancó con el mismo patrón que cerró septiembre: sistemas instalados una vez, expuestos a internet y fuera del ciclo de parches. La diferencia ahora es la velocidad. Si una herramienta de tu empresa lleva más de un año sin actualizarse, ya no es una tarea pendiente: es una puerta abierta, y quien la empuje puede no ser una persona.
