Correctif TeamCity CVE-2026-63077 : guide d’urgence 2026

Un serveur TeamCity vient d’être corrigé, mais un Mac Agent inconnu apparaît encore dans la console et les derniers artefacts ne peuvent plus être considérés comme fiables.

La solution la plus rapide consiste à limiter immédiatement l’accès externe, appliquer une version corrigée ou le correctif de sécurité officiel, puis traiter l’environnement comme potentiellement compromis jusqu’à la fin de l’enquête et de la validation sur un nœud Mac propre. Le bulletin de sécurité officiel concernant CVE-2026-63077 confirme que des serveurs non corrigés ont fait l’objet d’une exploitation active ou de tentatives d’exploitation ; TeamCity Cloud ne nécessite pas cette intervention côté client.

Décision immédiate : cette procédure convient à une équipe qui doit préserver la livraison tout en réduisant le risque. Elle ne convient pas à une reprise précipitée où un correctif installé, un Agent reconnecté ou un build réussi serait traité comme une preuve d’absence d’intrusion.

Cette page est destinée aux administrateurs TeamCity On-Premises, aux responsables de l’iOS CI/CD et aux équipes chargées des signatures Apple. Elle aide également les responsables sécurité et techniques à coordonner l’isolement, l’enquête, la reconstruction et la remise en production.

Dernière mise à jour : 6 septembre 2026. Les versions, mesures de mitigation et conditions de reprise ont été vérifiées à partir des bulletins et documents officiels TeamCity cités dans cet article.

00Dans les premières minutes, réduire l’exposition avant de réparer

L’objectif de la première phase n’est pas encore de restaurer les builds. Il est de réduire la capacité d’un éventuel attaquant à modifier la configuration, extraire des secrets ou déclencher une signature pendant que l’équipe rassemble les informations nécessaires.

La séquence recommandée est la suivante :

Restreindre l’accès public au serveur TeamCity au moyen du pare-feu, du répartiteur ou du contrôle d’accès réseau déjà approuvé par l’entreprise.
Geler les changements d’administration, les modifications de projets et les créations d’Agents non planifiées.
Suspendre les tâches de production qui utilisent une clé de signature, un trousseau de certificats ou des identifiants de déploiement.
Préserver les journaux du serveur, les événements d’administration, les traces de connexion, l’inventaire des Agents et les métadonnées des builds.
Nommer une personne responsable de la chronologie afin d’éviter que chaque équipe ne redémarre séparément son propre composant.

Cette restriction ne signifie pas nécessairement que le serveur doit être arrêté immédiatement. Un arrêt peut faire disparaître des éléments volatils ou empêcher une collecte contrôlée. La décision dépend de la capacité de l’équipe à conserver les journaux et à empêcher les accès non autorisés.

Le correctif TeamCity CVE-2026-63077 doit-il être appliqué à tous les environnements ?
Oui pour TeamCity On-Premises exposé ou susceptible d’avoir été exposé, mais la méthode dépend de la version installée, de la fenêtre d’arrêt, de la base de données, des extensions et de la licence. TeamCity Cloud est traité par son opérateur et ne demande pas au client d’exécuter cette correction, selon le bulletin officiel sur l’exposition et les mesures de sécurité.

Élément à traiter	Action immédiate	Décision à ne pas prendre trop tôt
Serveur TeamCity On-Premises	Limiter les accès externes et geler les changements sensibles	Le déclarer sain parce que l’interface redémarre
Mac Agent de production	Retirer temporairement le routage des tâches sensibles	Le réautoriser dès qu’il se reconnecte
Nœud de signature	Suspendre les publications et conserver les preuves	Réutiliser automatiquement le trousseau existant
Artefacts récents	Marquer les livrables concernés pour vérification	Les republier sans contrôler leur provenance
TeamCity Cloud	Vérifier la communication officielle du fournisseur	Appliquer une procédure serveur locale

01Avant la fenêtre de maintenance, choisir une correction traçable

La version ciblée doit être choisie à partir de la version actuellement installée, et non à partir de la dernière version simplement disponible. Le bulletin officiel indique que les versions 2025.11.7 et 2026.1.3 contiennent la correction ; lorsqu’une mise à niveau immédiate n’est pas possible, le plugin de correctif de sécurité officiel constitue une mesure temporaire documentée par la même source sur CVE-2026-63077.

