Zammad: dos zero-day contra el DIVD en un ataque con agentes IA

El Dutch Institute for Vulnerability Disclosure (DIVD), la organización neerlandesa de voluntarios que comunica de forma responsable las vulnerabilidades encontradas en sistemas expuestos, ha hecho público que también ha sido vulnerada. Los atacantes entraron por su helpdesk Zammad con dos vulnerabilidades hasta entonces desconocidas, la CVE-2026-102489 y la CVE-2026-102490, y según el DIVD la operación la llevaron a cabo agentes de inteligencia artificial.

Ya hablamos de la primera vulnerabilidad en un artículo dedicado. Este artículo trata del incidente, de la cadena de ataque y de la segunda CVE, a partir del informe y las publicaciones del DIVD recogidos por The Register e Infosecurity Magazine.

Qué ha pasado

• Cronología: según la reconstrucción del DIVD que recoge The Register, la intrusión se produjo el 21 de septiembre y se descubrió al día siguiente. El DIVD bloqueó el acceso a todos los sistemas de su centro de datos y formó un equipo de respuesta con Merlon Security. El 24 de septiembre comunicó las vulnerabilidades al fabricante, avisó a la autoridad neerlandesa de protección de datos y al National Cyber Security Centre y valoró sus opciones con la policía. Infosecurity Magazine, en cambio, sitúa el 24 de septiembre como el día en que se detectó la actividad sospechosa: los dos medios no coinciden en la fecha del descubrimiento.
• Datos robados: según ambos medios, los atacantes se llevaron datos de los voluntarios, entre ellos las direcciones de correo del DIVD y posiblemente otros datos de contacto. El DIVD aún está comprobando qué datos de qué voluntarios están afectados.
• Contención: según Infosecurity Magazine, el DIVD escribió que desde el servidor de Zammad los atacantes llegaron a otros servicios y leyeron y exfiltraron datos, pero que la segmentación de la red y la actuación del equipo les impidieron ir más allá.

La cadena de ataque

Usadas juntas, las dos vulnerabilidades permitieron secuestrar sesiones, ejecutar código en remoto y elevar privilegios del usuario zammad a root: «en segundos», según el DIVD, precisamente por la parte automatizada del ataque.

• CVE-2026-102489: según The Register, permite a un atacante no autenticado filtrar sesiones de usuario y ejecutar código en remoto como el usuario local zammad. Versiones explotables: de la 6.3.0 a la 6.5.4. El fallo también existe en la rama 7 pero, según el aviso del DIVD, no es explotable por las condiciones del entorno. The Register indica las versiones de la 7.0.0 a la 7.1.3, mientras que la descripción de NVD citada en nuestro artículo anterior llegaba hasta la 7.1.2.
• CVE-2026-102490: elevación de privilegios de usuario local a root. Según The Register, son vulnerables todas las versiones de Zammad.
• Puntuación: ambas tienen un CVSS 4.0 de 9,4, calculado en el escenario de la cadena por el DIVD, que también es CNA y asignó las dos CVE.
• MITRE ATT&CK, correspondencia orientativa a partir de los hechos publicados: T1190 (Exploit Public-Facing Application), T1539 (Steal Web Session Cookie), T1068 (Exploitation for Privilege Escalation).

Las fuentes no publican indicadores de compromiso: el DIVD ha dicho que no puede compartir más sin entorpecer la investigación.

Por qué el DIVD habla de agentes IA

El DIVD ha afirmado que nunca había visto un ataque así, no por la intrusión en sí, sino por el modo de operar. Según The Register, lo describió como «ruidoso y muy desordenado»: en los registros se veía un agente que, tras cada acción, decidía por sí solo el paso siguiente, a gran velocidad y con una lógica descuidada.

El indicio más concreto, recogido por ambos medios, son los comentarios en los scripts del atacante: notas en las que el agente justifica sus propias acciones, explicando por qué lo que hace es lícito y «no es phishing». Un atacante humano, observa el DIVD, no se molestaría en hacerlo. Es una valoración del DIVD basada en los registros: las fuentes no dicen qué modelo o herramienta se usó ni quién está detrás.

Impacto para las empresas europeas e italianas

Un helpdesk guarda tickets, correos y datos personales de clientes y empleados. El caso del DIVD enseña dos cosas a quien defiende: los tiempos se acortan, de la sesión robada a root en segundos, y la segmentación funciona, porque es lo que limitó el daño. Tim Burke, de Quest Technology Management, en declaraciones a Infosecurity Magazine, añade que ante ataques a velocidad de máquina hay que saber de antemano quién tiene autoridad para aislar sistemas y bloquear cuentas.

Hay además un riesgo indirecto: con las direcciones de los voluntarios en manos de los atacantes, es más fácil hacerse pasar por el DIVD. Según The Register, la organización pide a quien reciba correos o solicitudes de contacto en su nombre que le parezcan extraños que los verifique escribiendo a communications@divd.nl.

El DIVD notificó el incidente a la autoridad de protección de datos y al centro nacional de ciberseguridad. En Italia el esquema es el mismo: notificación al CSIRT Italia de la ACN para las entidades sujetas a NIS2 y, si hay datos personales afectados, valoración de la notificación al Garante según el RGPD.

Qué hacer ya

1. Inventario: localiza todas las instancias de Zammad y su versión; prioriza las accesibles desde Internet y las versiones de la 6.3.0 a la 6.5.4.
2. Actualiza o apaga: el DIVD recomienda a todos los usuarios de Zammad pasar a la versión 7 o desconectar el servicio lo antes posible. Las fuentes no indican una versión que corrija la CVE-2026-102490: compruébalo en el aviso de Zammad.
3. Reduce la exposición y segmenta: hasta que hayas actualizado, deja el helpdesk accesible solo desde la red interna o por VPN, y limita las conexiones del servidor del helpdesk hacia otros sistemas internos a las imprescindibles.
4. Busca indicios de compromiso en las instancias expuestas con versiones vulnerables: comandos lanzados por el usuario zammad, procesos inesperados con privilegios de root, scripts nuevos en las carpetas de la aplicación y en las temporales, sesiones anómalas, conexiones desde el servidor hacia otros sistemas internos. La actividad automatizada se reconoce en los registros por la rapidez con la que se suceden las acciones.
5. Después de actualizar, cierra las sesiones activas. Si encuentras rastros, sustituye las credenciales y los tokens de las integraciones y valora reconstruir el servidor: el atacante puede haber obtenido root.

Cómo ayuda ARXDOME

ARX Expose muestra qué servicios expone tu empresa en Internet y qué productos se reconocen en ellos, así un helpdesk accesible desde fuera salta a la vista enseguida. ARX Shield enumera las vulnerabilidades abiertas en las máquinas supervisadas, destacando las ya explotadas, y permite aislar de la red una máquina sospechosa. ARX Sentry recoge registros y eventos de los servidores con el agente instalado, incluidas las ejecuciones sospechosas y los cambios en los archivos de las carpetas elegidas; con ARX Trace los analistas reconstruyen lo ocurrido mediante recolecciones y búsquedas en varias máquinas.

Última actualización: 2 de octubre de 2026