Vos pipelines CI/CD savent tout de votre code, de vos secrets, de vos clés de déploiement. Pendant des années, ils étaient l'angle mort parfait : trop techniques pour les équipes sécurité, trop abstraits pour les RSSI. Les APT ont compris depuis longtemps que compromettre un serveur de build vaut mille fois mieux que de forcer une porte d'entrée. CVE-2026-63077 sur TeamCity, divulguée le 28 juillet 2026, est la troisième RCE critique CVSS 9.8 en trois ans sur ce seul produit. Il est temps de prendre ce sujet au sérieux.

La leçon SolarWinds n'a pas été retenue

En décembre 2020, la révélation de l'opération SolarWinds a changé la façon dont la communauté de sécurité parle de supply chain attacks. L'attaquant — identifié comme le groupe APT29, affilié au SVR russe — n'avait pas piraté directement les 18 000 organisations victimes. Il avait compromis le pipeline de build d'Orion, la plateforme de supervision réseau de SolarWinds, et injecté un backdoor baptisé SUNBURST dans les mises à jour légitimes distribuées aux clients pendant plusieurs mois.

Ce qui a rendu l'attaque si efficace n'était pas la sophistication du malware. SUNBURST était en réalité assez classique dans ses capacités : commande et contrôle via des requêtes DNS obfusquées, persistance dans le registre Windows, latence volontaire de deux semaines avant activation pour contourner les analyses sandbox post-déploiement. Ce qui l'a rendu dévastateur, c'est son vecteur : il arrivait signé numériquement par SolarWinds, via les canaux de mise à jour officiels, sans aucun indicateur de compromission visible pour les équipes sécurité des victimes. Les défenses classiques — antivirus, EDR, vérification de signature — ne pouvaient rien contre un binaire légitimement signé à partir d'un pipeline de build compromis.

JetBrains TeamCity était associé à cette histoire. Le serveur CI/CD utilisé par SolarWinds pour construire Orion tournait sur TeamCity, même si JetBrains a systématiquement contesté que son produit ait été le vecteur d'entrée initial. L'incident a mis TeamCity — et plus largement la catégorie CI/CD — sous les projecteurs des équipes red team et des agences gouvernementales. Le CISA, le FBI et la NSA ont publié des guidelines spécifiques sur la sécurisation des pipelines CI/CD dans les années qui ont suivi.

Six ans après SolarWinds, CVE-2026-63077 vient rappeler que la leçon n'a pas été retenue à l'échelle de l'industrie. TeamCity présente une nouvelle faille RCE non authentifiée CVSS 9.8 — la troisième critique de ce niveau en trois ans sur ce seul produit. Et selon les données Censys collectées fin juillet 2026, plus de 23 000 instances TeamCity sont accessibles directement depuis Internet sans protection de périmètre. Certaines tournent encore sur des versions de 2019. Dans les entreprises qui les opèrent, ces serveurs sont probablement considérés comme des outils internes sans risque externe particulier. Les groupes APT ont une opinion radicalement différente.

Pourquoi les APT ciblent vos builds en priorité

Pour un attaquant étatique ou un groupe criminel sophistiqué, le serveur CI/CD représente le Graal : accès aux secrets, levier sur la production, et persistance quasi indétectable. Voici les raisons précises pour lesquelles c'est une cible de choix.

L'accès aux secrets. Un serveur TeamCity, Jenkins ou GitHub Actions Runner typique d'une entreprise moyenne stocke entre 50 et 200 secrets opérationnels : clés d'API AWS, Azure et GCP, tokens d'accès GitHub et GitLab, credentials de bases de données de staging et de production, clés de signature de code, tokens d'accès aux registres Docker, identifiants de déploiement sur Kubernetes, clés SSH. Ces secrets sont là parce qu'ils sont nécessaires pour que les builds fonctionnent automatiquement. Un attaquant qui accède au serveur CI/CD les récupère tous en quelques minutes en lisant les variables d'environnement ou les fichiers de configuration des pipelines. Le pivot vers les environnements de production devient alors trivial.

La persistance silencieuse. Injecter un backdoor dans un pipeline de build est une forme de persistance particulièrement difficile à détecter. Le code malveillant est compilé avec le code légitime, signé avec les certificats de production, et distribué via les mécanismes de déploiement habituels. Les défenses classiques ne détectent pas un backdoor injecté au niveau du build, car le binaire final est signé à partir d'une source compromise mais considérée comme légitime par tous les systèmes de contrôle. Il faut une comparaison déterministe entre le code source git et le binaire produit (reproductible builds) pour détecter ce type d'injection a posteriori — et très peu d'organisations l'ont mis en place.

