Une compromission de JetBrains Cadence a exposé des identifiants AWS après l’exploitation d’une RCE dans TeamCity

JetBrains a révélé une compromission de son service de cloud computing Cadence après que des attaquants non identifiés ont exploité CVE-2026-63077, une vulnérabilité critique d’exécution de code à distance dans TeamCity.

L’intrusion a touché le serveur Cadence à l’adresse api.cadence.jetbrains.com, que JetBrains a mis hors ligne. Les attaquants ont accédé à une sauvegarde du serveur, extrait des identifiants AWS et atteint des fichiers stockés dans des buckets S3 associés au service.

JetBrains a détecté l’exploitation le 23 août 2026. La période d’intrusion s’est étendue du 8 au 24 août 2026, et toute activité observée à partir du 8 août doit être considérée comme potentiellement suspecte.

L’entreprise a indiqué que le serveur TeamCity aurait dû recevoir une mise à jour dans le cadre de son processus de traitement des vulnérabilités. Elle n’a pas expliqué pourquoi le correctif n’avait pas été appliqué.

Un serveur TeamCity non corrigé a ouvert la voie

CVE-2026-63077 est une vulnérabilité d’exécution de code à distance et sans authentification qui affecte le protocole d’interrogation des agents de JetBrains TeamCity. Elle est classée CWE-502, désérialisation de données non fiables.

Un attaquant capable d’atteindre un serveur TeamCity vulnérable peut exploiter cette faille sans identifiants ni interaction de l’utilisateur. Une exploitation réussie permet d’exécuter arbitrairement des commandes du système d’exploitation avec les privilèges attribués au processus du serveur TeamCity.

La vulnérabilité affiche un score CVSS v3 de 9,8 et le vecteur suivant :

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Cette évaluation reflète une attaque accessible par le réseau, de faible complexité, ne nécessitant aucun privilège préalable ni aucune action de la part d’un utilisateur légitime. Une compromission réussie peut avoir des conséquences importantes sur la confidentialité, l’intégrité et la disponibilité.

Les versions concernées couvrent deux branches de TeamCity. Les déploiements antérieurs à 2025.11.7 sont vulnérables, tandis que la description de la NVD identifie également les versions antérieures à 2026.1.3 et 2025.11.7 comme vulnérables. Les administrateurs doivent donc utiliser la version corrigée correspondant à la branche installée, plutôt que de considérer 2025.11.7 comme une limite de version universelle.

JetBrains n’a pas communiqué la version exacte de TeamCity installée sur le serveur Cadence compromis. L’entreprise s’est contentée de qualifier le déploiement de non corrigé.

La CISA avait déjà confirmé l’exploitation active

La CISA a ajouté CVE-2026-63077 à son catalogue des vulnérabilités exploitées connues le 5 août 2026. La date limite de remédiation imposée aux agences fédérales américaines était fixée au 8 août 2026, soit le jour où a commencé la période d’intrusion signalée chez Cadence.

L’inscription au catalogue KEV signifie que la vulnérabilité n’était pas seulement considérée comme exploitable en théorie. La CISA disposait de preuves d’exploitation dans le cadre d’attaques réelles.

L’agence exige des organisations concernées qu’elles appliquent les mesures d’atténuation du fournisseur tout en respectant la directive BOD 26-04, « Prioritizing Security Updates Based on Risk », ainsi que ses exigences en matière de triage forensique. Pour les services cloud, les agences doivent suivre les recommandations applicables de la BOD 26-04 ou cesser d’utiliser le produit lorsque aucune mesure d’atténuation n’est disponible.

La CISA demande également aux parties prenantes d’évaluer l’exposition de chaque actif à Internet et de veiller à ce que l’application des correctifs respecte la directive contraignante. Les systèmes TeamCity accessibles depuis Internet doivent faire l’objet d’une attention particulière, car CVE-2026-63077 ne nécessite aucune authentification.

L’incident Cadence illustre les conséquences opérationnelles de l’exposition prolongée d’un tel serveur. L’exécution initiale de code sur une plateforme de développement a donné aux attaquants accès à des secrets stockés qui pouvaient être utilisés contre l’infrastructure cloud et des services externes.

Les données de sauvegarde ont mené les attaquants aux identités AWS et aux fichiers S3

Cadence est un service hébergé par JetBrains qui se connecte à PyCharm via un plugin facultatif. Les développeurs peuvent l’utiliser pour exécuter des charges de travail de machine learning et d’autres tâches gourmandes en ressources sur des GPU cloud depuis l’IDE.

Après avoir compromis le serveur Cadence, les attaquants ont accédé à une sauvegarde complète du serveur datant de 2024. Cette sauvegarde pouvait contenir des identifiants, des secrets, des informations de configuration, des artefacts d’exécution ou de compilation, des journaux et d’autres données opérationnelles.

JetBrains a confirmé que plusieurs utilisateurs AWS IAM ainsi que les identifiants ou secrets qui leur étaient associés avaient été extraits de la sauvegarde. Les identités concernées comprenaient des comptes appartenant à des employés de JetBrains qui avaient utilisé Cadence.

Les attaquants ont également accédé à des fichiers stockés dans des buckets S3 de comptes AWS de JetBrains utilisés par le service. Les données potentiellement exposées peuvent être associées aux utilisateurs actuels de Cadence, notamment :

