flawopen.com/Incidents/divd-zammad-ai-agent-zero-day-chain-september-2026

● Dutch Institute for Vulnerability Disclosure (DIVD) · CVE-2026-102489 · 2026-09-21 · CVSS 9.4 · Critique

Recherche · FlawOpen

Intrusion DIVD via Zammad : CVE-2026-102489 et 102490

DIVD indique que les attaquants ont obtenu root grâce à deux vulnérabilités de Zammad, puis ont utilisé des agents IA pour poursuivre leurs activités. CVE-2026-102490 concerne les paquets DEB/RPM et est corrigée en 7.2.2.^{[10], [1], [2], [12], [3], [11]}

💡 Explication en Langage Simple (ELI5)

Imaginez une responsable qui commence avec les clés maîtresses, lit et exécute un ordre de travail qu’un employé subalterne peut modifier, puis rend seulement ensuite les clés. L’employé peut changer ce qui sera exécuté tant que la responsable dispose de tous les droits. Le problème des paquets Zammad concerne des fichiers que le compte zammad peut modifier avant qu’un service lancé en root n’abaisse ses privilèges ; un accès préalable est nécessaire et seuls les paquets DEB/RPM sont concernés. Cette CVE ne fournit pas l’accès initial.^{[1], [2], [3]}

Concepts Clés et Termes

CVE-2026-102489: DIVD décrit un détournement de session Zammad menant à l’exécution de code à distance sous le compte de service zammad. CWE-384 est répertoriée ; GHSA indique CVSS 4.0 9,4.^{[2], [5], [6]}
CVE-2026-102490: CVE-2026-102490 est une élévation locale de privilèges propre aux paquets. La configuration DEB/RPM peut exécuter des fichiers modifiables par le compte non privilégié zammad avant qu’un service lancé en root n’abaisse ses privilèges ; l’attaquant doit donc déjà disposer d’un accès et des droits nécessaires. Les conteneurs officiels et les installations depuis les sources sont exclus. Zammad 7.2.2 corrige le problème.^{[8], [10], [2], [7], [12], [3], [11]}
CWE-384 / CWE-269: DIVD distingue le CVSS 4.0 de 8,5 (local, privilèges faibles) pour CVE-2026-102490 seule du score 9,4 lorsqu’elle est chaînée avec CVE-2026-102489. L’ancien GHSA-HGFF affiche toujours 9,4 avec un vecteur réseau/sans privilèges pour CVE-2026-102490 seule. L’avis Zammad/GHSA-p97 du 8 octobre attribue 8,5 et un vecteur local au problème DEB/RPM. Indiquez le scénario et la source ; ne présentez pas les anciennes métadonnées comme preuve d’un accès distant autonome. Pour le problème propre aux paquets, GHSA-p97 associe aussi CWE-250, CWE-426 et CWE-732 ; l’attribution CWE-269 de la fiche DIVD/CVE est distincte.^{[10], [2], [6], [7], [3], [11]}
KEV: Le NVD indique que CVE-2026-102489 figure au catalogue CISA KEV. N’en déduisez pas que CVE-2026-102490 y figure aussi.^[5]
Limite de divulgation: L’avis public cité décrit le problème des paquets et la version corrigée, mais ne contient ni lignes de code ni patch propres à cette CVE. Cette page ne peut donc pas présenter de correctif de code étayé par les sources ; suivez les recommandations de l’éditeur pour les paquets plutôt que de prendre un exemple générique pour le patch Zammad.^{[6], [7], [11]}

Correspondances de référentiels

Référence CWE pour la faiblesse décrite dans ce guide : CWE-269 CWE-384
CISA KEV — ajouté le 2026-10-02 — CVE-2026-102489

Failles Zammad distinctes et état des correctifs

