JetBrains TeamCity : un contournement d'auth critique menant à la RCE sur votre serveur CI/CD
> En bref : JetBrains avertit d'une vulnérabilité critique de contournement d'authentification dans TeamCity On-Premises qui pourrait être exploitée pour une exécution de code à distance. TeamCity est un serveur CI/CD — une compromission donne à l'attaquant l'accès aux pipelines de build, aux identifiants de déploiement, au code source et aux clés de déploiement de chaque environnement que le serveur peut atteindre. Correctif disponible.
Pourquoi ça vous concerne
Si votre équipe d'ingénierie auto-héberge TeamCity pour la CI/CD (beaucoup d'environnements enterprise et régulés le font, pour des raisons de souveraineté), c'est un incident supply chain qui attend d'arriver. Une compromission de serveur CI/CD, c'est le pattern SolarWinds à l'échelle d'une équipe : l'attaquant récupère votre code source, vos artifacts de build et vos identifiants de déploiement en un seul mouvement.
Cela suit le même pattern que la RCE GitLab que nous avons couverte — infrastructure dev auto-hébergée avec un contournement d'authentification qui mène à l'exécution de code. Le fil conducteur : ces plateformes ont été conçues pour l'intranet et sont régulièrement exposées à Internet.
La faille et son impact
Un contournement d'authentification permet à un attaquant non authentifié d'atteindre des fonctionnalités authentifiées sur le serveur TeamCity. De là, le chemin vers la RCE dépend de la configuration du serveur, mais le contexte CI/CD rend l'impact sévère quoi qu'il arrive :
Ce qu'il faut faire
Le pattern de surface d'attaque CI/CD
TeamCity, GitLab, Jenkins, GitHub Actions runners — chaque grande plateforme CI/CD a eu un contournement d'auth critique ou une RCE ces 18 derniers mois. La raison est structurelle : les serveurs CI/CD sont des cibles à forte valeur (ils détiennent chaque secret de l'organisation d'ingénierie) avec des modèles de permissions complexes et une exposition Internet historique. Pour un éditeur SaaS, la réponse opérationnelle est cohérente : la CI/CD auto-hébergée appartient derrière un VPN, sur un cycle de patch court, avec ses secrets dans un vault dédié — pas dans des variables de build.
Vous éditez un logiciel RH, paie ou recrutement ? CleanIssue réalise des audits de sécurité pour SaaS RH en conditions réelles, sans accès au code. Pour une première lecture de votre exposition, commencez par une revue externe de votre application.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
JFrog Artifactory CVE-2026-82329 : un token JWT signé avec une clé vide donne les droits admin
CVE-2026-82329 (CVSS 9,8) permet à un attaquant non authentifié de forger un JWT admin sur les instances Artifactory auto-hébergées non durcies, en exploitant une clé de cluster vide par défaut. L'accès obtenu permet de contrôler dépôts, utilisateurs et configuration — un risque direct d'empoisonnement de la chaîne d'approvisionnement logicielle.
RCE GitLab via Oj : une chaîne de corruption mémoire cachée dans un patch non-sécurité
Deux bugs de corruption mémoire dans Oj (parser JSON Ruby) permettent à tout utilisateur authentifié de lancer des commandes en tant que `git` sur les GitLab auto-hébergés <18.10.8 / <18.11.5 / <19.0.2, via des notebooks Jupyter forgés. Le correctif a été livré le 10 juin mais listé en bug fixes, pas en sécurité. PoC publié le 24 juillet.
Langflow CVE-2026-9198 : une RCE non authentifiée sur la plateforme IA exploitée en masse
CVE-2026-9198 (CVSS 9.8) permet une exécution de code à distance non authentifiée sur les déploiements par défaut de Langflow, une plateforme open source de développement d'applications IA. 650 tentatives d'exploitation recensées depuis juillet 2026.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.