Vos forges Git internes sont le nouveau vecteur supply chain : ce que Gitea CVE-2026-60004 révèle de votre angle mort DevSecOps

CVE-2026-60004 sur Gitea a été ajoutée au KEV CISA le 25 août 2026. Une RCE CVSS 9.8 exploitée en moins d'un mois après le patch, sur des milliers d'instances auto-hébergées accessibles depuis internet. La vraie question n'est pas « pourquoi Gitea n'a pas patché plus vite » — c'est « pourquoi vos forges Git internes ne sont pas dans le périmètre de votre programme de sécurité ? »

Le paradoxe de la forge auto-hébergée : entre souveraineté et dette sécurité

Depuis 2022, une migration significative d'équipes de développement vers des forges auto-hébergées est observable. Les raisons sont légitimes : contrôle des données, indépendance vis-à-vis des tarifs GitHub ou GitLab, conformité RGPD sur l'hébergement du code source, souveraineté numérique. Gitea, Forgejo, Gogs, GitLab CE — ces outils sont fonctionnellement excellents et représentent un choix parfaitement rationnel pour de nombreuses organisations.

Le problème, c'est ce qui arrive après le déploiement. J'ai conduit des audits dans des PME de 200 à 2000 salariés où l'instance Gitea avait été installée par un développeur motivé un weekend, mise en production le lundi, et oubliée dans le programme de patching pendant 18 mois. Le service tourne, les développeurs sont contents, les commits s'enchaînent — et personne ne pense à vérifier si une CVE critique est sortie depuis l'installation. C'est le paradoxe de l'auto-hébergement : vous avez choisi de prendre le contrôle, mais vous avez aussi pris la responsabilité de tout ce qui va avec.

Les chiffres parlent d'eux-mêmes. Les estimations compilées par plusieurs équipes de recherche en août 2026 évaluent à plus de 85 000 le nombre d'instances Gitea directement exposées sur internet. Parmi elles, 20% à 35% tournaient encore en version vulnérable à CVE-2026-60004 au moment de l'alerte CISA. Ce n'est pas de la négligence individuelle : c'est un problème systémique de gouvernance de la sécurité sur les outils de développement.

La forge n'est pas juste un outil dev : c'est le cœur de votre supply chain interne

Quand on parle de « supply chain attacks », les esprits vont immédiatement vers SolarWinds, XZ Utils, les compromissions de packages npm. Des attaques sur des fournisseurs externes qui injectent du code malveillant dans des logiciels distribués massivement. C'est réel, documenté, important. Mais il y a un angle mort encore plus proche de vous : votre supply chain interne.

Votre forge Git, c'est là où tout votre code source est stocké. Les pipelines CI/CD qui s'y connectent ont accès aux environnements de staging et de production. Les runners CI/CD ont des secrets — tokens AWS, clés API, credentials de base de données — stockés dans des variables d'environnement. Les artifacts buildés sont déployés directement sur vos serveurs. La forge est le hub central de votre chaîne de valeur logicielle.

Un attaquant qui prend le contrôle de votre instance Gitea peut :

• Modifier les scripts de build pour injecter un backdoor dans chaque version déployée en production
• Accéder aux variables CI/CD contenant les credentials de vos environnements cloud, bases de données, services tiers
• Planter des hooks Git qui s'exécutent à chaque commit de tous les développeurs
• Exfiltrer l'intégralité du code source — propriété intellectuelle, algorithmes, configurations métier
• Pivoter vers les environnements connectés via les runners CI/CD qui ont accès aux clusters Kubernetes, serveurs cloud, VPNs

C'est exactement le scénario documenté dans l'incident Habr lié à CVE-2026-60004 : l'organisation compromise a découvert que l'attaquant avait non seulement installé un cryptomineur, mais aussi exfiltré les dépôts contenant les tokens d'accès à leur infrastructure cloud. La réponse à incident a nécessité une rotation complète de tous les secrets, une réinstallation des runners CI/CD, et un audit de tous les déploiements des 30 derniers jours pour vérifier l'absence d'injection de code malveillant.

Anatomie d'une exploitation supply chain via une forge vulnérable

Pour rendre les choses concrètes, voici le déroulé type d'une exploitation de CVE-2026-60004 — basé sur les techniques documentées et les incidents analysés.

Phase 1 — Reconnaissance (quelques minutes). L'attaquant utilise Shodan, Fofa ou Censys pour identifier les instances Gitea exposées. La version est affichée publiquement dans le footer des interfaces Gitea. En quelques secondes, il dispose d'une liste d'instances vulnérables avec leurs IPs et leurs versions exactes.

