Dos vulnerabilidades de día cero en Zammad permitieron a un intruso guiado por IA obtener acceso root a los sistemas de DIVD

DIVD vincula la intrusión en su red con una cadena de explotación de dos vulnerabilidades

El Instituto Neerlandés para la Divulgación de Vulnerabilidades (DIVD) atribuyó una reciente intrusión en su red a dos vulnerabilidades hasta ahora desconocidas en Zammad, una plataforma de código abierto para gestionar servicios de asistencia y solicitudes de soporte.

Según la información publicada sobre la investigación de DIVD, el atacante combinó CVE-2026-102489 y CVE-2026-102490 para comprometer el entorno de Zammad de DIVD. La cadena habría permitido secuestrar sesiones, ejecutar código de forma remota y escalar privilegios desde la cuenta de servicio de Zammad hasta root.

Después, el intruso accedió a otros servicios, consultó información de los sistemas de DIVD y exfiltró datos. Según la organización, la segmentación de la red y las medidas de respuesta al incidente impidieron que siguiera avanzando por la red.

La investigación seguía abierta cuando se publicó la información citada. DIVD afirmó que tenía previsto publicar otra actualización «mañana», aunque no precisó la hora.

Del robo de una sesión al control con privilegios de root

Al parecer, las dos vulnerabilidades cumplieron funciones complementarias, en lugar de provocar efectos independientes. DIVD describió una secuencia de ataque que comenzó con el control de una sesión autenticada y terminó con la ejecución de código arbitrario.

Según la información publicada, el atacante logró después superar las limitaciones de la cuenta de Zammad y obtener privilegios de root. En un sistema Linux habitual, root ofrece a un proceso el máximo nivel de control, lo que hace especialmente grave la escalada final, incluso sin una puntuación CVSS publicada.

La cadena descrita puede resumirse así:

1. La explotación de las vulnerabilidades de Zammad permitió secuestrar una sesión.
2. El contexto comprometido se utilizó para ejecutar código de forma remota.
3. El atacante escaló privilegios desde la cuenta de Zammad hasta root.
4. La intrusión se extendió a otros servicios accesibles desde el entorno afectado.
5. Se accedió a datos y se exfiltraron antes de que las medidas de contención limitaran nuevos movimientos.

El informe disponible no explica qué vulnerabilidad permitió cada etapa, cómo se tomó el control de la sesión ni qué mecanismo hizo posible la ejecución remota. Tampoco incluye código de prueba de concepto, patrones de solicitudes u otros detalles técnicos de la explotación.

Esto limita la capacidad de los equipos de defensa para crear detecciones específicas basadas únicamente en la información pública. Sin embargo, no resta gravedad al impacto descrito: DIVD afirma que las vulnerabilidades se combinaron con éxito contra su propia infraestructura.

DIVD afirma que un agente de IA dirigió la intrusión

Un aspecto singular del incidente es la valoración de DIVD de que la operación estuvo a cargo de un agente de IA capaz de decidir de forma autónoma cuáles serían sus siguientes acciones.

La organización afirmó que, en cuestión de segundos y sin indicaciones externas durante esa secuencia, el agente pasó de la explotación a la escalada de privilegios, el acceso a servicios y el robo de datos. DIVD también señaló que el sistema dejó explicaciones de sus decisiones, que los investigadores utilizaron para reconstruir el ataque.

Esta caracterización debe ceñirse a las conclusiones de DIVD. El informe atribuye al agente la toma autónoma de decisiones en este incidente, pero no aclara cómo desarrolló el sistema el atacante, qué modelo utilizó ni cuánta preparación hubo antes de que comenzara la actividad automatizada.

La velocidad tiene relevancia operativa. Una cadena automatizada que evalúa el acceso y selecciona de inmediato las siguientes acciones puede comprimir varias etapas de una intrusión en un intervalo demasiado breve para intervenir manualmente. Por ello, los controles defensivos deben poder detener o contener la actividad de forma automática, en lugar de depender exclusivamente de que un analista detecte cada paso y responda a él.

En este caso, la segmentación ayudó a limitar las consecuencias. El atacante llegó a otros servicios, pero, según DIVD, los controles impidieron que avanzara más por la red.

Los usuarios de Zammad no disponen de una lista precisa de versiones afectadas

