Zammad : deux failles exploitées, que faire

Deux failles du logiciel de helpdesk Zammad, enchaînées, ont permis de passer d'un accès web à un compte root en quelques secondes. Découvertes par le DIVD, l'institut néerlandais de divulgation de vulnérabilités, à la suite d'une intrusion dans ses propres systèmes, elles ont été ajoutées le 2 octobre 2026 au catalogue des vulnérabilités activement exploitées de la CISA américaine. L'éditeur a depuis publié un avis et un correctif. Voici ce qu'il faut savoir pour sécuriser une instance Zammad.

Une intrusion chez le DIVD

Le DIVD, une organisation bénévole qui signale habituellement les failles des autres, a annoncé fin septembre avoir été compromis via le Zammad qu'il utilisait en interne. Selon ses déclarations rapportées par BleepingComputer, l'attaque a été menée par un agent d'IA progressant de manière autonome. L'attaquant a ensuite accédé à d'autres services et exfiltré des données ; la segmentation du réseau et la réponse à incident ont, selon le DIVD, limité sa progression. Les deux failles ont été identifiées avec la société Merlon Security, dans le cadre du dossier DIVD-2026-00015.

CVE-2026-102489 : détournement de session

La première faille est un détournement de session qui mène à l'exécution de code à distance sous l'identité du compte de service zammad. D'après la fiche du DIVD, elle touche les versions 6.3.0 à 6.5.4. Le code fautif est aussi présent dans les versions 7.0.0 à 7.1.2, mais n'y est pas exploitable en raison de changements dans le framework sous-jacent. Le DIVD lui attribue un score CVSS 4.0 de 8,7, porté à 9,4 en cas de chaînage.

Dans son avis publié le 5 octobre, Zammad indique que l'exploitation n'est possible que sur les versions 6.5 et antérieures, et que la version 7.2.0 intègre une modification du code concerné à titre de durcissement supplémentaire.

CVE-2026-102490 : élévation de privilèges locale

La seconde faille concerne les paquets DEB et RPM construits avec packager.io. Les processus de service démarraient en root et exécutaient des fichiers modifiables par le compte zammad avant d'abaisser leurs privilèges. Un attaquant disposant déjà de ce compte pouvait donc obtenir les droits root, d'autant plus vite que les services redémarrent automatiquement. Les installations depuis les sources et les images de conteneurs officielles ne sont pas concernées.

L'éditeur souligne que cette faille ne peut pas être exploitée à distance seule. Combinée à la première, elle devient en revanche critique. L'avis de sécurité GitHub publié le 8 octobre désigne la version 7.2.2 comme corrigée ; toutes les versions empaquetées jusqu'à la 7.2.1 sont vulnérables.

Les mesures à prendre

• Mettre à jour vers Zammad 7.2.2 ou ultérieur, en priorité pour les installations en paquets DEB ou RPM.
• Abandonner les versions 6.5 et antérieures : selon Zammad, elles ne reçoivent plus de mises à jour de sécurité. Le DIVD conseille de passer en version 7 ou de mettre l'instance hors ligne.
• Restreindre l'accès au serveur hébergeant Zammad aux seuls administrateurs de confiance, comme le recommande l'éditeur.
• Rechercher des traces de compromission si une instance vulnérable était exposée sur Internet : un correctif appliqué tardivement ne suffit pas si l'attaquant est déjà passé.

Ce cas rappelle que les outils de support, souvent exposés et riches en données, sont des cibles de choix. Comme pour les failles Citrix NetScaler récemment, l'entrée au catalogue de la CISA doit servir de signal pour prioriser les correctifs.