La bonne décision suit quatre questions :

la version actuelle appartient-elle à une branche directement corrigeable ?
l’équipe peut-elle arrêter le serveur et vérifier la restauration de la base ?
les plugins utilisés supportent-ils la branche visée ?
l’organisation accepte-t-elle une mesure temporaire, avec une date de remplacement clairement enregistrée ?

TeamCity 2026.2 a été publié le 1er septembre 2026, mais cette disponibilité ne signifie pas qu’un saut direct est approprié. Les notes de version doivent être confrontées à la version existante, aux plugins et à la stratégie de migration dans les notes officielles de TeamCity 2026.2.

Que faut-il sauvegarder avant l’installation ?
Il faut préserver la base de données, le Data Directory, la configuration du serveur, les paramètres des projets, les définitions de build et les journaux nécessaires à l’enquête. Il faut aussi inventorier les éléments stockés hors de la sauvegarde ordinaire : secrets injectés par un coffre externe, artefacts conservés dans un dépôt séparé, trousseaux de signature sur les Mac, certificats, scripts d’administration et règles réseau. Une sauvegarde réussie ne garantit donc pas que la chaîne complète pourra être reconstruite.

La préparation peut être consignée dans cette liste :

[ ] Relever la version exacte du serveur et le mode d’installation.
[ ] Exporter l’inventaire des plugins et leur version.
[ ] Identifier le moteur de base de données, le pilote et la méthode de restauration.
[ ] Documenter la version de Java utilisée par le serveur.
[ ] Recenser chaque Mac Agent, son propriétaire, son rôle et son emplacement réseau.
[ ] Séparer les Agents de compilation ordinaires des nœuds de signature.
[ ] Conserver les journaux avant toute rotation automatique.
[ ] Vérifier que la sauvegarde peut être restaurée dans un environnement isolé.
[ ] Préparer un compte d’urgence dont les droits et l’usage sont journalisés.
[ ] Définir le responsable du retour arrière et le critère d’abandon.

Un passage vers les versions récentes peut exiger Java 21, un pilote de base de données compatible ou une vérification particulière des extensions. La page officielle consacrée à Java 21 dans TeamCity doit être lue avec les notes de mise à niveau, et non remplacée par une simple installation locale de Java.

02Pendant la maintenance, réparer puis prouver le blocage

La fenêtre de maintenance doit rester centrée sur le serveur. Il est préférable de ne pas mélanger simultanément la mise à niveau du serveur, la réinstallation de tous les Mac Agent et la rotation de tous les secrets : si une étape échoue, l’équipe ne saura plus quelle modification a produit le résultat observé.

L’ordre opérationnel peut être limité à cette chaîne :

Annoncer le gel des tâches et enregistrer l’heure de début.
Arrêter proprement le serveur selon la méthode d’installation utilisée.
Confirmer l’existence et la lisibilité des sauvegardes prévues.
Installer la version corrigée ou appliquer le plugin de sécurité officiel selon la décision documentée.
Redémarrer le serveur et contrôler l’état de la base, de la console d’administration et des services essentiels.
Vérifier la version effectivement exécutée, et non seulement le fichier téléchargé.
Confirmer que la mesure de sécurité attendue est active.
Tester une connexion VCS sans lancer de signature ni de déploiement.
Contrôler la file d’attente, les projets critiques et les erreurs récentes.
Conserver les journaux de la mise à niveau pour l’enquête et le retour arrière.

Comment vérifier le blocage après l’installation du correctif TeamCity CVE-2026-63077 ?
La vérification doit associer la version active, l’état du correctif, les accès administratifs, les connexions VCS et l’absence de changement non expliqué. L’ouverture de l’interface et la réussite d’un build banal ne suffisent pas. Si le serveur se trouve dans un réseau sans accès sortant, l’équipe doit confirmer que le téléchargement ou la validation du correctif n’a pas échoué silencieusement ; cette contrainte doit être relevée dans le compte rendu.