Zammad está disponible como plataforma de asistencia alojada o autogestionada. Permite gestionar consultas de clientes, flujos de trabajo de soporte informático y solicitudes internas, por lo que puede resultar un objetivo atractivo: los sistemas de gestión de solicitudes pueden contener conversaciones confidenciales y estar conectados a otros servicios empresariales.

El proveedor afirma tener más de 2.000 clientes y 55.000 usuarios. Entre las organizaciones mencionadas en el informe como usuarias de Zammad figuran De’Longhi, Amnistía Internacional y NextCloud. Que aparezcan en ese contexto no demuestra que sus sistemas hayan sido atacados o comprometidos.

La divulgación citada no identifica las versiones vulnerables de Zammad. Tampoco especifica qué versiones están afectadas, cuál es la versión corregida ni qué configuración del producto se necesita para explotar las vulnerabilidades.

Por tanto, los administradores no pueden determinar de forma fiable si están expuestos limitándose a comparar sus instalaciones con una lista detallada de versiones vulnerables. La recomendación de DIVD es más general: actualizar a Zammad versión 7, que considera segura, o desconectar cuanto antes la instancia.

DIVD afirmó que descubrió las vulnerabilidades junto con Merlon Security y que notificó a Zammad. También estaba avisando a los usuarios que sabía que tenían instancias vulnerables.

Prioridades inmediatas de defensa para los administradores

Quienes gestionan Zammad deben considerar la actualización como la medida prioritaria. Los sistemas que no puedan actualizarse cuanto antes a la versión 7 deberían aislarse o desconectarse, siguiendo las recomendaciones de DIVD, hasta que puedan protegerse.

Dado que el compromiso descrito incluyó el secuestro de sesiones y la ejecución de código con privilegios de root, restablecer una contraseña puede no ser suficiente si el sistema ya ha sido explotado. Los administradores deberían comprobar el servidor y los servicios conectados para detectar indicios de accesos no autorizados, escaladas de privilegios y extracción de datos.

Entre los aspectos que conviene revisar se encuentran:

• Sesiones autenticadas inesperadas o cambios inusuales en su comportamiento.
• Procesos iniciados con la cuenta de Zammad que no correspondan a la actividad habitual de la aplicación.
• Indicios de comandos o procesos ejecutados con privilegios de root.
• Conexiones desde el servidor de Zammad a servicios internos a los que normalmente no accede.
• Transferencias salientes inusuales o acceso a grandes volúmenes de datos de solicitudes y servicios.
• Cambios en cuentas, permisos o configuraciones realizados durante actividades sospechosas.

Estas son prioridades generales de investigación basadas en los efectos descritos por DIVD, no indicadores específicos de estas vulnerabilidades. El informe citado no proporciona direcciones IP, hashes de archivos, dominios, firmas de registros ni otros indicadores concretos de compromiso.

Siempre que sea posible, los equipos de defensa deberían conservar los registros del sistema, de la aplicación, de autenticación y de red antes de reinstalar el servidor o desconectar uno sospechoso. La segmentación entre el servidor de gestión de solicitudes y los servicios internos sensibles también puede limitar los recursos a los que accede un atacante tras el compromiso inicial, como demuestra la experiencia de DIVD.

Siguen sin respuesta varias preguntas técnicas importantes

El incidente tuvo consecuencias graves, pero aún faltan detalles necesarios para evaluar mejor el riesgo general. El informe citado no incluye una puntuación CVSS ni una clasificación formal de gravedad, y tampoco identifica las versiones exactas afectadas.

Además, no explica qué versiones son vulnerables y cuáles se corrigieron en cada actualización. La información pública tampoco detalla las solicitudes utilizadas para explotar las vulnerabilidades, las condiciones de acceso necesarias ni los rastros que dejó la cadena de ataque.

El informe tampoco aporta pruebas de que se hayan vulnerado otros clientes de Zammad. El alcance confirmado que se describe aquí se limita al incidente de DIVD y a su atribución a las dos vulnerabilidades de día cero.

Por ahora, la combinación de secuestro de sesiones, ejecución remota de código y escalada de privilegios hasta root deja clara la recomendación operativa: actualizar a la versión 7 o retirar de servicio la instancia expuesta. Para delimitar el número de afectados y facilitar una detección precisa, será necesario que DIVD publique nuevos hallazgos y que Zammad proporcione información técnica.