El Instituto Holandés de Divulgación de Vulnerabilidades (DIVD) pasa sus días escaneando internet, encontrando agujeros en el software de otros y diciéndoles amablemente cómo solucionarlos. El 21 de septiembre de 2026, un agente de IA autónomo invirtió los papeles y encontró los agujeros en los suyos.
No con una sofisticada compromisión de la cadena de suministro. No con un arsenal de cero-days de un Estado-nación. Con dos fallos encadenados en un sistema de helpdesk de código abierto, y la velocidad de una máquina que no espera a que un humano pulse enter.
Cuando los equipos de DIVD alcanzaron al atacante, este ya tenía root en la máquina, había llegado a otros servicios internos y había leído y exfiltrado datos. Toda la escalera de privilegios, de desconocido sin autenticar a root, llevó segundos.
Cuando los cazadores de vulnerabilidades se convierten en la vulnerabilidad
DIVD es una organización sin ánimo de lucro formada por investigadores voluntarios que notifican a los propietarios de sistemas sobre fallos antes de que los criminales los exploten. Que los ataquen no les sorprende: viene con el territorio. Lo que hace diferente este caso es cómo se ejecutó el ataque.
DIVD descubrió la intrusión mientras trabajaba en un caso anterior en el que determinó que había sido comprometida a través de la actividad de un agente de IA. Al investigar cómo entraron realmente los atacantes, DIVD y su socio de investigación Merlon Security reconstruyeron el camino e identificaron dos vulnerabilidades previamente desconocidas en Zammad, la plataforma de código abierto de tickets y helpdesk que DIVD usaba internamente.
Su análisis del incidente, registrado como DIVD-2026-00015, es directo sobre lo que ocurrió después. Como escribió la organización: "Cuando a los hackers les hackean, lo tratamos con estilo hacker."
Los dos cero-days
La cadena está construida sobre dos fallos de Zammad, ambos ya con CVE asignado:
- CVE-2026-102489 — un fallo de secuestro de sesión aprovechable en Zammad 6.3.0 a 6.5.4. Un atacante puede secuestrar sesiones legítimas y escalar el defecto a ejecución remota de código como usuario de servicio
zammad. (El defecto también existe en 7.0.0 a 7.1.3, pero las condiciones del entorno impiden explotarlo ahí.) - CVE-2026-102490 — un fallo de escalada de privilegios local que existe desde la versión 1.5.0 hasta la 7.1.0-alpha. Una vez que el código se ejecuta en el host como usuario de servicio, este fallo lleva al atacante hasta root.
Cada fallo es grave por sí solo. Encadenados, forman una línea recta: acceso sin autenticar en un endpoint web público, a RCE, a control total de root del servidor.
Root en segundos — la firma agéntica
Esta es la parte que importa a cualquier equipo que opere software expuesto a internet: la velocidad era la firma del agente de IA.
La divulgación de DIVD lo dice sin rodeos. De un usuario de Zammad a root, en segundos — "debido a la parte agéntica de este hack". El agente analizó el entorno, encadenó las dos vulnerabilidades, escaló privilegios y se movió a otros servicios sin que un humano dirigiera cada paso. Tomó decisiones y ejecutó el siguiente movimiento por su cuenta, comprimiendo una secuencia de ataque que históricamente lleva horas de trabajo manual a unos instantes.
Tras alcanzar root, el atacante accedió a otros servicios, leyó datos y exfiltró parte de ellos. La segmentación de red y la respuesta rápida de los equipos de TI e IR de DIVD detuvieron la intrusión antes de que se extendiera más — pero no antes de que ocurriera algún daño.
DIVD detectó el ataque en parte porque el agente era ruidoso: dejó rastros visibles que ayudaron a los investigadores a reconstruir todo. Eso es un consuelo, aunque incómodo. Un atacante más disciplinado con la misma herramienta agéntica podría permanecer mucho más silencioso.
Por qué un helpdesk es un objetivo Tier-0
La elección del vector merece la pena analizar. Zammad es software de código abierto muy popular — más de 2.000 clientes y 55.000 usuarios — y los helpdesks son uno de los sistemas más expuestos que opera cualquier organización.
Piensa en lo que vive en un escritorio de soporte: nombre completo, correo, teléfono, correspondencia con socios externos, credenciales compartidas en hilos de tickets, enlaces a sistemas internos, y la costumbre de adjuntar capturas de pantalla que nunca fueron pensadas para ojos ajenos. Un helpdesk es un mapa preindexado de tu organización, accesible para cualquiera que llegue a la página de login.
Por eso una cadena de RCE en un sistema de tickets nunca es solo un problema de tickets. Es un problema de identidad, de acceso y de movimiento lateral, todo a la vez.
Qué hacer esta semana
Si tu organización usa Zammad en cualquier versión, la orientación de DIVD y Zammad es inequívoca:
- Actualiza a Zammad versión 7, o desconecta el sistema. La versión 7 se considera segura; toda versión anterior se presume explotable. No esperes a la ventana de parcheo — esta cadena está en el catálogo de Vulnerabilidades Explotadas Conocidas (KEV) de CISA.
- Asume una compromiso previo. La cadena de DIVD es silenciosa hasta que el atacante hace algo ruidoso. Busca los indicadores suministrados en tus logs y revisa sesiones inesperadas, actividad extraña en el helpdesk y cuentas locales no reconocidas.
- Rota todo lo que el helpdesk pueda alcanzar. Los tickets suelen llevar credenciales, tokens y claves de API. Trata todo lo almacenado o enviado por el sistema como potencialmente expuesto.
- Saca el helpdesk de la zona de confianza. La única razón por la que este compromiso se contuvo fue la segmentación. Tu sistema de tickets nunca debería ser un trampolín desde un formulario web hasta la infraestructura interna.
- Modela la amenaza a velocidad de máquina. Ejecuta los escenarios que tu plan de respuesta debe sobrevivir cuando el atacante se mueve en segundos, no horas: decisiones de contención, rotación de credenciales y comunicaciones a dirección, todos ensayados a ese ritmo.
El panorama general: los ataques agénticos ya están aquí
Durante años, la IA en las conversaciones de seguridad vivía en dos cajas: la IA ayudando a los defensores a encontrar y parchear más rápido, y el phishing generado por IA volviéndose más convincente. El compromiso de DIVD rompe ambas cajas. Fue un agente de IA ejecutando toda la cadena de intrusión — reconocimiento, explotación, escalada de privilegios, movimiento lateral — contra una organización real, con consecuencias reales.
Además, el objetivo fue irónico. El instituto cuya misión central es encontrar vulnerabilidades antes de que se exploten fue comprometido a través de vulnerabilidades que nadie conocía. Nadie en DIVD fue descuidado; los fallos existían en código que miles de organizaciones ejecutan.
Esa es la conclusión estratégica para nuestros clientes del Golfo y de más allá: tu postura de seguridad es solo tan fuerte como el sistema de código abierto menos vigilado que hayas expuesto a internet, y tus adversarios ahora operan a velocidad de máquina. La defensa todavía gana — la segmentación, la respuesta rápida y el parcheo agresivo contuvieron esto en horas — pero la ventana para la remediación manual e impulsada por tickets se encoge cada mes.
Un agente de IA tomó el control de la infraestructura de una organización de seguridad en segundos. El próximo puede ser más silencioso. Asegúrate de que tu stack esté listo antes, no después.
En aratech ayudamos a las organizaciones a reforzar los sistemas que los atacantes apuntan de verdad — helpdesks, planos de identidad y la infraestructura de IA que ahora entra en la cadena de ataque de ambos lados. Si tu stack expuesto a internet no ha sido modelado contra ataques a velocidad agéntica, esa es la primera conversación a tener.