Ilustración editorial generada con IA por Defensops. No es una fotografía del incidente ni de los equipos afectados. Representa Ilustración editorial de tickets, sesión comprometida y segmentación.

Síntesis y análisis propios a partir de la cobertura de BleepingComputer; las afirmaciones del medio se atribuyen a su fuente.

Qué se ha confirmado

Según BleepingComputer, DIVD atribuyó la entrada en su red a una cadena de dos vulnerabilidades de día cero en el sistema de tickets Zammad.

DIVD identificó los fallos como CVE-2026-102489 y CVE-2026-102490 y afirma que juntos permitieron secuestrar sesiones, ejecutar código a distancia y elevar privilegios desde el usuario de Zammad hasta root.

La organización afirma que un agente automatizado por IA tomó decisiones de forma autónoma y dejó explicaciones de sus pasos que facilitaron reconstruir la intrusión.

Tras explotar los fallos, el atacante accedió a otros servicios y leyó y exfiltró datos de los sistemas de DIVD; la segmentación y la respuesta impidieron, según la organización, un avance más profundo.

DIVD recomienda a los usuarios de Zammad actualizar a la versión 7, que considera segura, o desconectar cuanto antes la instancia vulnerable.

Análisis de Defensops

El caso muestra cómo una aplicación de soporte expuesta puede convertirse en punto de acceso a otros servicios si una sesión y los privilegios del proceso quedan comprometidos. La cadena descrita combina varias etapas: cada hallazgo aislado debe evaluarse junto con el estado real de la instancia y los accesos que le concede la red local. La consecuencia más grave comunicada hasta ahora es la exfiltración en la propia organización afectada; la fuente no demuestra que todos los despliegues de Zammad hayan sufrido intrusiones.

La referencia a IA procede del relato de DIVD recogido por BleepingComputer. Las explicaciones que dejó el agente ayudaron a reconstruir ese incidente, pero no permiten inferir por sí solas qué tecnología concreta utilizó ni que esa automatización sea necesaria para explotar los fallos. La rapidez observada reduce el margen para reaccionar después de la primera alerta y da prioridad a la reducción de exposición y a la preservación de registros.

La investigación sigue abierta y el artículo no precisa las versiones vulnerables anteriores a Zammad 7, el alcance de los datos extraídos ni indicadores técnicos para buscar la actividad. Una organización que opere Zammad debe contrastar su versión, accesibilidad y registros de sesión y procesos antes de concluir si necesita respuesta a un incidente además de actualización.

Prioridades de revisión

Identificar de inmediato las instancias de Zammad, su versión y su exposición de red; comprobar si se puede aplicar Zammad 7 y, si no, planificar la desconexión de la instancia vulnerable conforme a la recomendación de DIVD.

Antes de actualizar o desconectar una instancia sospechosa, conservar registros de autenticación, sesiones, procesos y conexiones salientes para poder investigar accesos no autorizados.

Revisar las cuentas y sesiones administrativas de Zammad y los accesos desde el servidor a otros servicios; investigar actividad anómala y revocar sesiones o credenciales comprometidas según los hallazgos.

Comprobar qué sistemas puede alcanzar el servidor de tickets y reducir permisos y rutas innecesarias; verificar que los controles de segmentación registren intentos de movimiento hacia otros servicios.

Seguir las actualizaciones técnicas de DIVD y Zammad para precisar versiones afectadas e indicadores, y ajustar la búsqueda retrospectiva cuando se publiquen.

Qué no se ha confirmado

La investigación de DIVD seguía abierta al publicarse la noticia y no se detalla el volumen ni el tipo de datos exfiltrados.

La cobertura no enumera todas las versiones vulnerables ni aporta indicadores concretos para detectar la explotación.

La herramienta de IA y su grado de autonomía se describen según DIVD; el artículo no identifica su implementación.

Fuente

BleepingComputer. Fecha indicada: 2026-09-30.