• Noms d’utilisateur, noms réels et adresses e-mail
• Horodatages de dernière connexion et adresses IP du dernier accès
• Code source des projets PyCharm
• Identifiants et données de configuration
• Entrées, sorties et artefacts d’exécution
• Autres fichiers téléversés ou synchronisés pour le traitement dans le cloud

Les développeurs ont pu transférer davantage de fichiers que ceux sélectionnés intentionnellement pour l’exécution. Les arborescences de code source contiennent souvent des fichiers d’environnement, des configurations de déploiement, des clés d’API, des métadonnées de dépôt ou des identifiants intégrés à des scripts et des notebooks.

JetBrains a indiqué que son enquête n’avait identifié aucun autre utilisateur concerné parmi les personnes qui n’avaient pas été contactées directement. L’entreprise considère néanmoins comme potentiellement exposées les données stockées dans les espaces de stockage concernés.

L’entreprise a également averti que chaque exécution Cadence, y compris ses entrées et ses sorties, doit être considérée comme non fiable. La réponse ne doit donc pas se limiter à la confidentialité : les organisations doivent vérifier que les artefacts produits dans l’environnement compromis n’ont pas été modifiés.

Les indicateurs pointent vers six adresses d’exploitation

JetBrains a associé six adresses IP à l’activité d’exploitation observée :

150.109.230.104
43.153.227.206
62.210.127.48
210.247.242.190
15.235.225.205
152.233.30.18

Les équipes de défense doivent rechercher ces adresses dans les journaux d’authentification, du cloud, des dépôts, des terminaux et du réseau. Les correspondances sont particulièrement significatives lorsqu’elles concernent des identifiants stockés dans Cadence ou des systèmes accessibles à l’aide de ces identifiants.

L’enquête ne doit pas se limiter à cette liste. Les attaquants peuvent modifier leur infrastructure, faire transiter leur trafic par d’autres hôtes ou utiliser des identifiants volés depuis des emplacements sans rapport.

Les équipes doivent examiner l’activité menée pendant et après la période d’intrusion afin de repérer les clonages ou téléchargements de dépôts inattendus, les commits inhabituels ou les modifications apportées aux secrets et aux webhooks. Les jetons d’accès personnel, jetons d’API, clés SSH, collaborateurs et comptes de service nouvellement créés, ainsi que les changements de privilèges, doivent également faire l’objet d’une enquête.

Les journaux cloud doivent être vérifiés afin de détecter les modifications apportées aux rôles IAM, aux politiques, aux relations de confiance et aux autorisations de stockage. Un accès inhabituel à des objets AWS S3 ou à un stockage Google Cloud équivalent peut indiquer que les identifiants exposés ont été utilisés au-delà de l’environnement JetBrains.

Les systèmes de la chaîne d’approvisionnement logicielle constituent une autre priorité. Les organisations doivent rechercher toute publication non autorisée de packages, toute version modifiée, toute altération d’images de conteneurs ou toute modification des flux de compilation et de déploiement.

Les attaquants n’ont pas été attribués à un groupe, une campagne ou un gouvernement identifiés. Leurs objectifs au-delà de l’obtention de données et d’identifiants restent inconnus.

La rotation des identifiants doit aller au-delà de Cadence

JetBrains a mis api.cadence.jetbrains.com hors ligne et invalidé tous les jetons d’accès utilisés par le plugin Cadence dans PyCharm. Ces mesures bloquent le chemin de connexion existant, mais elles n’invalident pas les identifiants copiés depuis des projets, des sauvegardes ou des environnements d’exécution.

Les utilisateurs et organisations concernés doivent :

1. Révoquer et renouveler chaque mot de passe, jeton, clé d’API, clé SSH, certificat et secret stocké dans Cadence ou exposé à une exécution Cadence.
2. Remplacer les identifiants associés aux utilisateurs AWS IAM et aux autres identités cloud utilisées par le service.
3. Identifier les systèmes en aval accessibles avec ces identifiants, notamment les dépôts, registres, environnements de déploiement, comptes cloud, bases de données et plateformes de packages.
4. Auditer les dépôts afin de détecter les accès non autorisés, commits, téléchargements, modifications de webhooks, nouveaux collaborateurs, changements de privilèges et nouveaux jetons.
5. Examiner les journaux d’audit cloud à la recherche de modifications IAM, de nouveaux comptes, d’assumptions de rôles inhabituelles, de changements de politiques et d’accès inattendus à S3.
6. Inspecter les systèmes de compilation, de gestion de packages, de conteneurs et de publication afin de détecter toute publication ou modification non autorisée.
7. Valider les sorties générées par Cadence avant de les réutiliser ou de les distribuer.
8. Rechercher dans les systèmes connectés tout mécanisme de persistance, nouveau compte de service, changement de relation de confiance ou réutilisation d’identifiants.

La rotation doit inclure les accès dépendants. Remplacer une clé AWS, par exemple, ne suffit pas si le même secret a été réutilisé dans un dépôt, une plateforme CI/CD, un fichier de configuration local ou un autre environnement cloud.

Les noms et adresses e-mail exposés présentent également un risque secondaire. Les attaquants pourraient exploiter leur connaissance des projets Cadence ou des workflows JetBrains pour élaborer des messages d’hameçonnage ciblés, usurper l’identité d’administrateurs ou demander aux développeurs concernés de communiquer de nouveaux identifiants.

Le point d’entrée initial dans TeamCity a été retiré du service. La tâche la plus difficile consiste désormais à déterminer à quels systèmes les identités extraites pouvaient donner accès et à vérifier si les attaquants les ont utilisées avant leur révocation.