Retour au blog
TeamCityJetBrainsCI/CDCVE-2026-63077contournement d'authentificationagents IA

TeamCity CVE-2026-63077 : RCE sans authentification CI/CD

Publié le 2026-07-30 · Mis à jour le 2026-10-295 min de lecture
En bref : CVE-2026-63077 est une exécution de code à distance sans authentification dans JetBrains TeamCity On-Premises, via le protocole d'interrogation des agents de build (CVSS v3.1 9,8). Toutes les versions On-Premises sont concernées ; les versions corrigées sont 2025.11.7 et 2026.1.3. L'avis a été publié le 27 juillet 2026 après un signalement privé du 10 juillet, et CISA a inscrit la faille au KEV le 5 août 2026. TeamCity Cloud est déjà protégé.

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 ?

  1. Inventoriez les serveurs TeamCity On-Premises, leur version et leur exposition réseau (page de connexion ou API REST joignable depuis Internet).
  2. Vérifiez l'exposition depuis l'extérieur : une page de connexion CI/CD accessible publiquement est le signal principal.
  3. Auditez les configurations de build : nouvelles étapes, scripts modifiés, variables d'environnement ajoutées, comptes administrateur inattendus, agents enregistrés inconnus.
  4. 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.

Sachez ce que votre agent peut faire avant un attaquant.

Rendez-vous découverte de 30 minutes, gratuit : vous décrivez votre agent, je vous dis ce que je testerais et à quel prix. Cinq études de cas sont publiées.

Prendre rendez-vous