CVE-2026-63077 : RCE non authentifiée sur chaque serveur TeamCity On-Premises

JetBrains TeamCity On-Premises embarque une faille critique d'exécution de code à distance sous CVE-2026-63077. Le bug se situe dans le protocole de polling des agents : un attaquant non authentifié envoie des données forgées que le serveur désérialise, produisant une exécution de code avec les privilèges du serveur TeamCity. Le score est CVSS 9,8 ; le rayon d'impact est tout ce que votre système de build touche — dépôts source, clés de déploiement cloud, matériel de signature et artefacts que ces pipelines produisent.

JetBrains a publié l'avis le 27 juillet 2026 en indiquant ne pas disposer de preuve d'exploitation à la divulgation. La donne a changé rapidement. La CISA a ajouté CVE-2026-63077 au catalogue Known Exploited Vulnerabilities le 5 août, fixant une échéance fédérale de remédiation au 8 août — trois jours. Les releases corrigées sont TeamCity 2025.11.7 et 2026.1.3. Les versions supportées plus anciennes peuvent appliquer le plugin de correctif de sécurité JetBrains jusqu'à 2017.1. TeamCity Cloud n'est pas concerné.

L'écart entre « pas d'exploitation connue » à la divulgation et l'inscription KEV huit jours plus tard est le signal. La couverture des scanners et la recherche de proof of concept rattrapent vite les bugs de désérialisation sur des produits CI/CD largement déployés. Si votre serveur TeamCity possède un enregistrement DNS ou accepte des connexions d'agents depuis autre chose qu'un réseau de build strictement contrôlé, supposez qu'il figure sur une liste cible, quel que soit le texte initial de l'avis.

Comment le polling des agents devient une RCE

Les agents TeamCity interrogent le serveur pour recevoir des commandes. Ce canal est conçu pour du trafic machine-à-machine à haute fréquence — exactement le type de chemin qui reçoit parfois moins de contrôle d'authentification que l'interface web où les administrateurs se connectent chaque jour.

CVE-2026-63077 est une faille de désérialisation de données non fiables dans ce traitement de protocole. L'attaquant n'a pas besoin de compte utilisateur sur TeamCity. Il a besoin d'une reachabilité réseau vers le serveur et de la capacité à envoyer des charges de polling malformées que le serveur analysera.

L'exploitation réussie passe typiquement par :

• La livraison d'un message de polling forgé qui déclenche une désérialisation dangereuse sur le serveur.
• L'exécution de code dans le contexte du processus serveur TeamCity, qui accède à la base de données applicative, au magasin de configuration et au coffre d'identifiants.
• La collecte d'identifiants et la modification de pipelines comme objectifs de suivi plutôt que comme vulnérabilités séparées.

Comme le point d'entrée est non authentifié, les évaluations d'exposition qui n'ont revu que qui peut se connecter à l'interface web ratent entièrement le chemin d'attaque.

Pourquoi une compromission CI/CD est un événement supply-chain

Un serveur TeamCity n'est pas « une application interne de plus ». Il détient les clés qui permettent à l'automatisation d'atteindre la production.

Après une RCE au niveau serveur, les attaquants poursuivent routinièrement :

• Les identifiants stockés pour l'hébergement Git, les dépôts d'artefacts, les registres de conteneurs et les API cloud — souvent largement scoped car les jobs de build en ont besoin.
• Les modifications de configuration de build qui ajoutent une étape malveillante à un pipeline existant, effet similaire à des workflows GitHub Actions compromis mais centré sur une infrastructure auto-hébergée que de nombreuses équipes sécurité inventorient mal.
• La falsification d'artefacts — remplacer un paquet ou une image conteneur construite avant qu'elle n'atteigne des consommateurs aval qui font confiance à la signature de sortie du système CI.
• La persistance via déclencheurs de build et hooks d'agents qui survivent à un simple redémarrage serveur jusqu'à ce que quelqu'un compare les définitions de pipeline à une référence saine.

Le parallèle avec les thèmes supply-chain GitHub Actions est volontaire. Les fournisseurs CI hébergés publient des guides de durcissement parce que les secrets de pipeline sont des cibles de valeur. TeamCity auto-hébergé derrière un pare-feu d'entreprise a reçu le même modèle de confiance sans toujours recevoir les mêmes contrôles réseau — et CVE-2026-63077 retire le confort de « il leur faut d'abord des identifiants ».

Chemins de correctif et plugin de sécurité

JetBrains propose deux voies de remédiation :

• Monter en 2025.11.7 ou 2026.1.3 sur les lignes principales supportées — le correctif préféré pour les équipes capables de bouger vite sur les trains de release.
• Appliquer le plugin de correctif de sécurité sur les installations 2017.1+ plus anciennes qui ne peuvent pas sauter de version immédiatement.

Le plugin est un pont pour des fenêtres de maintenance mesurées en semaines, non une excuse de reporter indéfiniment. Les failles de désérialisation sur protocoles de polling attirent la recherche d'exploit public une fois l'inscription KEV confirmée. Les équipes sur branches 2019.x ou 2022.x doivent planifier la montée mainline en parallèle du plugin plutôt que de traiter le plugin comme un état permanent.