La propagation en aval. Un serveur CI/CD déploie vers les environnements de staging et de production. Un attaquant qui en prend le contrôle peut modifier les scripts de déploiement pour exfiltrer des données en production, installer des outils de reconnaissance sur les serveurs cibles, créer des comptes admin cachés, ou cartographier l'intégralité de l'infrastructure à travers les connexions que le pipeline établit avec ses systèmes de destination. C'est une latéralisation gratuite vers tout système que le pipeline a besoin d'atteindre — souvent sans déclencher d'alerte, car le serveur CI/CD est un émetteur de connexion autorisé dans les règles firewall.

L'angle mort organisationnel. Dans beaucoup d'organisations, les serveurs CI/CD sont gérés par les équipes DevOps ou plateforme, pas par la sécurité. Ils ne figurent pas dans le périmètre des scans de vulnérabilités réguliers. Ils ne sont pas supervisés par le SIEM. Leurs logs d'accès ne sont pas conservés 12 mois comme les logs des serveurs de production. Cette fragmentation organisationnelle crée exactement le type de zone grise que les APT cherchent à exploiter : un système à hautes permissions, peu surveillé, rarement patché en urgence, avec des droits de connexion vers la production.

L'historique d'exploitation de TeamCity : un cas d'école répété

TeamCity est devenu malgré lui le cas d'école des vulnérabilités CI/CD critiques. Le pattern se répète à un rythme inquiétant, sur le même produit, avec les mêmes conséquences.

Octobre 2023 — CVE-2023-42793. Bypass d'authentification CVSS 9.8 permettant à tout attaquant réseau d'accéder à l'interface d'administration sans identifiant. Les détails techniques ont circulé avant la communication officielle de JetBrains. Des acteurs APT nord-coréens (groupe Lazarus) et russes (Fancy Bear / APT28) ont exploité la faille dans les 48 heures. La CISA et le FBI ont publié un avis conjoint en décembre 2023 documentant des compromissions de chaînes d'approvisionnement logicielles, avec des victimes dans les secteurs défense, technologie et finance.

Mars 2024 — CVE-2024-27198 et CVE-2024-27199. Double bypass d'authentification (CVSS 9.8 et 7.3) permettant l'accès à l'API REST et au système de fichiers du serveur TeamCity sans authentification préalable. Rapid7 publie les détails techniques complets le 4 mars 2024. Le 5 mars au matin, des milliers de serveurs sont déjà en cours de compromission automatisée via des scanners publics. Des groupes ransomware (BianLian, Black Basta) utilisent ces accès initiaux pour déployer des cryptolockers, et des groupes d'espionnage pour installer des implants persistants dans les pipelines de build de leurs victimes.

Juillet 2026 — CVE-2026-63077. Désérialisation non authentifiée CVSS 9.8 dans le protocole de polling des agents. Même niveau de criticité, même surface d'attaque, même réponse requise en urgence. L'exploitation active n'est pas encore confirmée au 29 juillet 2026, mais le précédent suggère une fenêtre de 24 à 48 heures maximum après la publication d'un Proof of Concept.

Ce pattern se répète parce que les organisations ne traitent pas les serveurs CI/CD avec le même niveau de rigueur que leurs serveurs de production. Un serveur web exposé reçoit des patchs de sécurité en urgence, avec un processus d'escalade clair et des SLA définis. Un serveur TeamCity interne — même exposé sur Internet — peut rester sans patch pendant des semaines parce qu'il est perçu comme un outil de développement, pas comme une surface d'attaque externe critique. L'historique d'exploitation de TeamCity devrait avoir mis fin à cette perception depuis 2023.

Ce que j'observe en mission : les angles morts les plus courants

En intervention chez mes clients, je rencontre systématiquement les mêmes configurations problématiques autour des environnements CI/CD. Je les documente ici sans nommer de clients, mais les patterns sont suffisamment répandus pour être utiles à titre général.

