Zammad et TeamCity : les outils TI comme porte d'entrée

Le 21 septembre 2026, quelqu'un est entré dans le réseau du Dutch Institute for Vulnerability Disclosure (DIVD) par son service d'assistance Zammad. Deux jours plus tard, le 23 septembre, la CISA signalait qu'une faille de JetBrains TeamCity servait désormais à des campagnes de rançongiciels. Un logiciel de billets et un serveur d'intégration continue : deux outils que l'équipe TI installe pour elle-même, et qui détiennent les clés du reste.

Ce que disent les sources

DIVD, sur sa propre intrusion. L'organisation a publié elle-même son cas, DIVD-2026-00014, avec une déclaration finale le 1er octobre. Les attaquants ont enchaîné deux failles inconnues de Zammad pour détourner une session, exécuter du code, puis passer de l'utilisateur zammad à root. Ils ont ensuite atteint d'autres services et exfiltré des données, dont des adresses courriel DIVD de bénévoles et possiblement des coordonnées. DIVD écrit : « The modus operandi indicates an agentic AI powered attack, something we had not seen before », et note que les scripts contiennent des passages où « the agent justifies its own actions ». Elle attribue la limitation des dégâts à la segmentation de son réseau et à la rapidité de sa réponse.

Les deux failles. Le cas DIVD-2026-00015 décrit CVE-2026-102489, un détournement de session menant à l'exécution de code sous l'utilisateur zammad (versions 6.3.0 à 6.5.4), et CVE-2026-102490, une élévation de privilèges locale vers root (v1.5.0 à v7.1.0-alpha). La chronologie est serrée : exploitation le 21, analyse et reproduction les 22 et 23, signalement à Zammad le 24, divulgation limitée et avis aux victimes dès le 26. Zammad demande de passer à la version 7.2.0 et de réserver l'accès au serveur aux administrateurs de confiance. La CISA a inscrit les deux CVE à son catalogue KEV le 2 octobre.

TeamCity. CVE-2026-63077, notée 9,8, permet à un attaquant non authentifié d'exécuter des commandes sur un serveur TeamCity On-Premises par une désérialisation non sûre dans le protocole d'interrogation des agents. JetBrains l'a corrigée le 25 juillet dans les versions 2025.11.7 et 2026.1.3. Elle est entrée au catalogue KEV le 5 août, et la CISA a indiqué le 23 septembre qu'elle est exploitée dans des campagnes de rançongiciels.

Pourquoi ça compte

Un service d'assistance et un serveur de compilation ne sont pas des systèmes de production au sens habituel, et c'est précisément pourquoi ils échappent souvent au cycle de correctifs. Pourtant, le premier conserve les échanges, les pièces jointes et parfois des identifiants envoyés par les utilisateurs ; le second détient des secrets de déploiement et produit ce qui part en production.

Pour un fournisseur de services gérés (MSP) ou de sécurité gérés (MSSP), l'effet est multiplié : le même système de billets, le même pipeline et le même outil d'accès à distance servent tous les clients. Un seul outil compromis donne une vue, parfois un accès, sur chacun d'eux.

La seconde leçon porte sur la vitesse. DIVD a enquêté, signalé et divulgué en cinq jours, ce qui est exemplaire. Mais si l'attaquant est automatisé, comme l'organisation le pense, l'enchaînement de deux failles jusqu'à root ne prend que quelques minutes. Pour TeamCity, plus de deux mois ont séparé le correctif de l'usage par des rançongiciels : le temps existait, il n'a pas été pris partout.

Ce que nous en pensons chez Sentrix

1. Inscrire les outils de l'équipe TI à l'inventaire des actifs exposés. Billets, intégration continue, gestion de configuration, accès à distance, coffres de mots de passe : chacun avec sa version, son exposition Internet et un propriétaire. C'est l'inventaire que le module CTEM d'exposition continue tient à jour, voir les cinq étapes du CTEM.
2. Corriger à l'inscription KEV, pas au cycle mensuel. Une entrée au catalogue déclenche la décision le jour même, avec un délai mesurable, comme le décrit notre service vulnérabilités et correctifs.
3. Sortir ces outils d'Internet. Un service d'assistance peut garder un portail public tout en réservant l'administration et le serveur à un réseau de confiance.
4. Segmenter. C'est ce qui a limité les dégâts chez DIVD : l'outil d'assistance ne doit pas voir le reste du réseau ni les environnements des clients.
5. Traiter les secrets des pipelines comme des identités. Jetons de déploiement et comptes de service se recensent, se limitent et se renouvellent, comme le rappelle notre article sur les identités non humaines et notre service identité et accès.
6. Ne jamais laisser transiter un mot de passe client dans un billet. Un coffre partagé avec journal d'accès le remplace.

La prochaine étape

Dressez aujourd'hui la liste des outils que votre équipe TI exploite pour elle-même, avec, pour chacun, sa version, son exposition à Internet et ce qu'il peut atteindre. Les lignes sans réponse sont votre priorité de la semaine. Si vous voulez faire cet exercice avec nous, contactez-nous.