Faille	État et périmètre selon les sources	Mesure défensive
`CVE-2026-102489`	DIVD indique les versions 6.3.0–6.5.4 et 7.0.0–7.1.3 ; cette dernière plage n’était pas exploitable dans le runtime décrit. Zammad indique que l’exploitation pratique se limite à la 6.5 et aux versions antérieures et mentionne un durcissement supplémentaire en 7.2.0.	Évaluez la version et le runtime exacts selon les consignes de Zammad et de DIVD. L’avis distinct de la 7.2.1 ne prouve pas que cette CVE y a été corrigée.
`CVE-2026-102490`	La fiche DIVD actuelle et l’avis Zammad/GHSA-p97 du 8 octobre limitent cette élévation locale aux installations DEB/RPM ; un accès préalable sous le compte zammad non privilégié est nécessaire. Le problème de paquet est corrigé en 7.2.2 ; les installations depuis les sources et les conteneurs officiels sont exclus. DIVD attribue 8,5 local au CVE seul et 9,4 à la chaîne avec `CVE-2026-102489`. Un ancien GHSA-HGFF affiche encore un vecteur réseau contradictoire pour le CVE seul.	Vérifiez l’origine de l’installation. Mettez à jour les paquets DEB/RPM vers 7.2.2 ou ultérieure ; les installations depuis les sources et les conteneurs officiels sont exclus de ce problème spécifique. Distinguez le scénario autonome du scénario chaîné.
GHSA-23hj-h8w6-rgm3 (problème distinct)	Cet avis sans CVE concerne l’exposition d’identifiants de session jusqu’à la 7.2.0 et indique que la 7.2.1 la corrige. Les sources citées ne le relient pas aux CVE ci-dessus.	Gardez cette divulgation séparée ; n’utilisez pas le correctif de la 7.2.1 comme preuve que l’une des CVE de DIVD est résolue.

Chronologie de l'Incident

2026-09-21

DIVD signale le premier accès malveillant à ses systèmes.^[1]

2026-09-22

DIVD détecte une activité suspecte, bloque l’accès à ses systèmes de centre de données et lance la réponse à incident avec une équipe forensique externe.^[1]

2026-09-24

DIVD indique avoir signalé la vulnérabilité à Zammad.^[2]

2026-09-29

DIVD publie son dossier d’incident et décrit les vulnérabilités Zammad.^{[1], [2]}

2026-09-30

CVE-2026-102489 et CVE-2026-102490 sont publiées ; DIVD décrit leur chaîne.^{[2], [8], [6], [7]}

2026-10-02

Selon le NVD, CVE-2026-102489 est ajoutée au catalogue CISA KEV.^[5]

2026-10-05

Zammad publie son évaluation : CVE-2026-102489 n’est pas exploitable en pratique sous 7.0+ avec son environnement d’exécution ; CVE-2026-102490 est locale et toujours analysée.^{[3], [6], [7]}

2026-10-06

Zammad publie la version 7.2.1 avec des correctifs de sécurité critiques. La page ne relie pas ces CVE à cette version ; ne supposez pas qu’elle corrige CVE-2026-102490.^[4]

2026-10-07

Zammad 7.2.1 renvoie vers un avis distinct, GHSA-23hj-h8w6-rgm3, concernant l’exposition d’identifiants de session corrigée dans la version 7.2.1. Cet avis ne comporte pas de CVE ; les sources disponibles ne l’associent ni à CVE-2026-102489 ni à CVE-2026-102490. Gardez ces problèmes distincts.^{[4], [9]}

2026-10-08

Zammad a publié la version 7.2.2 et lié GHSA-p97w-927q-8vxq au problème d’élévation locale propre aux paquets DEB/RPM associé à CVE-2026-102490. La fiche DIVD actuelle indique aussi 7.2.2 comme limite corrigée ; les installations depuis les sources et les conteneurs officiels sont exclues.^{[10], [11], [12]}

Déroulement de l'Attaque Étape par Étape

Étape 1

L’accès initial exploite un zero-day Zammad

DIVD indique que l’attaquant a accédé à ses systèmes le 21 septembre 2026 au moyen d’une vulnérabilité Zammad. Les sources publiques ne révèlent pas assez de détails d’implémentation pour reproduire la requête vulnérable avec sûreté et précision.^{[1], [2]}

Étape 2

CVE-2026-102489 atteint le compte de service

