Un 9.8 dans le serveur qui compile votre logiciel

CVE-2026-63077 est une vulnérabilité de désérialisation de données non fiables, la catégorie que la CISA classe sous CWE-502, dans JetBrains TeamCity On-Premises, le serveur d'intégration et de livraison continues que des milliers d'équipes de développement européennes et britanniques utilisent pour compiler, tester et publier leur propre code. Elle affiche un score CVSS de 9.8, le niveau quasi maximal réservé aux failles qui ne nécessitent ni identifiants ni interaction utilisateur et qui livrent tout à l'attaquant d'un seul coup.

La faille se situe dans le protocole de sondage des agents de TeamCity, le canal que les agents de build utilisent pour se signaler au serveur. Un attaquant capable d'atteindre ce canal via HTTP ou HTTPS, sans aucune connexion requise, peut envoyer une charge utile forgée que TeamCity désérialise et exécute comme une commande système, avec exactement les privilèges que détient le processus serveur TeamCity lui-même. Toutes les versions sur site publiées sont concernées ; TeamCity Cloud, hébergé par JetBrains, était déjà corrigé et ne nécessite aucune action de la part des clients.

Neuf jours entre la divulgation et l'exploitation confirmée

JetBrains a publié son propre avis le 27 juillet 2026, reconnaissant la découverte et publiant des versions corrigées, TeamCity 2025.11.7 et 2026.1.3, ainsi qu'un plugin de correctif de sécurité couvrant les versions à partir de 2017.1 pour les équipes qui ne peuvent pas mettre à jour immédiatement. À l'époque, JetBrains a indiqué n'avoir connaissance d'aucune exploitation active.

Le 5 août 2026, l'agence américaine CISA (Cybersecurity and Infrastructure Security Agency) a ajouté CVE-2026-63077 à son catalogue des vulnérabilités exploitées connues, la liste que la CISA réserve aux failles dont elle a confirmé l'exploitation dans des attaques réelles, pas simplement théoriques. En vertu de la Binding Operational Directive 26-04, les agences civiles fédérales américaines avaient jusqu'au 8 août 2026, samedi dernier, pour corriger ou déconnecter les systèmes exposés. L'ajout est arrivé la même semaine où la CISA a confirmé une autre vague distincte d'exploitation active visant IBM Langflow, N-able N-central et Apache Tomcat, ajoutée au catalogue la veille, le 4 août, dans un bulletin séparé ; des vulnérabilités différentes, des éditeurs différents, le même message sur le peu de répit dont dispose un logiciel d'infrastructure exposé à internet une fois qu'une faille devient publique.

Une brèche CI/CD est une brèche de chaîne d'approvisionnement

Une compromission classique de serveur web coûte à une organisation ce qui se trouve sur ce seul serveur. TeamCity détient plus que cela : les clés des fournisseurs cloud et les jetons de registre de conteneurs que les agents de build utilisent pour déployer, les identifiants de dépôts de paquets qui permettent à un pipeline de publier sous le nom vérifié d'une organisation, et souvent les clés de signature de code qui font paraître le logiciel publié authentiquement sien aux yeux de chaque client qui l'installe. L'exécution de code à distance avec les privilèges du serveur, sur l'orchestrateur au centre de cette chaîne de confiance, atteint tous ces identifiants d'un seul coup.

Un attaquant qui parvient jusque-là peut faire plus que copier une base de données : il peut s'insérer dans une future compilation jusqu'à ce que quelqu'un le remarque, le même mécanisme derrière les compromissions de chaîne d'approvisionnement qui ont déjà touché des éditeurs de logiciels bien plus grands que l'entreprise de développement européenne ou britannique type. L'exposition dépasse le serveur TeamCity lui-même, jusqu'à chaque client et chaque système en aval qui fait confiance à ce que ce serveur produit.

L'échéance n'est pas la vôtre ; l'exploitation, elle, l'est déjà

La Binding Operational Directive 26-04 lie légalement uniquement les agences civiles fédérales américaines, et une entreprise de développement à Paris, Amsterdam ou Manchester qui exploite TeamCity sur site ne doit aucun rapport de conformité à la CISA. Y voir une autorisation de corriger selon le calendrier habituel revient à confondre un artefact de conformité avec une prévision de menace.

Le fait qui compte le plus est l'inscription au catalogue KEV elle-même. La CISA n'ajoute une CVE à ce catalogue qu'une fois qu'elle a confirmé que de vrais attaquants l'utilisent contre de vrais serveurs exposés à internet, et une instance TeamCity exposée à internet dans l'UE ou au Royaume-Uni est exactement aussi accessible à cet attaquant qu'une instance en Virginie. La directive NIS2 et les propres recommandations britanniques pour les entités essentielles et importantes attendent déjà des organisations qu'elles traitent une exploitation active confirmée comme une urgence opérationnelle, quel que soit le gouvernement qui a fixé l'échéance. L'échéance fédérale a expiré samedi ; l'exposition pour laquelle elle avait été écrite, elle, reste ouverte.

Ce qu'il faut vérifier cette semaine

Si TeamCity On-Premises tourne dans votre environnement, le correctif tient en un numéro de version : mettre à jour vers 2025.11.7 ou 2026.1.3. Lorsqu'une mise à jour immédiate n'est pas possible, le plugin de correctif de sécurité de JetBrains couvre les versions à partir de 2017.1 et ferme la faille sans saut de version complet. Tant que l'une de ces deux mesures n'est pas appliquée, il convient de retirer le serveur de l'internet ouvert, de restreindre l'accès à un VPN ou à un autre réseau de confiance, et de vérifier que le processus TeamCity tourne avec les privilèges système minimaux dont il a besoin, et non avec un compte administrateur.

Corriger ferme la porte pour l'avenir. Ce qui a déjà pu passer avant l'application du correctif mérite une attention distincte : chaque identifiant que le serveur TeamCity pouvait atteindre, clés API cloud, jetons de registre, clés de signature, clés SSH de déploiement, mérite d'être fait tourner, que l'intrusion ait été confirmée ou non, car une RCE par désérialisation s'exécutant avec les privilèges du processus serveur ne laisse pas de journaux de manière fiable, proportionnellement à ce qu'elle a pu atteindre. Avant la publication de la prochaine version, il vaut la peine de vérifier les artefacts de compilation récents par rapport à des empreintes connues et saines datant d'avant la fenêtre d'exposition.