Les runners sans segmentation vers la production. Pour que les pipelines de déploiement fonctionnent, les runners (GitHub Actions, GitLab CI, TeamCity agents) ont besoin d'accès aux environnements cibles. Dans beaucoup de configurations, ces runners sont placés dans une zone "interne" mais ont des règles de pare-feu qui leur permettent d'atteindre directement les serveurs de production sur des ports d'administration (SSH 22, Kubernetes API 6443, API cloud en accès direct). Un attaquant qui compromet un runner a une voie directe vers la production sans avoir à franchir d'autre périmètre. La solution — des runners ségrégués par environnement, avec des connexions pull depuis un vault centralisé — n'est pas complexe mais nécessite une refonte de l'architecture de déploiement que peu d'organisations font de manière proactive.

Les secrets en clair dans les fichiers de pipeline. GitHub Actions, GitLab CI et TeamCity permettent tous de stocker des secrets de manière sécurisée. Mais dans la pratique, ces mécanismes sont mal compris et souvent contournés : les développeurs hardcodent les credentials dans les fichiers YAML de pipeline, dans les scripts de build, ou les passent en variables d'environnement non protégées qui apparaissent en clair dans les logs de build. Un audit de 50 dépôts clients réalisé en 2025 a identifié des credentials en clair dans des fichiers CI dans 62 % des cas. Ces credentials sont lisibles par quiconque accède au serveur CI/CD — légitime ou malveillant.

L'absence de supervision du serveur CI/CD lui-même. Les serveurs TeamCity et Jenkins tournent souvent sans agent EDR, sans surveillance des processus fils, sans alerting sur les connexions sortantes. Si un attaquant exploite CVE-2026-63077 et spawne un shell, la détection repose uniquement sur la corrélation des logs réseau — quand ces logs existent et sont conservés avec une durée suffisante. Installer un agent EDR sur le serveur CI/CD, l'inclure dans le périmètre SIEM et alerter sur tout spawn de processus inattendu depuis le processus TeamCity ou Jenkins sont des mesures basiques mais rarement en place dans les environnements que je rencontre.

Les artefacts non vérifiables. La reproductibilité des builds (reproductible builds) est la seule garantie technique qu'un binaire produit correspond exactement au code source de référence. Sans elle, il est impossible de détecter une injection au niveau du pipeline a posteriori. Debian, NixOS, Firefox et Chromium ont mis en place des builds reproductibles avec succès à grande échelle. Dans les entreprises, c'est encore extrêmement rare. Pour les logiciels distribués à des tiers ou déployés sur des infrastructures critiques, cette exigence devient néanmoins pertinente dans le contexte des obligations NIS2 sur la sécurité de la chaîne d'approvisionnement.

La gestion des droits des pipelines. Les pipelines de build ont besoin de droits pour fonctionner, mais ces droits sont souvent surfacés : accès en écriture à l'ensemble des branches d'un dépôt, credentials d'un compte de service avec des droits administrateur en production, tokens API sans restriction de scope. Appliquer le principe du moindre privilège aux pipelines — un token de déploiement qui ne peut écrire que dans un environnement spécifique, un compte de service qui ne peut pas lire les secrets de production — réduit considérablement l'impact d'une compromission du pipeline.

La réglementation arrive — préparez-vous maintenant

La directive NIS2, transposée en droit français par la loi de transposition de 2024, impose aux entités essentielles et entités importantes une gestion rigoureuse de la sécurité de leur chaîne d'approvisionnement logicielle. L'article 21 de NIS2 cite explicitement la sécurité des processus de développement et des chaînes d'approvisionnement comme mesures techniques et organisationnelles minimales.

L'ENISA, dans ses guidelines sur la sécurité de la supply chain logicielle publiées en 2024, liste la sécurisation des environnements de build et de CI/CD parmi les 10 contrôles prioritaires pour les entités soumises à NIS2. Concrètement, lors d'un audit de conformité NIS2, un serveur CI/CD exposé sur Internet sans patch récent, sans monitoring et sans contrôle des secrets sera un finding de première priorité pouvant conduire à une non-conformité formelle.

Aux États-Unis, le NIST SP 800-218 (Secure Software Development Framework) et l'Executive Order 14028 imposent aux fournisseurs de logiciels travaillant avec le gouvernement fédéral de documenter et sécuriser leurs pipelines CI/CD, avec des attestations de conformité. Le marché européen de la défense commence à aligner ses exigences de qualification sur des critères similaires, notamment pour les contrats relevant du règlement EUCS (European Union Cybersecurity Scheme).

