Deux zero-days Zammad donnent un accès root, exploités contre l’institut de divulgation DIVD
Une chaîne de deux failles Zammad — détournement de session puis élévation de privilèges vers root — a été exploitée le 21 septembre 2026 contre le DIVD, l’institut néerlandais de divulgation des vulnérabilités, et inscrite au catalogue KEV de la CISA le 2 octobre. Montez vos instances Zammad en version 7 et traitez toute instance exposée comme potentiellement compromise, car le correctif seul n’efface pas la persistance.
21 septembre 2026. Un attaquant exploite un détournement de session pour compromettre Zammad, la plateforme de tickets du DIVD (Dutch Institute for Vulnerability Disclosure) — l’institut néerlandais chargé, précisément, de coordonner la divulgation des failles. 24 septembre 2026. Le DIVD signale deux zero-days à l’éditeur sous la référence DIVD-2026-00015. 2 octobre 2026. La CISA inscrit la première faille, CVE-2026-102489, au catalogue KEV des vulnérabilités exploitées. Pourquoi c’est important : l’organisation qui traque les failles des autres a été prise au piège des siennes, et la chaîne complète mène à un accès root en quelques secondes.
Une chaîne en deux étapes, de la session au root
La première faille, CVE-2026-102489, est un détournement de session (CWE-384) qui touche Zammad 6.3.0 à 6.5.4. Non authentifiée, elle permet à un attaquant de s’emparer d’une session valide sur le réseau, puis d’exécuter des commandes à distance sous le compte de service zammad. Le défaut existe aussi dans les versions 7.0.0 à 7.1.3, mais le DIVD précise qu’il n’y est pas exploitable en raison de conditions d’environnement.
La seconde, CVE-2026-102490, est une élévation de privilèges locale qui transforme l’accès zammad en accès root. Son périmètre est nettement plus large : elle concerne toutes les versions de Zammad, de la 1.5.0 jusqu’à la 7.1.0-alpha. Autrement dit, monter en version 7 neutralise la première étape mais laisse la seconde intacte si un attaquant obtient déjà un shell local.
Mises bout à bout, les deux failles forment une chaîne à fort impact. Un attaquant distant détourne une session, exécute des commandes sous zammad, puis escalade vers root : de là, il peut altérer les données du helpdesk, lire les tickets clients, voler les pièces jointes, modifier les comptes, installer une porte dérobée persistante et pivoter vers le reste du réseau. Le DIVD décrit une progression « en quelques secondes » entre la prise de session et le contrôle total, suivie d’un accès à d’autres services et d’une exfiltration de données.
Le piège symbolique : la victime est l’institut de divulgation
La leçon la plus amère tient moins à la technique qu’à l’identité de la victime. Le DIVD est une organisation de bénévoles et de chercheurs qui scanne Internet, notifie les propriétaires d’instances vulnérables et coordonne la correction — un rôle proche de celui du CERT-FR ou de la CISA côté américain. La compromission du 21 septembre 2026 n’a pas été découverte de façon proactive : elle est apparue en creux, pendant l’enquête sur un cas de brèche distinct, DIVD-2026-00014.
Le DIVD a analysé et reproduit les deux failles entre le 22 et le 23 septembre, puis signalé le tout à Zammad le 24 septembre. Le 26 septembre, il a commencé à scanner les instances Zammad exposées sur Internet et à notifier leurs propriétaires. Ce calendrier dit quelque chose de la difficulté du travail : même l’acteur le mieux placé pour repérer une faille a d’abord été victime, puis a dû basculer en mode incident avant de pouvoir faire son métier de notificateur.
Version 7 ou hors ligne : une consigne à moitié rassurante
La recommandation officielle du DIVD est de monter en Zammad 7, ou de retirer l’instance du réseau tant que la correction n’est pas appliquée. La nuance compte : CVE-2026-102490 touche aussi la 7, y compris les derniers builds alpha. Passer en 7 coupe le détournement de session, mais un opérateur qui a déjà obtenu un accès zammad sur une machine non re-médiée conserve la possibilité d’escalader.
La persistance est le vrai sujet. Comme les failles ont été exploitées avant la divulgation publique, patcher ne supprime pas ce qu’un attaquant a déjà installé. Le DIVD a publié un script de vérification des logs qui cherche des indicateurs de compromission : sessions suspectes, activité administrative inattendue, exécution de commandes inhabituelle et modifications touchant le compte zammad. C’est le premier réflexe à déclencher, avant même de penser à la montée de version.
Zammad, un helpdesk open source très exposé
Zammad est un helpdesk open source, hébergé ou auto-hébergé, utilisé par des organisations de toutes tailles pour gérer tickets, clients et incidents. Sa popularité en fait une cible de choix : une instance mal exposée cumule une surface d’attaque web, un compte de service exécutant du code et, trop souvent, une intégration SMTP ou LDAP qui ouvre la porte au reste du réseau. Le DIVD lui-même a commencé, dès le 26 septembre, à scanner les instances exposées sur Internet pour notifier leurs propriétaires — signe que le parc exposé est suffisamment large pour justifier une campagne de notification.
Cette exposition explique pourquoi la chaîne est si dangereuse. Le détournement de session ne demande aucune authentification : il suffit qu’une instance soit joignable. Et comme le compte zammad exécute du code, l’attaquant n’a pas besoin d’un compte utilisateur privilégié pour commencer — l’élévation vers root fait le reste.
Ce que l’inscription au KEV change réellement
Le passage de CVE-2026-102489 au catalogue KEV de la CISA, le 2 octobre 2026, n’est pas anodin : ce catalogue ne recense que les failles dont l’exploitation active est avérée, ce qui en fait le signal de gravité le plus fiable, loin d’une notation CVSS théorique. En vertu de la directive BOD 22-01, les agences fédérales américaines doivent corriger ou atténuer toute faille listée dans un délai contraint.
Le chiffre qui doit retenir l’attention est le délai : entre la compromission du DIVD le 21 septembre et l’inscription au KEV le 2 octobre, douze jours se sont écoulés. C’est la fenêtre pendant laquelle des attaquants ont exploité la faille dans la nature avant que l’alerte publique ne tombe. Pour une organisation qui exploite Zammad, la question n’est donc pas « sommes-nous vulnérables », mais « avons-nous été touchés pendant ces douze jours ».
Ce qu’il faut faire
La marche à suivre tient en quatre actions, dans l’ordre.
- 1. Inventorier et isoler. Recensez toutes les instances Zammad de votre parc, y compris celles qui ne servent plus. Toute instance exposée sur Internet et non patchée doit être isolée du réseau immédiatement.
- 2. Chercher la compromission avant de patcher. Exécutez le script d’IOC du DIVD et passez les logs en revue. Si une activité suspecte apparaît, le patch arrive trop tard : traitez la machine comme compromise.
- 3. Monter en version 7 et corriger la seconde faille. La 7 neutralise CVE-2026-102489 ; appliquez le correctif de CVE-2026-102490 dès qu’il sort, car il couvre la 7 elle aussi.
- 4. Remédier, pas seulement patcher. Rotation des secrets et des clés, revue des comptes, inspection des tâches planifiées et des services : un accès root compromet tout ce que la machine peut atteindre, pas seulement le helpdesk.
Verdict
Si vous exploitez une instance Zammad exposée sur Internet, traitez-la comme potentiellement compromise tant que vous n’avez pas passé le script d’IOC du DIVD et vérifié les logs : la faille de session a été exploitée dans la nature avant d’être publique. Si vous êtes en version 6.x, la montée en 7 est urgente mais insuffisante à elle seule — la seconde faille escalade vers root sur toutes les versions, et le correctif seul n’efface pas une persistance déjà installée. Si vous croyez que « ça n’arrive qu’aux autres », ce cas prouve le contraire : l’institut qui coordonne la divulgation des vulnérabilités a été compromis par la chaîne exacte qu’il documente aujourd’hui. La remédiation complète, pas le patch, est la seule réponse qui tienne.