Contrôle après redémarrage	Preuve attendue	Échec à traiter comme un blocage
Version du serveur	Version affichée et enregistrée dans le procès-verbal	Version différente du paquet prévu
Correctif de sécurité	État actif ou installation confirmée	Téléchargement partiel ou statut ambigu
Administration	Comptes, droits et changements récents comparés	Compte privilégié inconnu
VCS	Connexion de lecture contrôlée	Jeton refusé ou modification inattendue
Agents	Liste et états comparés à l’inventaire	Agent inconnu ou identité incohérente
File d’attente	Tâches non sensibles visibles et maîtrisées	Tâche de signature relancée automatiquement

03Après le serveur, remettre chaque Mac Agent sous contrôle

Un Mac Agent ne doit pas être restauré en bloc avec le serveur. Il faut d’abord désactiver son routage vers les tâches de production, puis vérifier son identité, son autorisation et son URL de serveur. Les contrôles d’état et d’autorisation peuvent être confrontés à la documentation officielle de l’API des Agents TeamCity.

Pour chaque nœud, l’équipe vérifie :

le nom de l’Agent et l’hôte physique ou virtuel auquel il correspond ;
l’identité du Mac et son propriétaire opérationnel ;
l’URL serverUrl configurée ;
l’état d’autorisation dans TeamCity ;
la date et le résultat de la mise à niveau automatique de l’Agent ;
les extensions, outils Xcode, dépendances et scripts réellement présents ;
la présence éventuelle d’un compte local, d’un lancement automatique ou d’un accès distant non documenté.

La mise à niveau automatique de l’Agent ne doit pas être accompagnée d’un redémarrage forcé pendant son déroulement. Les conditions de connexion et de lancement sur macOS sont détaillées dans la documentation officielle de démarrage d’un Agent macOS.

Comment décider qu’un Mac Build Agent peut revenir en production ?
Un Agent peut revenir seulement après sa désactivation initiale, la vérification de son identité et une validation fonctionnelle sur une tâche sans signature. Le test doit récupérer le code, sélectionner l’environnement Xcode attendu, installer ou restaurer les dépendances, compiler, exécuter les contrôles prévus et nettoyer l’espace de travail. Une reconnexion réussie ne prouve ni l’intégrité du système ni celle du trousseau.

Le premier test doit être sans signature et sans publication. Pour les équipes audio, vidéo ou design, il peut inclure l’ouverture contrôlée d’un projet nécessitant les outils macOS réellement utilisés en production, à condition de ne pas exposer les certificats de distribution. Cela évite de valider uniquement un environnement minimal qui ne représente pas les projets réels.

Un Agent inconnu, récemment ajouté ou impossible à rattacher à un hôte documenté reste non autorisé. Il doit être séparé des nœuds connus et examiné avec ses journaux, son identité système et ses connexions ; un événement isolé est une piste d’enquête, pas une preuve autonome d’exploitation.

Pour une équipe sans machine de secours, un environnement Mac temporaire peut servir à reconstruire un Agent propre, rejouer une chaîne critique et conserver l’ancien nœud pour analyse. NUKCLOUD présente ses solutions d’accès à des Mac distants comme une option à évaluer dans cette phase, après validation des exigences de réseau, de confidentialité et de conservation des données.

04Le premier jour, enquêter et faire tourner les identifiants

Le serveur corrigé et l’Agent reconnecté ne suffisent pas à clore l’incident. L’équipe doit établir une table d’enquête qui relie l’heure, l’acteur, le projet, l’Agent, l’action et la preuve disponible.

Les signaux à rapprocher comprennent notamment :

une connexion administrative inhabituelle ;
une modification de projet ou de configuration non planifiée ;
un Agent inconnu ou réautorisé sans responsable identifié ;
un changement d’URL, de règle d’accès ou de paramètre d’exécution ;
un build lancé hors du calendrier prévu ;
une divergence entre l’artefact publié et le commit attendu.

Comment savoir si le serveur TeamCity a été exploité ?
Il n’existe pas de conclusion fiable fondée sur une seule anomalie de journal. L’équipe doit comparer les événements avec les changements approuvés, les accès réseau, les journaux VCS, les états d’Agents et la provenance des artefacts. Le bulletin officiel fournit des pistes d’investigation, mais une absence de trace dans un fichier ne démontre pas l’absence d’activité si la conservation était incomplète.

La rotation doit être ordonnée par périmètre :

