Le 2 octobre 2026, la CISA a ajouté deux CVE Zammad à son catalogue KEV, le même jour, avec la même échéance : 5 octobre. Zammad est une plateforme open source de helpdesk et de ticketing, souvent auto-hébergée et exposée sur Internet pour que les clients puissent ouvrir des tickets.
Les deux failles sont chaînables, et la CISA le dit explicitement dans les deux fiches : la première donne l'exécution de code en tant qu'utilisateur zammad, la seconde fait passer de cet utilisateur à root.
| CVE-2026-102489 | CVE-2026-102490 | |
|---|---|---|
| Classe | fixation / détournement de session → RCE | gestion incorrecte des privilèges → root |
| CVSS 3.1 | 9.8 (CRITICAL) | non publié par NVD à la date de rédaction |
| Vecteur | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H | non publié |
| Publication NVD | 2026-09-30 | pas encore publiée |
| CISA KEV | ajoutée le 2026-10-02, échéance 2026-10-05 | ajoutée le 2026-10-02, échéance 2026-10-05 |
CVE-2026-102489 : du détournement de session à l'exécution de code
a session hijack vulnerability that leads to remote code execution as the zammad user
La CISA la qualifie de fixation de session. Le principe de cette classe de faille : l'application accepte un identifiant de session imposé ou récupéré par l'attaquant, qui se retrouve alors dans la session d'un utilisateur légitime. Ici, NVD indique que cela débouche sur une exécution de code sous l'identité du compte système zammad, sans authentification préalable selon le vecteur.
Je ne détaille pas le mécanisme : l'avis de sécurité Zammad est la référence.
CVE-2026-102490 : de l'utilisateur zammad à root
NVD n'a pas encore publié de score ni de versions à la date de rédaction. La CISA la décrit comme une gestion incorrecte des privilèges permettant à l'utilisateur local zammad de s'élever en root.
Prise seule, elle demande un accès local. Chaînée à la première, elle transforme une compromission applicative en prise de contrôle complète du serveur.
Pourquoi c'est grave
Un helpdesk concentre plus d'informations sensibles qu'on ne le pense :
- l'historique des échanges avec les clients et les collaborateurs, pièces jointes comprises
- souvent des mots de passe, captures d'écran et extraits de configuration envoyés « pour le support »
- des intégrations avec la messagerie, l'annuaire (LDAP), le CRM, et leurs identifiants
Root sur ce serveur, c'est tout cela, plus un point d'appui dans le réseau interne.
Versions
D'après NVD, CVE-2026-102489 touche Zammad de 6.3.0 à 6.5.4.
The bug is also present in version 7.0.0 to version 7.1.2, but not exploitable due to changes in the underlying framework.
Donc : la branche 7 jusqu'à 7.1.2 contient le défaut sans qu'il y soit exploitable selon NVD. Ce n'est pas une raison pour ne pas mettre à jour.
NVD ne donne pas de version corrigée pour CVE-2026-102489, et rien du tout pour CVE-2026-102490. Je n'en invente pas : la version à installer est dans l'avis de sécurité Zammad. Vérifie-la pour les deux CVE, la seconde pouvant toucher des versions différentes.
Détection
- Sessions anormales : même session utilisée depuis des adresses ou des navigateurs différents, connexions d'agents ou d'admins à des horaires inhabituels
- Processus enfants inattendus sous les services Zammad (serveur web, workers)
- Fichiers modifiés dans le répertoire d'installation de Zammad et les répertoires système, hors mise à jour
- Comptes agents ou administrateurs créés récemment, jetons d'API nouveaux
- Signes d'élévation : nouvelles tâches planifiées, clés SSH ajoutées, binaires modifiés appartenant à root
Mitigation
- Mettre à jour Zammad vers la version corrigée indiquée par l'éditeur. L'échéance CISA tombe aujourd'hui.
- Si tu es encore en 6.x, la priorité est maximale : c'est la plage où NVD qualifie la faille d'exploitable.
- Limiter l'exposition : si le portail client doit rester public, restreindre l'interface agents et admin aux réseaux internes ou derrière un VPN.
- Invalider toutes les sessions après la mise à jour, et faire tourner les jetons d'API.
- En cas de compromission : considérer le serveur comme perdu (root possible), le reconstruire, faire tourner les identifiants des intégrations (messagerie, LDAP), et traiter le contenu des tickets comme exposé.
Pourquoi surveiller vos outils de support en continu
Un helpdesk est rarement dans la liste des systèmes critiques, alors qu'il reçoit chaque jour des données que personne n'oserait mettre ailleurs. Deux CVE chaînables au KEV avec une échéance de trois jours ne laissent pas le temps de découvrir qu'on en héberge un.
Avec cveo.tech, inventorie tes applications métier auto-hébergées avec leur version, et reçois une alerte dès qu'une CVE au CISA KEV les concerne.