JetBrains Cadence compromis par une faille TeamCity non corrigée, des identifiants AWS IAM exfiltrés
Des attaquants ont exploité CVE-2026-63077 (CVSS 9.8) pour pénétrer Cadence, le service cloud GPU de JetBrains, entre le 8 et le 24 août 2026, et exfiltrer des identifiants AWS IAM ainsi que des données stockées dans des buckets S3. Révoquez et faites tourner tous les identifiants et secrets liés à Cadence sans attendre.
5 septembre 2026. JetBrains révèle que des attaquants ont pénétré Cadence, son service cloud de calcul GPU, en exploitant une faille critique de TeamCity — le produit que l’éditeur fabrique lui-même. L’intrusion, qui s’est déroulée du 8 au 24 août 2026, a permis d’exfiltrer des identifiants AWS IAM et des données stockées dans des buckets S3. Pourquoi c’est important : un éditeur d’outils de développement n’a pas patché sa propre instance de son propre serveur d’intégration continue, et ce sont les secrets cloud de ses clients qui en ont payé le prix.
Cadence, un GPU cloud branché sur l’IDE
Cadence est un service hébergé par JetBrains qui s’intègre à PyCharm via un plugin optionnel. Sa promesse : lancer des charges lourdes — apprentissage automatique, entraînement de modèles, calcul intensif — sur des GPU cloud directement depuis l’IDE, sans gérer soi-même l’infrastructure.
Cette promesse a un corollaire invisible. Pour que les exécutions fonctionnent, Cadence doit conserver des identifiants cloud : des clés AWS IAM, des secrets, des jetons d’accès, des chemins vers des buckets S3. C’est précisément ce qu’un attaquant cherche quand il vise un service de ce type. Un compromis ne frappe pas des fichiers statiques, mais le coffre à secrets d’un parc de développeurs.
CVE-2026-63077, la faille TeamCity que JetBrains n’a pas corrigée chez lui
Le point d’entrée est CVE-2026-63077, une désérialisation de données non fiables dans TeamCity, notée CVSS 9.8. Elle permet à un attaquant non authentifié disposant d’un accès réseau au serveur de contourner l’authentification et d’exécuter des commandes système arbitraires avec les privilèges du processus TeamCity. Autrement dit, une exécution de code à distance sans aucune condition préalable d’identification.
La faille est connue depuis des semaines. La CISA l’a inscrite au catalogue KEV (Known Exploited Vulnerabilities) le 5 août 2026, signe qu’elle était déjà exploitée dans la nature. JetBrains a corrigé le produit — mais, de son propre aveu, le serveur Cadence compromis n’avait pas reçu le correctif. La société concède que l’instance en question « aurait dû être patchée dans le cadre de sa propre réponse aux vulnérabilités », sans expliquer pourquoi elle ne l’a pas été.
L’ironie est lourde. TeamCity est un serveur d’intégration continue vendu pour orchestrer des pipelines et manipuler des secrets de déploiement. L’éditeur qui le commercialise n’a pas appliqué son propre correctif à sa propre infrastructure de production. C’est la version moderne du cordonnier mal chaussé, transposée à l’ère du cloud.
Ce que l’attaquant a obtenu
JetBrains a découvert l’intrusion le 23 août 2026. L’attaquant est resté actif du 8 au 24 août. La liste des données confirmées comme accédées ou compromises est longue :
- Des données personnelles : noms d’utilisateur, vrais noms, adresses e-mail, horodatages de dernière connexion, dernières adresses IP.
- Une sauvegarde complète du serveur Cadence datant de 2024, contenant identifiants, configuration, artefacts et journaux.
- Plusieurs utilisateurs AWS IAM et les identifiants/secrets associés utilisés avec Cadence, y compris des IAM appartenant à des employés de JetBrains.
- Des fichiers stockés dans des buckets S3 des comptes AWS de JetBrains utilisés par le service.
- Potentiellement du code source synchronisé depuis PyCharm vers le serveur compromis, ce qui recouvre les scénarios où des développeurs ont téléversé des fichiers de projet pour exécution.
Le serveur exploité, api.cadence.jetbrains.com, a été mis hors ligne. JetBrains a également invalidé tous les jetons d’accès utilisés par le plugin Cadence dans PyCharm.
Des indicateurs de compromission à traiter comme une alerte
JetBrains a publié une liste d’indicateurs. L’activité malveillante est observable à partir du 8 août 2026, notamment des authentifications ou des actions menées avec des identifiants précédemment stockés dans — ou accessibles via — Cadence. Les adresses IP associées à l’exploitation observée sont :
150.109.230.104
43.153.227.206
62.210.127.48
210.247.242.190
15.235.225.205
152.233.30.18Au-delà de ces IP, JetBrains invite les équipes à surveiller tout signe d’activité anormale : authentifications depuis des adresses inattendues, clonages ou commits de dépôts non sollicités, modifications de secrets de dépôt ou de webhooks, nouveaux tokens d’accès, nouveaux comptes de service, changements de rôles IAM dans le cloud, accès inhabituels à du stockage S3, et publications ou modifications de paquets non prévues.
Le serveur d’intégration continue, nouvelle porte d’entrée du cloud
TeamCity n’est pas une cible isolée. Les serveurs d’intégration continue — TeamCity, Jenkins, GitLab CI — sont devenus la porte d’entrée privilégiée des attaquants vers le cloud, pour une raison simple : ils concentrent les secrets de déploiement. Une clé IAM qui vit dans un pipeline vaut plus qu’un mot de passe, car elle ouvre directement le compte AWS qui héberge la production.
L’historique récent le confirme. TeamCity a déjà été massivement exploité début 2024 via CVE-2024-27198 et CVE-2024-27199, deux failles d’authentification et d’exécution de code qui ont permis à des groupes de ransomware de pénétrer des réseaux entiers. Le fournisseur d’analyse de code Codecov a été compromis en 2021, CircleCI en janvier 2023 — à chaque fois, l’enjeu était le même : des identifiants cloud hébergés dans un outil de développement, puis revendus ou exploités. CVE-2026-63077 s’inscrit dans la même lignée, à la différence près que la victime est ici l’éditeur du produit lui-même.
La leçon est structurelle. Les clés AWS IAM statiques et à longue durée de vie sont le pire choix dans un contexte d’intégration continue : une fois exfiltrées, elles restent valides jusqu’à leur révocation manuelle, quel que soit le délai de détection. L’OIDC et les jetons à durée de vie courte, qui expirent avant d’être exploitables, sont la réponse technique à cette classe d’incident — celle que JetBrains vient d’illustrer malgré lui.
Ce qu’il faut faire
La consigne de JetBrains est sans ambiguïté : révoquer ou faire tourner immédiatement tous les identifiants et secrets susceptibles d’avoir servi à des exécutions Cadence, et traiter toutes les exécutions comme potentiellement compromises. En pratique, cela signifie :
- Faire tourner les clés AWS IAM exposées et auditer les buckets S3, les environnements de déploiement et les registres accessibles avec ces identifiants.
- Auditer les dépôts de code source pour repérer toute modification non autorisée sur la période du 8 au 24 août.
- Surveiller les comptes de service et les changements de politiques IAM dans AWS et Google Cloud.
# Lister les clés d’accès d’un utilisateur IAM
aws iam list-access-keys --user-name mon-utilisateur
# Désactiver une clé potentiellement compromise
aws iam update-access-key --user-name mon-utilisateur --access-key-id AKIA... --status InactiveCes gestes ne protègent pas que de cet incident : ils réduisent la surface de toute la classe des compromissions de secrets hébergés chez un tiers. La conséquence la plus probable, selon JetBrains, est une hausse du phishing ciblé et de l’ingénierie sociale exploitant les noms et adresses e-mail exposés — un rappel que le coût d’une fuite d’identifiants se paie souvent en amont d’une autre attaque.
Verdict
Si vous avez utilisé Cadence, révoquez et faites tourner tous les identifiants liés, en commençant par les clés AWS IAM : l’attaquant a explicitement exfiltré ce type de secrets, et la fenêtre d’intrusion (plus de deux semaines) laisse le temps d’un usage différé.
Si vous exploitez un service cloud qui héberge vos secrets, relisez la leçon de cet incident : le correctif existe depuis le 5 août, mais il n’a pas été appliqué à l’instance qui comptait. Privilégiez des jetons à durée de vie courte et l’OIDC plutôt que des clés statiques de longue durée, afin qu’un secret exfiltré expire avant d’être exploitable.