Phase 2 — Accès initial (5 à 10 minutes). L'attaquant crée un compte utilisateur (inscription ouverte activée par défaut), crée un dépôt, y dépose un fichier patch forgé contenant un hook Git malveillant, et soumet le patch. Le serveur exécute le hook avec les privilèges du compte de service Gitea — qui dispose généralement de droits étendus sur le filesystem et les clés SSH des dépôts.

Phase 3 — Persistance et pivotement (variable selon l'objectif). Une fois le shell obtenu, l'attaquant installe une backdoor persistante, clone l'ensemble des dépôts accessibles, extrait les variables d'environnement des runners CI/CD, et commence à explorer le réseau interne depuis le serveur Gitea. Si les runners tournent sur le même serveur ou ont des accès réseau privilégiés, l'attaquant peut atteindre les environnements de production sans exploiter d'autres vulnérabilités.

Phase 4 — Action sur l'objectif. Cryptomineur pour les groupes opportunistes, ransomware pour les opérateurs spécialisés, exfiltration de propriété intellectuelle pour les APT, injection de backdoor dans le code pour les attaques supply chain sophistiquées. Le délai entre accès initial et action finale varie de quelques heures (cryptomineur automatisé) à plusieurs semaines (APT implantant un accès dormant dans les pipelines).

Ce que CVE-2026-60004 révèle sur la maturité DevSecOps réelle des organisations

J'entends souvent « on fait du DevSecOps » dans les organisations que j'audite. En creusant, ça signifie généralement : scanner SAST dans le pipeline CI/CD, DAST en recette, scan des containers. C'est bien. Mais la sécurité des outils qui orchestrent ce pipeline ? Rarement dans le scope.

C'est le paradoxe de la protection périmétrique DevSecOps : on sécurise ce qui sort de la forge — le code, les containers, les déploiements — mais pas la forge elle-même. C'est comme équiper tous vos coffres-forts de serrures de haute sécurité tout en laissant la porte de la salle des coffres ouverte.

Voici les cinq angles morts les plus fréquents que j'observe :

1. Les outils de développement sont exclus du périmètre de vulnérabilité management. Le programme de gestion des patches couvre Windows, Linux, les équipements réseau, les middlewares. Mais Gitea, Jenkins, Nexus, Harbor, ArgoCD ? Souvent hors scope. Ces outils sont considérés comme des « outils internes » qui ne méritent pas le même traitement que les serveurs exposés. C'est une erreur fondamentale.

2. Les runners CI/CD ont des secrets trop larges. Par commodité, les tokens AWS des pipelines sont souvent des tokens admin ou avec des politiques trop permissives. Un attaquant qui compromet le runner a accès à toute l'infrastructure. La bonne pratique — tokens avec scope minimal, rotation régulière, rôles IAM plutôt que clés statiques — est connue mais rarement appliquée.

3. Les forges ne sont pas dans le scope des tests de pénétration. Le périmètre du pentest couvre le site web, le portail client, les APIs. La forge interne est exclue parce qu'elle est « interne » ou parce que les développeurs ne voulaient pas de perturbation. Résultat : personne n'a jamais testé ce qu'un attaquant peut faire avec un accès en lecture sur un dépôt Gitea.

4. La configuration par défaut n'est jamais revue. L'inscription ouverte de Gitea, les permissions par défaut des dépôts, les hooks Git non supervisés, les APIs admin sans authentification forte — les configurations par défaut des outils de développement sont rarement revues avec un œil sécurité. L'urgence de mettre l'outil en production prime sur la revue de la configuration.

5. Les logs des forges ne remontent pas dans le SIEM. On collecte les logs des serveurs web, des firewalls, des endpoints. Mais les logs d'accès de Gitea, les créations de comptes, les opérations sur les hooks ? Rarement présents dans le SIEM. Un attaquant peut explorer la forge pendant des semaines sans déclencher aucune alerte.

Le référentiel de sécurité d'une forge Git : à quoi ça devrait ressembler

Sécuriser une forge Git auto-hébergée n'est pas une mission impossible. Voici les mesures concrètes que j'applique dans les missions d'accompagnement DevSecOps, classées par priorité :

Niveau 1 — Mesures immédiates (0 à 2 semaines, coût zéro)

• Inventaire des instances : Cartographier toutes les forges Git de l'organisation, y compris les instances « sauvages » lancées par des équipes sans validation IT
• Versioning systématique : Intégrer les forges dans le suivi des versions du parc logiciel, avec alertes automatiques sur les nouvelles CVE (abonnement RSS NVD pour les packages concernés)
• Désactivation de l'inscription ouverte : Bloquer la création de comptes non autorisée sur toutes les instances exposées
• MFA obligatoire : Activer l'authentification multi-facteurs pour tous les comptes administrateurs et développeurs
• Audit des hooks Git existants : Vérifier tous les hooks en place pour s'assurer qu'ils sont légitimes et documentés

Niveau 2 — Architecture sécurité (2 à 8 semaines)

• Segmentation réseau : La forge ne doit pas être directement exposée sur internet si ce n'est pas fonctionnellement nécessaire — accès via VPN ou zero-trust gateway
• Principe du moindre privilège sur les runners CI/CD : Chaque pipeline n'accède qu'aux ressources strictement nécessaires, rotation des tokens tous les 90 jours maximum
• Intégration des logs dans le SIEM : Authentification, créations de comptes, accès aux dépôts sensibles et modifications de hooks doivent remonter dans votre outil de surveillance
• Scanning des secrets dans les dépôts : Outils comme Truffelhog ou Gitleaks pour détecter les secrets commités accidentellement
• WAF devant la forge : Règles spécifiques pour les forges Git capables de détecter les tentatives d'exploitation de CVE connues

Niveau 3 — Maturité opérationnelle (2 à 6 mois)

• Pentest annuel incluant les forges : Intégrer explicitement les outils de développement dans le scope des tests d'intrusion
• Procédure de réponse à incident spécifique : Documenter le plan de réponse pour une compromission de forge — isolation, audit des dépôts, rotation des secrets, vérification des déploiements
• Supply chain integrity : Signer les artifacts de build (SLSA level 2+), vérifier les checksums des dépendances, registre de packages interne avec scan des malwares
• Red team exercise : Simuler l'exploitation d'une forge pour mesurer le temps de détection et la capacité de réponse

Ce qui va changer dans les 6 prochains mois

CVE-2026-60004 ne sera pas la dernière vulnérabilité critique sur une forge Git auto-hébergée. La tendance de fond est claire : les attaquants ont compris que les outils de développement sont le maillon faible de la chaîne de sécurité enterprise.

La réglementation va rattraper les forges. NIS2 et DORA imposent déjà une gestion des risques sur la chaîne d'approvisionnement logicielle. Les autorités de contrôle vont progressivement étendre leur interprétation pour inclure les outils de développement internes dans le périmètre des exigences. Les organisations sans forges sécurisées se retrouveront en non-conformité.

Les assureurs cyber vont auditer les forges. Plusieurs courtiers d'assurance cyber ont déjà commencé à inclure des questions sur les forges Git dans leurs questionnaires de souscription. Dans 12 à 18 mois, une instance Gitea non patchée accessible depuis internet pourrait suffire à invalider une couverture ou augmenter significativement la prime.

Les attaquants vont sophistiquer les payloads post-exploitation. Les cryptomineurs observés sur CVE-2026-60004 sont la phase initiale opportuniste. Les groupes APT et opérateurs ransomware vont développer des playbooks spécifiques pour les forges Git — implantation dormante dans les pipelines CI/CD, conçue pour survivre aux réinstallations et rotations de secrets.

Les forges vont évoluer vers plus de sécurité par défaut. Suite à l'impact de CVE-2026-60004, Gitea et Forgejo ont annoncé pour la version 1.28 des révisions des configurations par défaut : inscription ouverte désactivée par défaut, validation plus stricte des hooks, mode « hardened » proposé. Un pas dans la bonne direction, qui n'aide pas les instances existantes.

Conclusion

CVE-2026-60004 sur Gitea n'est pas un incident isolé. C'est le symptôme d'un angle mort structurel dans la façon dont les organisations appréhendent la sécurité de leurs environnements de développement. Vos forges Git internes centralisent votre code, vos secrets, vos pipelines de déploiement — elles méritent d'être dans le périmètre de votre programme de sécurité au même titre que vos serveurs de production.

La bonne nouvelle : sécuriser une forge Git n'est pas hors de portée. Désactiver l'inscription ouverte, activer le MFA, intégrer les logs dans le SIEM, inclure la forge dans le patch management — des actions réalisables en quelques semaines avec des ressources raisonnables. Ce qui manque souvent, c'est la prise de conscience que le sujet est urgent et la volonté de l'intégrer dans le programme de sécurité existant.

Si CVE-2026-60004 vous a fait réaliser que vous n'avez pas de visibilité sur l'état de sécurité de vos outils de développement, c'est le bon moment pour y remédier — avant que ce soit un attaquant qui vous le signale.