Le 3 septembre 2026, JetBrains a conclu son enquête sur un incident de sécurité affectant Cadence, son service hébergé qui permet d’exécuter des projets sur des ressources cloud depuis PyCharm. L’exploitation a été identifiée entre le 8 et le 24 août, sur api.cadence.jetbrains.com, après l’exploitation d’une faille critique de TeamCity. Le serveur a été mis hors ligne le 24 août.
Le point important pour les équipes de développement n’est pas seulement la fuite de données personnelles. JetBrains indique qu’une sauvegarde Cadence de 2024, des identifiants AWS et des fichiers synchronisés depuis des projets PyCharm doivent être traités comme potentiellement exposés. Cela transforme un incident de service cloud en problème de secrets, de dépôts et de chaîne de déploiement.
Ce que JetBrains a confirmé
Cadence est un service JetBrains optionnel intégré à PyCharm. Selon la mise à jour officielle, des acteurs non autorisés ont exploité CVE-2026-63077 sur un environnement TeamCity vulnérable, puis ont accédé à des données liées au service Cadence. JetBrains a invalidé les jetons utilisés par le plugin PyCharm et a contacté directement le groupe d’utilisateurs concerné.
Les données personnelles confirmées comprennent des noms d’utilisateur, noms réels, adresses e-mail, dates de dernière connexion et dernières adresses IP utilisées. JetBrains précise aussi que l’accès à une zone de stockage contenant des données d’utilisateurs actuels pouvait inclure du code source et des identifiants. Cette formulation décrit une exposition potentielle : elle ne prouve pas que chaque projet ou chaque secret a été extrait.
Pourquoi une sauvegarde ancienne reste critique
La sauvegarde complète du serveur Cadence datant de 2024 est un élément central du dossier. JetBrains indique qu’elle pouvait contenir des identifiants, de la configuration, des artefacts et des journaux, et que plusieurs utilisateurs IAM AWS ainsi que leurs secrets associés ont été compromis dans cette sauvegarde.
Une sauvegarde n’est donc pas un simple fichier historique. Elle peut conserver des accès qui ont été oubliés, rarement utilisés ou jamais remplacés après une migration. Si un ancien secret est encore accepté par un dépôt, un bucket ou un registre, l’âge de la sauvegarde ne réduit pas automatiquement le risque.
Le périmètre possible côté projets et intégrations
Les utilisateurs qui ont synchronisé des fichiers PyCharm vers Cadence doivent considérer leur code, leurs fichiers de configuration et les secrets accessibles aux exécutions comme potentiellement compromis. Le scénario ne signifie pas que tous les projets PyCharm sont touchés, mais il impose de rechercher les secrets qui auraient pu être présents dans les variables d’environnement, fichiers de configuration, scripts ou sorties d’exécution.
Le périmètre ne s’arrête pas au dépôt Git. JetBrains cite les comptes AWS, buckets S3, environnements de déploiement, registres de paquets et conteneurs, jetons Slack, webhooks, clés SSH, certificats et comptes de service. Une cartographie utile suit donc chaque secret jusqu’au service qu’il pouvait atteindre.
Ce que les utilisateurs de Cadence doivent faire
Commencez par révoquer et renouveler tous les secrets utilisés par les exécutions Cadence, sans attendre d’avoir identifié une activité anormale. La liste doit inclure les accès cloud, les jetons GitHub ou GitLab, les clés de déploiement, les identifiants de registre et les secrets transmis à un script.
Ensuite, vérifiez les dépôts et les services accessibles pendant la période du 8 au 24 août : clones ou téléchargements inattendus, commits inconnus, changements de collaborateurs, webhooks, permissions, jetons personnels et rôles IAM. Les exécutions, leurs entrées et leurs sorties doivent rester considérées comme non fiables tant que cette revue n’est pas terminée.
Ce que les TPE-PME peuvent en retenir
Une équipe n’a pas besoin d’utiliser Cadence pour rencontrer le même problème. Tout outil cloud qui exécute du code, synchronise un dépôt ou reçoit des variables d’environnement devient un point de concentration des secrets. Le contrôle doit porter sur les accès réellement transmis à l’outil, leur durée de vie et la capacité à les révoquer rapidement.
Pour une petite équipe, trois mesures sont immédiatement utiles : attribuer un secret unique à chaque service, limiter les permissions à l’action nécessaire et tenir un inventaire des dépendances qui consomment ces secrets. Un compte partagé ou un fichier de configuration copié dans plusieurs outils rend la rotation plus lente et le périmètre plus incertain.
Le lien avec Soclyde
Soclyde ne protège pas JetBrains Cadence et ne peut pas déterminer quels secrets ont été consultés dans cet incident. Son utilité se situe dans l’organisation qui suit : générer une valeur différente pour chaque service, conserver les secrets dans un coffre chiffré local-first et retrouver rapidement les accès à renouveler.
Cette approche ne remplace ni les journaux cloud ni la revue des dépôts. Elle réduit toutefois la réutilisation et les copies dispersées qui compliquent une réponse lorsqu’un outil de développement ou un prestataire est compromis. Découvrez le guide pour créer des mots de passe forts et uniques ou contactez Soclyde.
À retenir
L’incident Cadence montre qu’une faille d’infrastructure peut atteindre bien plus qu’un compte applicatif : sauvegardes, code synchronisé, accès AWS et secrets transmis aux exécutions peuvent élargir le périmètre. Les affirmations publiques de JetBrains ne prouvent pas que tous ces éléments ont été extraits, mais elles justifient une rotation préventive et une revue ciblée.
Pour une TPE-PME, la priorité est simple : inventorier les secrets accessibles à chaque outil, supprimer les copies inutiles, renouveler les accès après chaque incident et vérifier les traces laissées dans les dépôts, clouds et registres.
