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.
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.
Gitea CVE-2026-20896 : un contournement d'authentification en un header, livré dans l'image Docker officielle
L'image Docker officielle de Gitea livrait `REVERSE_PROXY_TRUSTED_PROXIES=*`, donc avec l'authentification reverse-proxy activée, un client Internet non authentifié devenait celui qu'il prétendait être via le header X-WEBAUTH-USER. CVSS 9.8, exploitation active. Correctif : Gitea 1.26.3 / 1.26.4.
Rails Active Storage : une faille critique avec lecture de fichiers arbitraires et potentiel de RCE
Une vulnérabilité critique dans le framework Active Storage de Rails permet à un attaquant non authentifié de lire des fichiers arbitraires sur le serveur applicatif, avec un potentiel d'escalade vers l'exécution de code à distance. Affecte les applications Ruby on Rails utilisant Active Storage. Correctif disponible.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.