identifiants VCS et jetons de lecture ou d’écriture ;
accès aux dépôts d’artefacts ;
comptes et clés de déploiement ;
identifiants cloud utilisés par les tâches ;
certificats et profils associés à la distribution iOS ;
trousseaux et clés de signature présents sur les nœuds Mac.

Chaque secret doit être révoqué ou remplacé par son propriétaire légitime, puis retiré des variables, scripts, caches et espaces de travail où il n’a plus lieu d’être. Les équipes doivent également contrôler les artefacts construits pendant la période d’exposition : commit source, horodatage, Agent utilisé, dépendances, signature et destination. Un paquet techniquement valide peut néanmoins être écarté si sa provenance ne peut pas être établie.

05Reprendre la production avec une chaîne propre et des seuils écrits

La restauration finale doit commencer sur un Mac isolé, avec le minimum de composants nécessaires. L’équipe reconstruit ensuite les étapes dans l’ordre où un consommateur les vérifie réellement :

récupération du code depuis le dépôt attendu ;
résolution des dépendances ;
compilation ;
tests ;
archivage ;
signature contrôlée ;
publication vers une destination approuvée.

La signature et la publication restent désactivées tant que les étapes précédentes n’ont pas produit les résultats attendus. Le résultat du nœud propre doit être comparé à celui de l’ancien nœud : différences de version Xcode, de dépendance, de script, de variable, de certificat ou d’artefact doivent être expliquées avant toute remise en ligne.

La décision concernant l’ancien Mac Agent peut prendre trois formes :

réinstallation, si l’équipe ne peut plus garantir l’intégrité du système ;
maintien en quarantaine, si les éléments sont nécessaires à l’analyse ;
retrait, si l’identité ou la provenance du nœud ne peuvent pas être établies.

Avant le retour au trafic normal, le responsable de production doit pouvoir cocher les cinq conditions suivantes :

[ ] Le serveur TeamCity utilise une version corrigée ou la mesure officielle temporaire est documentée.
[ ] Les comptes, Agents et changements sensibles ont été comparés aux traces disponibles.
[ ] Les secrets concernés ont été renouvelés par leurs propriétaires.
[ ] Les artefacts produits pendant la fenêtre d’exposition ont une provenance acceptable.
[ ] Un Mac Agent propre a réussi la chaîne réelle jusqu’au point de publication contrôlée.
[ ] L’ancien nœud dispose d’une décision écrite : réinstaller, conserver pour enquête ou retirer.
[ ] Le retour arrière et le responsable d’astreinte sont connus de l’équipe.
[ ] La remise en production est progressive, avec arrêt immédiat prévu en cas de divergence.

Pour préparer cette étape, l’équipe peut consulter l’aide NUKCLOUD consacrée à l’accès et à l’exploitation des Mac distants, puis vérifier que le cadre retenu respecte ses exigences de données, d’accès administrateur et de réseau privé.

Pour une organisation qui ne possède qu’un seul Mac de signature, la difficulté n’est pas uniquement le correctif TeamCity CVE-2026-63077 : c’est l’absence de zone de reconstruction indépendante. Acheter immédiatement une machine supplémentaire apporte un contrôle physique, mais impose l’approvisionnement, le durcissement, la maintenance, le remplacement des composants et la gestion d’un actif qui restera parfois inutilisé. Une architecture temporaire ou complémentaire avec un Mac distant peut être plus adaptée à une enquête, à un test de reprise ou à une capacité de secours, à condition de valider la confidentialité des dépôts, la conservation des clés et la connectivité requise. Une commande de Mac distant NUKCLOUD peut alors être étudiée comme ressource de reconstruction, et non comme substitut automatique à un nœud de signature permanent.

La décision dépend donc de la durée prévue, du niveau de contrôle physique exigé, du besoin de ports ou de périphériques locaux et du caractère sensible des clés. Pour une charge permanente et strictement réglementée, l’achat d’un Mac dédié peut rester préférable. Pour une capacité de secours, un test isolé ou une reprise urgente, la location évite de laisser une machine de réserve non préparée au moment où l’incident survient. Dans les deux cas, le critère de retour doit rester le même : serveur corrigé, identifiants renouvelés, Agent identifié, artefacts traçables et chaîne réelle validée avant la signature.