Une faille critique TeamCity notée CVSS 9.8 permet à un attaquant non authentifié de prendre le contrôle complet du serveur d’intégration continue. Pour une PME-ETI, cela signifie bien plus qu’un serveur de build compromis : c’est l’accès aux secrets de déploiement, aux clés de signature et, in fine, au code livré à vos clients. Ce tutoriel détaille comment détecter, corriger et durcir votre instance JetBrains TeamCity en quelques heures.
Pourquoi la faille critique TeamCity menace toute la chaîne CI/CD
Un serveur TeamCity n’est pas un serveur comme les autres. Il concentre par conception les éléments les plus sensibles du système d’information :
- les identifiants de déploiement vers vos environnements de production ;
- les jetons d’accès aux dépôts Git, aux registres d’images et aux clouds ;
- les clés de signature de paquets et d’applications ;
- un droit d’exécution de code arbitraire, légitime, sur chaque agent de build.
Une prise de contrôle du serveur donne donc à l’attaquant un accès de niveau administrateur à la production, sans jamais toucher directement à la production. C’est le scénario type d’une attaque de supply chain logicielle : le code compromis est signé, distribué et exécuté par vos propres pipelines de confiance.
Le contexte : des serveurs de build exposés à Internet
Les précédentes vagues d’exploitation de TeamCity ont montré un schéma constant : les instances vulnérables sont massivement exposées sur Internet, souvent pour permettre aux développeurs distants ou aux webhooks des forges externes d’y accéder. Les groupes étatiques comme les affiliés ransomware scannent ces ports en continu. Avec une faille non authentifiée à CVSS 9.8, la fenêtre entre la publication du correctif et l’exploitation massive se compte désormais en heures — un phénomène que nous avons détaillé dans notre article sur la réduction de la fenêtre de patch N-day.
Étape 1 — Inventorier vos instances TeamCity
Avant de corriger, il faut savoir ce que vous exposez. Beaucoup d’organisations découvrent une instance de test oubliée, montée par une équipe projet, jamais mise à jour.
- Recherchez les ports TeamCity par défaut (8111/tcp, et 443 derrière un reverse proxy) sur l’ensemble de vos plages internes et de vos adresses publiques.
- Interrogez votre inventaire DNS pour les enregistrements de type
teamcity.*,ci.*,build.*. - Vérifiez la version exacte via l’interface d’administration ou l’API :
curl -s https://votre-teamcity/app/rest/server | grep -o 'version="[^"]*"'. - Listez les agents de build enregistrés et leurs machines hôtes — ce sont autant de rebonds possibles.
Étape 2 — Appliquer le correctif JetBrains sans attendre
JetBrains publie des versions correctives pour la branche courante de TeamCity. La marche à suivre est directe :
- Sauvegardez la base de données et le répertoire de données avant toute opération.
- Appliquez la mise à jour vers la dernière version corrigée de votre branche majeure.
- Si la mise à jour immédiate est impossible, appliquez le correctif de contournement fourni par JetBrains sous forme de plugin de sécurité, puis planifiez la montée de version.
- Redémarrez le service et revalidez la version via l’API avant de rouvrir les accès.
Le cas des instances qui ne peuvent pas s’arrêter
Si un arrêt de la chaîne CI/CD est inacceptable en journée, coupez d’abord l’exposition réseau plutôt que le service. Restreindre l’accès au serveur à un VPN ou à une liste d’adresses IP autorisées réduit immédiatement la surface d’attaque, sans interrompre les builds internes. Le correctif peut alors être appliqué lors de la fenêtre de maintenance suivante.
Étape 3 — Chasser les signes de compromission
Une faille critique TeamCity exploitée laisse des traces caractéristiques. Après le correctif, considérez l’instance comme potentiellement compromise jusqu’à preuve du contraire :
- Comptes administrateurs inconnus : listez les utilisateurs disposant du rôle System Administrator et leur date de création.
- Jetons d’accès récents : tout jeton API créé depuis la date de publication de la faille doit être justifié ou révoqué.
- Étapes de build ajoutées : inspectez l’historique de modification des configurations, en cherchant les étapes de type script shell ou PowerShell insérées récemment.
- Plugins installés : un plugin non répertorié dans votre référentiel interne est un indicateur fort de persistance.
- Trafic sortant anormal depuis le serveur ou les agents vers des domaines inconnus.
Centralisez les journaux TeamCity (teamcity-server.log, teamcity-auth.log) dans votre SIEM. Sur nos environnements, les règles Wazuh sur les authentifications échouées suivies d’une création de compte administrateur détectent ce chaînage en quelques secondes.
Étape 4 — Rotation des secrets, l’étape que l’on saute trop souvent
C’est le point le plus coûteux et le plus négligé. Si l’exposition a duré, partez du principe que tous les secrets stockés dans TeamCity ont fuité :
- jetons Git, GitHub, GitLab et clés de déploiement ;
- identifiants de registres Docker et de dépôts d’artefacts ;
- clés cloud (AWS, Azure, GCP) utilisées par les pipelines ;
- certificats et clés de signature de code.
La rotation doit être totale, pas sélective. Un seul jeton oublié suffit à rétablir l’accès de l’attaquant après votre remédiation — la logique exacte que nous décrivions pour les secrets exposés sur GitHub.
Étape 5 — Durcir durablement votre CI/CD
Corriger une faille critique TeamCity ne suffit pas : la prochaine arrivera. Quelques mesures structurantes réduisent durablement l’impact :
- Ne jamais exposer le serveur CI directement sur Internet. Placez-le derrière un VPN ou un proxy authentifiant, et n’ouvrez que les webhooks strictement nécessaires, filtrés par IP source.
- Isoler les agents de build dans un réseau dédié, sans accès latéral au SI de production.
- Externaliser les secrets dans un coffre-fort (HashiCorp Vault, AWS Secrets Manager) avec des jetons à durée de vie courte, plutôt que de les stocker dans TeamCity.
- Appliquer le moindre privilège aux comptes de service : un pipeline de test n’a pas besoin des droits de déploiement en production.
- Surveiller les modifications de configuration comme des événements de sécurité, au même titre qu’un changement de règle de pare-feu.
- Suivre les avis JetBrains et intégrer la CI/CD dans votre processus de gestion des vulnérabilités, avec un SLA de correction de 24 à 48 heures pour les CVSS ≥ 9.
Ce qu’il faut retenir
La faille critique TeamCity CVSS 9.8 rappelle une réalité inconfortable : votre chaîne CI/CD est un système de production à part entière, avec les privilèges les plus élevés de votre SI. Elle mérite le même niveau de patching, de surveillance et de segmentation qu’un contrôleur de domaine. Inventoriez, corrigez, chassez les traces, faites tourner vos secrets — puis sortez ce serveur d’Internet. C’est le meilleur investissement de sécurité que vous ferez cette semaine.
Chez ucyber.ai, notre Agentic SOC corrèle en continu les avis éditeurs, l’exposition réelle de vos actifs et la télémétrie de vos serveurs de build pour prioriser les correctifs qui comptent vraiment.