DIVD décrit un détournement de session menant à l’exécution de code à distance sous l’utilisateur zammad. Les versions 6.3.0–6.5.4 sont affectées ; la faille existe aussi sous 7.0.0–7.1.3 mais n’est pas exploitable selon les conditions d’environnement rapportées. Zammad affirme que l’exploitation n’est pratique que jusqu’à 6.5 ; le durcissement supplémentaire est dans 7.2.0.^{[2], [3], [6], [5]}

Étape 3

Une seconde faille change la frontière d’impact

DIVD indique que, lors de cet incident, CVE-2026-102490 a permis au compte local zammad d’obtenir root après le premier accès lié à CVE-2026-102489. La fiche DIVD actuelle et l’avis Zammad/mainteneur du 8 octobre limitent l’élévation documentée aux installations par paquets DEB/RPM ; les installations depuis les sources et les conteneurs officiels sont exclus. Zammad 7.2.2 corrige ce problème de paquet. Ne généralisez pas cette condition propre aux paquets à tous les déploiements Zammad.^{[8], [10], [2], [7], [12], [3], [11]}

Étape 4

Les agents IA ont été utilisés après l’accès root

DIVD indique qu’après avoir obtenu root, l’attaquant a utilisé des agents IA pour poursuivre ses activités. Cela décrit ce qui s’est passé après l’élévation de privilèges, et non le mécanisme qui a permis d’obtenir root. La déclaration de DIVD ne prouve pas qu’un modèle IA ait choisi ou exécuté chaque action de façon autonome.^[1]

Étape 5

Corrigez CVE par CVE et vérifiez les preuves

Corrigez chaque maillon selon le CVE et le type de déploiement. Pour CVE-2026-102489, suivez les conditions de version/runtime de Zammad et son avis de renforcement supplémentaire en 7.2.0. Pour CVE-2026-102490, vérifiez l’origine du paquet : l’avis actuel couvre les installations DEB/RPM et indique 7.2.2 comme version corrigée ; les installations depuis les sources et les conteneurs officiels sont exclus de ce problème de paquet. Vérifiez la version installée. Conservez l’ancien vecteur GHSA contradictoire comme divergence entre sources, pas comme conclusion d’accessibilité.^{[10], [4], [12], [3], [11], [9]}

Pourquoi aucun exemple de code n’est présenté

L’avis public cité décrit le périmètre des paquets et la version corrigée, mais ne contient ni lignes de code ni patch propres à cette CVE. Un exemple laisserait croire à des détails d’implémentation que la source ne montre pas. Pour les paquets DEB/RPM concernés, vérifiez la mise à jour prise en charge vers la version 7.2.2 ou ultérieure et confirmez la version installée.^[11]

Liste de Contrôle de Sécurité pour l'Ingénierie

✓Inventoriez précisément édition, version, runtime et exposition Zammad ; comparez chaque CVE à ses propres conditions DIVD et éditeur.^{[2], [3], [5], [6], [7]}
✓Pour CVE-2026-102490, identifiez le mode d’installation de Zammad. Mettez à jour les installations par paquets DEB/RPM vers la version 7.2.2 ou ultérieure ; l’avis de Zammad exclut les installations depuis les sources et les images de conteneur officielles de ce problème spécifique aux paquets.^{[10], [4], [12], [3], [11]}
✓Suivez séparément le correctif de paquet de CVE-2026-102490 et les anciennes métadonnées GHSA-HGFF ; consignez le type d’installation et la version corrigée, sans traiter l’ancien vecteur réseau comme preuve d’exploitation distante autonome.^{[7], [4], [12], [3], [11]}
✓Réservez l’accès à l’hôte Zammad aux administrateurs de confiance ; isolez le compte de service et supprimez les chemins inutiles d’élévation de privilèges.^{[2], [3]}
✓Segmentez le service d’assistance des systèmes d’identité, de CI et de données sensibles ; limitez l’accès réseau du compte de service aux destinations nécessaires.^[1]
✓En cas de suspicion d’intrusion, préservez journaux et images forensiques, invalidez les sessions, renouvelez les secrets exposés et vérifiez l’accès aux services connectés.^[1]
✓Séparez les statuts « affecté », « non exploitable avec le runtime indiqué », « corrigé par l’éditeur » et « correctif déployé » ; ne les fusionnez pas.^{[3], [4], [8]}