La fenêtre pour traiter ce sujet de manière proactive se réduit. Attendre un incident pour justifier l'investissement dans la sécurité CI/CD, c'est choisir d'apprendre à ses dépens avec les coûts associés : remédiation forensique (souvent entre 200 000 et 800 000 euros pour un incident CI/CD majeur selon les données Mandiant 2025), reconstruction complète des pipelines, renouvellement de tous les secrets, notification réglementaire si des données clients sont accessibles depuis les pipelines, et impact réputationnel si vous distribuez des logiciels à des tiers.

5 actions concrètes à lancer cette semaine

Sans rentrer dans une roadmap pluriannuelle, voici ce qui peut être fait rapidement avec un impact immédiat sur le risque.

1. Patcher CVE-2026-63077 maintenant. Si vous tournez sur TeamCity On-Premises, c'est l'urgence absolue du jour. Versions cibles : 2025.11.7 ou 2026.1.3. Si vous ne pouvez pas patcher immédiatement, installez le plugin de sécurité JetBrains et isolez le serveur derrière un VPN dans l'attente de la fenêtre de maintenance.

2. Inventorier tous vos serveurs CI/CD exposés sur Internet. Lancez un scan de votre périmètre externe avec Shodan, Censys, ou votre outil de gestion de surface d'attaque pour identifier les instances CI/CD visibles depuis l'extérieur. Tout ce qui n'a pas besoin d'être exposé doit passer derrière un VPN ou être restreint par liste blanche d'IP dans les 24 heures.

3. Auditer les secrets stockés dans vos pipelines. Cherchez dans vos fichiers YAML CI, vos scripts de build et vos variables d'environnement de pipeline tout ce qui ressemble à une clé d'API, un mot de passe ou un token. Migrez-les vers un gestionnaire de secrets (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) avec rotation automatique. C'est un chantier de quelques jours pour un bénéfice durable.

4. Installer un EDR sur vos serveurs CI/CD. Tout serveur qui a accès à vos environnements de production et à vos secrets doit être supervisé par un agent de détection. Configurez des alertes sur tout spawn de processus shell (bash, sh, cmd, powershell) depuis le processus principal de votre serveur CI/CD — c'est le signal d'exploitation le plus fiable pour une RCE de type CVE-2026-63077.

5. Tester votre plan de réponse. Si votre serveur CI/CD est compromis demain matin, avez-vous une procédure documentée pour identifier les builds potentiellement compromis, révoquer tous les secrets, reconstruire le pipeline depuis un état contrôlé et notifier les équipes concernées ? Si la réponse est non, c'est le chantier qui mérite le plus d'attention cette semaine.

Mon avis d'expert

CVE-2026-63077 sur TeamCity n'est pas une surprise. C'est la troisième vulnérabilité critique CVSS 9.8 sur ce produit en trois ans, avec le même schéma à chaque fois : faille divulguée, exploitation en 48 heures, organisations non patchées compromises. Le problème n'est pas JetBrains — toutes les plateformes CI/CD ont leurs vulnérabilités. Le problème, c'est qu'on continue à traiter les serveurs CI/CD comme des outils de développement internes sans risque externe, alors qu'ils sont devenus l'un des actifs les plus critiques de toute organisation qui développe du logiciel. Si vous gérez un pipeline de déploiement vers de la production et que vous n'avez pas de monitoring sur votre serveur de build, vous avez un angle mort majeur que les APT ont appris à exploiter systématiquement. La bonne question n'est pas "est-ce que quelqu'un va attaquer notre TeamCity ?". Elle est : "combien de temps avant qu'on le détecte si c'est déjà fait ?"

Conclusion

La supply chain logicielle est le champ de bataille de la décennie. SolarWinds l'a démontré en 2020. 3CX l'a confirmé en 2023. Les vulnérabilités répétées de TeamCity le rappellent chaque année depuis 2023. L'objectif des attaquants n'est plus de forcer les portes — c'est de s'inviter par la porte de service que personne ne surveille : votre pipeline de build.

Sécuriser vos pipelines CI/CD n'est pas un projet de sécurité parmi d'autres. C'est une condition préalable à la sécurité de tout ce que vous déployez. Et contrairement à beaucoup de chantiers de sécurité, les gains les plus importants s'obtiennent avec des mesures de bon sens : patcher, isoler, monitorer, gérer les secrets proprement. Commencez par là. Cette semaine, pas au prochain trimestre.

Besoin d'un regard expert sur votre sécurité ?

Discutons de votre contexte spécifique.

Prendre contact