JetBrains Cadence compromis via un TeamCity non corrigé, des secrets AWS dérobés

JetBrains a confirmé la compromission de Cadence, son service cloud permettant aux développeurs d'exécuter des charges lourdes et des entraînements de modèles sur des GPU distants depuis PyCharm. Les attaquants sont entrés par une faille TeamCity connue depuis juillet, et non corrigée sur le serveur concerné.

Le butin est de ceux qui font le plus de dégâts en cascade : des identifiants et des secrets AWS, du code source, et les jetons d'accès de clients ayant utilisé le service.

Une faille connue, corrigée ailleurs, oubliée là

Le point d'entrée est la CVE-2026-63077, une vulnérabilité de désérialisation de données non fiables dans TeamCity, notée 9,8 sur 10. Elle permet à un attaquant non authentifié d'exécuter des commandes système arbitraires avec les privilèges du serveur TeamCity.

La chronologie est le vrai sujet de cette affaire. La faille a été divulguée en juillet 2026. Le 5 août, la CISA américaine l'a ajoutée à son catalogue des vulnérabilités activement exploitées — un signal fort, qui impose aux agences fédérales américaines un délai contraint de correction et sert d'alerte au reste du secteur. L'intrusion, elle, s'est déroulée entre le 8 et le 24 août, et JetBrains ne l'a découverte que le 23 août.

Autrement dit : le correctif existait depuis plusieurs semaines et l'alerte publique était maximale quand le serveur a été compromis. Il ne s'agit pas d'une faille inconnue exploitée par surprise, mais d'un actif qui n'a pas été mis à jour — la cause la plus banale et la plus répandue des compromissions réussies.

Ce qui a été volé

• Des identifiants et secrets AWS IAM extraits d'une sauvegarde datant de 2024.

• Des adresses e-mail, noms d'utilisateurs et horodatages de dernière connexion.

• Du code source et des configurations stockés dans des buckets S3.

• Les identifiants et secrets utilisés par les clients au sein de Cadence.

Le détail de la sauvegarde de 2024 mérite d'être relevé. Des secrets vieux de deux ans n'ont de valeur pour un attaquant que s'ils sont toujours valides — ce qui est fréquemment le cas des clés IAM de longue durée, rarement soumises à une rotation systématique. Une sauvegarde ancienne devient alors un trousseau de clés parfaitement fonctionnel.

Ce que doivent faire les utilisateurs de Cadence

La consigne est sans ambiguïté : tout identifiant stocké dans Cadence doit être révoqué immédiatement, et toutes les exécutions passées doivent être traitées comme potentiellement compromises. JetBrains a de son côté invalidé l'ensemble des jetons d'accès et mis hors ligne le serveur touché, api.cadence.jetbrains.com.

La révocation est plus étendue qu'il n'y paraît. Un service qui exécute du code d'entraînement accède rarement à un seul secret : il détient souvent des clés de stockage objet, des jetons de dépôts de code, des accès à des bases de données et parfois des clés d'API de fournisseurs de modèles. Chacun doit être passé en revue, pas seulement ceux dont on se souvient.

Pourquoi les chaînes d'outils de développement sont une cible privilégiée

Compromettre un serveur d'intégration continue ou une plateforme de calcul offre un rendement sans commune mesure avec l'attaque d'un poste isolé. Ces systèmes sont conçus pour détenir des secrets : c'est leur fonction que de disposer des droits nécessaires pour construire, tester et déployer. Ils concentrent donc, par nature, ce qu'un attaquant cherche.

Cette affaire s'ajoute à une série d'incidents visant l'outillage des développeurs que nous avons documentés, notamment la compromission de l'infrastructure de registre de Coder et le piège tendu aux agents de codage via la configuration Git.

Source

The Hacker News — « Attackers Breached JetBrains Cadence via Unpatched TeamCity, Extracting AWS Credentials »