Documentez quels agents se connectent depuis quels sous-réseaux avant de corriger. Une montée précipitée qui coupe la connectivité agent ressemble à une panne ; une montée précipitée sans conservation des journaux perd les preuves nécessaires si l'exploitation précède le correctif.

KEV CISA et l'horloge fédérale de trois jours

L'inclusion KEV le 5 août avec remédiation due le 8 août indique aux agences fédérales — et à quiconque lit le catalogue — que la CISA attend une exploitation active ou imminente même si JetBrains n'en avait aucune preuve à la divulgation.

Le secteur privé doit interpréter le calendrier ainsi :

• Corriger ou isoler les serveurs TeamCity exposés avant la fin de la semaine où l'entrée KEV est parue, non au prochain cycle de maintenance trimestriel.
• Supposer que le scan a commencé dès que l'identifiant CVE a circulé dans les flux éditeur et listes de diffusion sécurité, même avant un PoC public.
• Traiter les ports de polling des agents avec la même discipline pare-feu que l'interface web et l'API REST.

Suivez le CVE dans CVE Watch avec l'évolution EPSS pour que la repriorisation intervienne quand le score bouge, non quand un incident l'impose.

Signaux de détection et de recherche

Partez des journaux et données réseau déjà collectés :

• Erreurs de désérialisation ou d'analyse dans les journaux serveur TeamCity sur le point de terminaison de polling des agents, surtout si regroupées autour d'une même adresse source.
• Nouvelles inscriptions d'agents ou UUID d'agents qui ne correspondent à aucun hôte de build connu.
• Exécution de processus inattendue sur l'hôte serveur TeamCity hors maintenance planifiée — des processus fils Java lançant des shells ne sont jamais normaux sur un coordinateur de build.
• Connexions sortantes du serveur vers des sites de paste, réseaux VPS ou hébergement proche du Tor — la préparation post-exploitation sort souvent directement de l'hôte compromis avant le mouvement latéral.
• Modifications de définitions de pipeline horodatées dans la même fenêtre que les anomalies de polling, y compris nouvelles étapes script, dépendances modifiées ou cibles de déploiement ajoutées.

Si TeamCity se trouve dans un VLAN développeur à routage plat, cherchez aussi en aval. Les serveurs de build sont des points de pivot. Un attaquant qui obtient une RCE serveur utilise souvent les clés cloud stockées en quelques minutes.

Contrôles réseau et enrichissement

Posture minimale pendant le correctif :

• Restreindre le polling des agents et l'accès à l'interface web aux seuls sous-réseaux de build. Si les développeurs ont besoin de l'interface depuis des portables, placez-la derrière VPN ou accès zero trust plutôt qu'un nom DNS public « temporairement » laissé depuis une preuve de concept.
• Segmenter TeamCity de la production même si les pipelines y déploient — le serveur doit initier les connexions de déploiement sortantes ; les charges production ne doivent pas initier de sessions de gestion entrantes vers la couche build.
• Revoir les identifiants stockés et renouveler tout secret que le coffre TeamCity pourrait exposer après un contact suspect avec du trafic de polling malveillant.

Lorsque la recherche produit des adresses IP sources inconnues, enrichissez avant de clore le ticket :

• Recherches de réputation IP pour les adresses frappant les points de polling depuis l'extérieur de votre réseau de build.
• Recherches en masse lors de la revue de semaines de journaux — les sondes de désérialisation arrivent souvent en courtes rafales depuis de nombreux hôtes.
• Alimentez l'enrichissement dans votre SIEM via l'API pour que la prochaine alerte TeamCity inclue automatiquement le contexte d'hébergement et les associations malveillantes antérieures.

Pour les domaines vus dans des étapes de pipeline modifiées ou URLs de callback, utilisez le renseignement domaine et l'historique DNS.

Réponse à incident lorsqu'une exploitation est suspectée

Si l'enrichissement relie le trafic de polling à une infrastructure d'exploit connue ou si des diffs de pipeline montrent des changements non autorisés, menez une réponse à incident comme un dossier supply-chain :

• Conservez la base de données et les journaux serveur TeamCity avant expiration de la rétention.
• Comparez toutes les configurations de build et scripts de déploiement à la dernière référence saine du contrôle de source, non depuis la seule interface TeamCity — un attaquant avec accès serveur peut masquer des changements dans la vue UI utilisée pour enquêter.
• Renouvelez chaque identifiant du coffre TeamCity et tout secret qu'un pipeline compromis pourrait joindre en aval.
• Examinez les artefacts construits durant la fenêtre d'exposition pour des signes de falsification avant redéploiement.

Branchez le suivi de gestion des vulnérabilités pour que CVE-2026-63077 reste lié aux hôtes TeamCity concernés jusqu'à ce que chacun rapporte une version corrigée — une clôture KEV dans un tableur n'est pas une clôture sur le serveur.

Les clients TeamCity Cloud peuvent se décharger du correctif serveur. Tous les autres doivent traiter CVE-2026-63077 comme une faille de classe périphérie sur une infrastructure qui signe le logiciel que l'organisation exécute réellement. Corrigez, restreignez, chassez la sortie, enrichissez les hits — l'échéance fédérale de trois jours rappelle utilement que les serveurs CI/CD ne sont plus « internes seulement » dans le modèle de menace de personne.