Le 28 juillet 2026, JetBrains a publié un avis de sécurité concernant CVE-2026-63077, une vulnérabilité d’exécution de code arbitraire dans TeamCity. Le score CVSS annoncé est de 9,8 sur 10, et la formulation de l’avis est de celles qui ne laissent pas de marge d’interprétation : toutes les versions de TeamCity On-Premises sont concernées. Les correctifs sont disponibles dans les versions 2025.11.7 et 2026.1.3.
Pourquoi une faille CI est pire qu’une faille applicative
Un score de 9,8 attire l’attention, mais il ne dit pas l’essentiel. Ce qui rend cette vulnérabilité particulièrement coûteuse, c’est la nature de la machine concernée.
Un serveur d’intégration continue est, par construction, l’un des systèmes les plus privilégiés d’une organisation technique. Il détient les jetons de déploiement vers la production. Il stocke les identifiants des registres d’images et des gestionnaires de paquets. Il possède souvent un accès en écriture aux dépôts de code, parfois les clés de signature des artefacts. Et surtout : tout ce qu’il produit est considéré comme légitime par le reste de la chaîne.
La conséquence est directe. Un attaquant qui exécute du code sur un serveur TeamCity n’a pas besoin d’attaquer votre production : il lui suffit d’attendre le prochain déploiement. Le code malveillant emprunte votre propre pipeline, signe avec vos propres clés, et arrive en production par le chemin nominal. C’est la définition même d’une compromission de chaîne d’approvisionnement logicielle, et c’est ce qui distingue cette faille d’une vulnérabilité sur un serveur applicatif isolé.
💡 Notre avis d’expert — le CI est le maillon qu’on oublie de traiter comme de la production
La plupart des équipes appliquent à leur serveur de build un niveau d’exigence très inférieur à celui de leur production. Il a été installé vite, souvent par une seule personne, il est rarement dans le périmètre des audits, et sa mise à jour est repoussée parce qu’elle interrompt le travail de toute l’équipe. Ce raisonnement est exactement inversé : le serveur CI mérite un niveau de protection supérieur à la production, parce qu’il peut écrire dans la production alors que l’inverse n’est pas vrai.
Les 4 réflexes, dans l’ordre
L’ordre compte : chaque étape réduit une fenêtre d’exposition différente.
- Vérifiez votre version, sans supposer. L’avis vise toutes les versions On-Premises. Une installation de 2023 restée stable est vulnérable au même titre qu’une installation récente. Relevez la version exacte depuis l’interface d’administration plutôt que depuis la mémoire de l’équipe. Les instances TeamCity Cloud sont gérées par l’éditeur et ne relèvent pas de cette action.
- Mettez à jour vers 2025.11.7 ou 2026.1.3. C’est la seule action qui corrige réellement le problème. Choisissez la branche correspondant à votre version installée pour limiter les effets de bord sur les configurations de build existantes.
- Si la montée de version doit attendre, retirez l’exposition publique. Un serveur TeamCity accessible depuis Internet est une cible triviale à découvrir. Le placer derrière un VPN ou une liste d’adresses autorisées ne corrige pas la faille mais réduit fortement la probabilité d’exploitation opportuniste. Traitez cette mesure comme un sursis, pas comme une solution.
- Faites tourner les secrets si le serveur a été exposé. C’est l’étape la plus souvent omise, et la plus importante. Corriger empêche une exploitation future ; cela n’annule pas un accès qui aurait déjà eu lieu. Jetons de déploiement, clés SSH de build, identifiants de registre, variables d’environnement sensibles : tout ce que le serveur connaissait doit être considéré comme potentiellement connu d’un tiers.
Pourquoi corriger ne suffit pas : les deux fenêtres d’exposition
Une semaine chargée côté vulnérabilités
CVE-2026-63077 n’est pas arrivée seule. La dernière semaine de juillet 2026 a été dense pour les équipes chargées du maintien en condition de sécurité.
Le 27 juillet, des détails d’exploitation publics ont été diffusés pour une exécution de code à distance dans vBulletin : une requête non authentifiée parvient à atteindre la fonction eval() de PHP et à exécuter du code sur un forum non corrigé. Ni compte, ni accès administrateur, ni interaction d’un tiers ne sont nécessaires. Pour les organisations qui hébergent encore un forum communautaire hérité, c’est le genre d’actif oublié qui devient une porte d’entrée.
Le 28 juillet également, CVE-2026-53264 a été publiée : une situation de compétition de type use-after-free dans le sous-système de contrôle de trafic réseau du noyau Linux, notée 7,8. Un détail de cette divulgation mérite d’être relevé : le chercheur Lee Jia Jie a indiqué que l’intelligence artificielle l’avait aidé à découvrir le bogue et à accélérer le développement de l’exploit.
💡 Notre avis d’expert — l’asymétrie de rythme est le vrai sujet
Quand la recherche de vulnérabilités s’outille avec de l’IA, c’est le délai entre publication et exploitation qui se comprime, pas seulement le nombre de failles trouvées. Un cycle de correctifs calé sur un rythme trimestriel était défendable quand ce délai se comptait en semaines. Il l’est beaucoup moins aujourd’hui. La question à poser en rétrospective n’est pas « avons-nous corrigé » mais « combien de temps avons-nous mis » — et cette métrique-là, peu d’équipes la mesurent.
Ce que cet incident dit de votre inventaire
Une difficulté récurrente apparaît à chaque avis de ce type : beaucoup d’équipes ne savent pas répondre rapidement à la question « combien d’instances TeamCity avons-nous, et où ? ». Un serveur de build installé il y a quatre ans pour un projet qui a survécu, hébergé sur une machine dont le propriétaire a changé d’équipe, reste en ligne et reste vulnérable.
Le coût réel d’une CVE critique ne se mesure donc pas au temps d’application du correctif, mais au temps nécessaire pour établir la liste des machines concernées. Les organisations qui tiennent un inventaire à jour de leurs services internes traitent ce type d’avis en une demi-journée. Les autres découvrent des instances oubliées pendant des semaines — parfois à l’occasion de l’incident lui-même.
Si vous devez retenir une seule action structurelle de cet épisode, ce n’est pas « mettre à jour TeamCity » : c’est savoir en une commande ce qui tourne dans votre périmètre. Toutes les autres bonnes pratiques en dépendent.
Votre chaîne CI/CD a-t-elle déjà été auditée ?
Inventaire des instances, exposition réseau, gestion des secrets, politique de mise à jour. Nous regardons la chaîne complète, pas seulement le serveur.
Discutons-en →Rayon d’action d’un serveur CI compromis
Questions fréquentes
Quelles versions de TeamCity sont concernées ?
Toutes les versions On-Premises. Les correctifs sont publiés dans 2025.11.7 et 2026.1.3. Il n’existe pas de version antérieure épargnée : l’ancienneté d’une installation ne constitue en aucun cas une protection.
Quel est le niveau de gravité réel ?
9,8 sur 10 en CVSS, avec exécution de code arbitraire à la clé. Mais la gravité opérationnelle dépasse le score : un serveur CI concentre les accès privilégiés de toute la chaîne de livraison. Le compromettre revient à obtenir un droit d’écriture indirect sur la production.
Que faire si je ne peux pas mettre à jour tout de suite ?
Retirez l’interface de l’exposition publique : VPN ou liste d’adresses autorisées. C’est une réduction de surface d’attaque, pas un correctif. Planifiez la mise à jour dans la foulée et prévoyez la rotation des secrets.
Faut-il faire tourner les secrets même après correction ?
Oui, dès lors que le serveur a été joignable publiquement avant le correctif. La mise à jour ferme la porte ; elle ne révoque pas ce qui a pu sortir. La rotation est la seule manière de reprendre la main sur une fenêtre d’exposition dont vous ne connaissez pas la durée.
Pour aller plus loin
- Comment créer un CRM sur mesure — les arbitrages d’architecture, y compris la chaîne de déploiement
- Comment créer une plateforme freelance — gérer les secrets et les accès dès la conception
- WebGuard Agency — audits de sécurité et conformité pour les PME françaises
- Plug-Tech — l’angle IA et automatisation pour les équipes techniques
Besoin d’un regard extérieur sur votre infrastructure ?
Inventaire, exposition, gestion des secrets, politique de correctifs : nous établissons l’état des lieux et la liste des actions, par ordre de priorité réelle.
Discutons-en →