TeamCity CVE-2026-63077 : RCE sans authentification CI/CD
Que permet CVE-2026-63077 ?
Selon BleepingComputer et la NVD, un attaquant qui peut joindre le serveur TeamCity en HTTPS contourne l'authentification via le protocole d'interrogation des agents de build et exécute des commandes système avec les privilèges du processus serveur. Il s'agit d'une exécution de code à distance sans compte ni interaction. JetBrains décrit les conséquences possibles : exposition des données, des configurations et des identifiants stockés, ou compromission des artefacts de build et des pipelines CI/CD selon les privilèges.
Qui est concerné et quelles versions corrigent ?
Toutes les versions de TeamCity On-Premises. Les versions corrigées sont 2025.11.7 et 2026.1.3. Les clients de TeamCity Cloud n'ont rien à faire : JetBrains a appliqué les mesures nécessaires. Pour ceux qui ne peuvent pas mettre à jour, un plugin de correctif de sécurité existe pour TeamCity 2017.1 et suivantes ; il est téléchargé automatiquement à partir de 2024.03, et les versions 2017.1 à 2018.1 exigent un redémarrage du serveur après l'installation.
Comment la faille est-elle exploitée ?
Au moment de l'avis, JetBrains ne signalait pas d'exploitation. L'inscription au KEV le 5 août montre qu'elle l'est depuis. L'historique de TeamCity va dans le même sens : BleepingComputer rappelle des failles antérieures exploitées pour créer des comptes administrateur, par des groupes de rançongiciel et par des acteurs étatiques. Un serveur CI/CD concentre ce que cherchent les attaquants : code source, secrets de build, certificats de signature, accès aux environnements de déploiement.
Comment savoir si vous êtes exposé et comment tester ?
- Inventoriez les serveurs TeamCity On-Premises, leur version et leur exposition réseau (page de connexion ou API REST joignable depuis Internet).
- Vérifiez l'exposition depuis l'extérieur : une page de connexion CI/CD accessible publiquement est le signal principal.
- Auditez les configurations de build : nouvelles étapes, scripts modifiés, variables d'environnement ajoutées, comptes administrateur inattendus, agents enregistrés inconnus.
- Examinez les journaux du serveur pour des requêtes inhabituelles vers le protocole des agents avant la mise à jour.
Comment corriger ?
Mettez à jour vers 2025.11.7 ou 2026.1.3, ou installez le plugin de correctif si la mise à jour est impossible. JetBrains recommande aussi d'utiliser un VPN ou une autre couche de protection pour les serveurs accessibles depuis Internet. Après une exposition, faites tourner tous les secrets que le serveur pouvait atteindre (identifiants cloud, clés de déploiement, certificats de signature, jetons de registre de conteneurs), vérifiez l'intégrité des artefacts produits pendant la fenêtre d'exposition en les comparant à des versions connues ou en recompilant depuis un état sain, et restreignez l'enregistrement de nouveaux agents.
Que change l'accès d'un agent IA à une chaîne CI/CD ?
La CI/CD est l'endroit où les agents IA reçoivent le plus de pouvoir : agents de programmation qui ouvrent des demandes de fusion, déclenchent des builds, lisent des journaux d'échec, corrigent des tests, parfois déploient. Ils héritent des variables d'environnement, des jetons et des droits du pipeline. Un serveur CI/CD compromis donne à l'attaquant ces secrets et la capacité de modifier ce que les agents exécutent.
Trois effets propres aux agents. Le journal de build comme entrée non fiable : un agent qui lit des journaux, des messages de commit ou des sorties de tests peut y trouver une instruction injectée (OWASP LLM01), et une injection dans un pipeline agit avec les secrets du pipeline. Les secrets accessibles à l'agent : une clé de déploiement présente dans l'environnement où tourne l'agent est lisible par tout code qu'il exécute (LLM02). Et l'autonomie : un agent autorisé à déclencher un déploiement sans validation transforme une compromission de la chaîne en mise en production. Les contrôles utiles : secrets dans un coffre dédié avec jetons à courte durée, environnement d'exécution de l'agent sans accès aux identifiants de production, validation humaine avant tout déploiement, et segmentation du serveur CI/CD. Voir la sécurité des agents IA, l'affaire GitLab Oj et Azure DevOps MCP.
Pourquoi le protocole des agents de build est-il une surface sensible ?
Les agents de build se connectent au serveur pour recevoir du travail, souvent depuis des réseaux variés (machines virtuelles, postes, conteneurs, prestataires). Le serveur expose donc un point d'accès conçu pour être appelé par des machines, parfois depuis l'extérieur, avec une logique d'authentification propre. Une erreur à cet endroit contourne tout le reste, y compris le contrôle d'accès des utilisateurs. Placer le serveur derrière un VPN ou un tunnel authentifié, et n'autoriser l'enregistrement que d'agents approuvés, réduit cette surface.
Quels signes révèlent une compromission de pipeline ?
Cherchez des étapes de build ajoutées ou modifiées sans demande de fusion associée, des variables d'environnement nouvelles, des artefacts dont l'empreinte diffère d'une reconstruction propre, des téléchargements sortants depuis les agents vers des adresses inconnues et des comptes ou jetons créés en dehors des horaires habituels. Conservez les journaux du serveur avant toute mise à jour pour faciliter l'analyse.
Comment tester son agent sur TeamCity CVE-2026-63077 ?
Un test de red team d'agent place une instruction piégée dans ce que l'agent lit en CI (journal, commentaire, fichier de configuration) et mesure les secrets qu'il voit, les commandes qu'il lance et les déploiements qu'il peut déclencher. En cinq jours et pour 1 900 €, le Red Team Agent Express teste ce qu'un agent de build peut faire si TeamCity est pris sans authentification. La méthode détaille la démarche.
Quelle leçon en tirer ?
Un serveur CI/CD auto-hébergé appartient derrière un VPN, sur un cycle de correctifs court, avec ses secrets dans un coffre et non dans des variables de build. Ajoutez à cela un principe pour les agents : tout ce qu'un pipeline peut faire, un agent détourné peut le faire.
Votre produit embarque un agent IA ? CleanIssue teste ce qu’un inconnu peut lui faire faire avec le Red Team Agent Express (5 jours, 1 900 €), ou un red team sur mesure pour plusieurs agents et serveurs MCP. Premier échange : un rendez-vous découverte de 30 minutes, gratuit.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
N-able N-central CVE-2026-18577 : contournement d'auth
CVE-2026-18577 : contournement d'authentification dans N-able N-central, exploité avec des tunnels Cloudflare. Versions, correctifs, détection, agents IA.
N-central CVE-2026-86218 : RCE pré-auth CVSS 10
CVE-2026-86218 : exécution de code sans authentification dans N-able N-central, corrigée par le Hotfix 4. Détection, correctifs et risque côté agents IA.
Gitea CVE-2026-20896 : contournement d'auth via Docker
CVE-2026-20896 : l'image Docker Gitea fait confiance à X-WEBAUTH-USER depuis toute IP (CVSS 9.8). Détection, correctif 1.26.4, risques pour les agents IA.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.