Forges Git auto-hébergées : la cible la plus sous-estimée

La CVE-2026-59774 affectant Gitea, publiée début août 2026 avec un score CVSS de 9,8, a déclenché une vague d'urgence dans les équipes DevOps. Un attaquant non authentifié peut lire des fichiers arbitraires sur le serveur, récupérer les secrets de l'instance, puis enchaîner vers une exécution de code à distance. Spectaculaire, certes. Mais le plus révélateur reste la surprise générale qu'elle a suscitée : rares sont les organisations qui avaient inscrit la sécurité forge Git auto-hébergée dans leur périmètre de supervision. Gitea, GitLab CE ou Forgejo hébergent pourtant l'intégralité de la propriété intellectuelle, les pipelines CI/CD, les jetons de déploiement et souvent les accès aux environnements de production. Ce serveur discret, installé un vendredi après-midi par une équipe pressée, concentre aujourd'hui plus de valeur exploitable que n'importe quel poste de travail de votre parc.

La forge Git : de l'outil DevOps a l'infrastructure critique

Il y a dix ans, heberger soi-meme son depot Git etait un choix pragmatique : autonomie vis-a-vis des fournisseurs cloud, controle des couts, et confidentialite des donnees — particulierement sensible dans les secteurs reglementes comme la defense, la finance ou la sante. Gitea, GitLab CE, Gogs : des outils legers, simples a deployer, open source. On les installait en quelques minutes sur un VPS ou un serveur interne.

En pratique, les incidents que nous traitons révèlent que l'écart entre politiques de sécurité documentées et application réelle est presque toujours plus grand que prévu. La vérification terrain régulière reste la seule façon de mesurer ce delta.

— Retour terrain, Ayi NEDJIMI Consultants

En 2026, la realite est radicalement differente. La forge Git n'est plus un simple gestionnaire de versions. C'est le nœud central de toute la chaine de production logicielle d'une organisation. Elle heberge le code source — y compris les logiciels embarques dans les produits livres aux clients. Elle integre les pipelines CI/CD qui construisent, testent et deploient automatiquement les applications. Elle stocke les configurations d'infrastructure-as-code (Terraform, Ansible, Helm charts). Elle gere les webhooks qui declenchent des actions en cascade sur des dizaines de systemes tiers. Et souvent, elle devient le premier endroit ou les developpeurs stockent des identifiants, tokens et cles API temporairement — qui restent finalement des annees dans l'historique Git.

Si vous avez du mal a visualiser la valeur strategique de votre forge Git, faites l'exercice mental suivant : que se passerait-il si un concurrent ou un attaquant etatique avait acces en lecture a l'integralite de vos depots ? Code source de vos produits. Logique metier proprietaire. Algorithmes developpes sur des annees. Secrets d'API pour vos partenaires. Architecture de votre SI. Identifiants de comptes de service cloud. Cles de chiffrement. Mots de passe en dur dans d'anciens commits. La reponse, dans la majorite des organisations que j'audite, serait catastrophique.

Or, cette infrastructure critique est souvent geree avec beaucoup moins de rigueur que l'Active Directory, le pare-feu perimetrique ou le VPN. La forge Git a une image d'outil developpeur — pas d'infrastructure de securite. Cette perception erronee est a l'origine de la majorite des risques que j'observe en audit. Les equipes securite ne l'ont souvent pas dans leur perimetre de supervision. Les equipes DevOps la gerent comme un service utilitaire. Personne n'est vraiment responsable de sa securite end-to-end.

Gitea, Forgejo, Gogs, GitLab CE : un ecosysteme populaire mais rarement securise par defaut

L'ecosysteme des forges Git auto-hebergees est domine par quatre acteurs principaux. Gitea, le plus populaire en volume de deploiements, est un projet Go leger et performant. Forgejo est son fork communautaire ne en 2022 apres des inquietudes sur la gouvernance de Gitea Inc. — il partage donc la quasi-totalite du code base historique, y compris les vulnerabilites. Gogs est l'ancetre dont Gitea est derive, moins activement maintenu depuis plusieurs annees. GitLab Community Edition est la version open source de GitLab, fonctionnellement la plus riche mais aussi la plus lourde a operer et a maintenir.

Ces quatre plateformes ont en commun un probleme structurel : leurs configurations par defaut sont optimisees pour la facilite d'installation et de prise en main, pas pour la securite. Gitea, dans sa configuration standard, expose son interface web directement sur le port 3000. Il n'y a pas de MFA active par defaut. Les depots peuvent etre crees publics sans avertissement particulier. L'API REST est accessible sans rate limiting significatif. Les webhooks peuvent pointer vers n'importe quelle URL, y compris des serveurs internes — une surface d'attaque SSRF classique.

GitLab CE est legerement mieux loti sur certains points, avec une interface de securite plus mature et des alertes sur les configurations risquees. Mais sa complexite operationnelle — une quarantaine de services en arriere-plan dans une installation standard — rend les mises a jour plus difficiles a appliquer et augmente la surface d'attaque globale. Les organisations qui oublient de patcher leur instance GitLab pendant six mois ne sont pas rares, et chaque cycle de patches apporte son lot de CVE critiques.

Du cote de l'exposition reseau, des analyses recurrentes de Shodan et Censys montrent des milliers d'instances Gitea, Gogs et GitLab directement exposees sur Internet, sans reverse proxy, sans WAF, et souvent avec des comptes d'administration accessibles par defaut. En 2025, une etude de Censys avait identifie plus de 60 000 instances Gitea exposees sur Internet, dont environ 30% presentaient au moins un indicateur de mauvaise configuration evidente. En 2026, ces chiffres n'ont pas significativement diminue malgre la multiplication des vulnerabilites mediatisees.

CVE-2026-59774 comme cas d'ecole : quand le rendu de markup devient une arme

La CVE-2026-59774, publiee le 2 aout 2026 avec l'advisory GHSA-6v53-hr58-556r, illustre parfaitement la problematique des dependances tierces mal controlees dans les projets open source. Le vecteur de la faille est l'endpoint POST /{owner}/{repo}/markup, qui permet de rendre du contenu markup pour previsualisation. Ce type de fonctionnalite existe dans toutes les forges modernes — utile, pratique, et a priori peu risque.

Le probleme vient de la bibliotheque go-org, qui gere le format Emacs Org-mode dans Gitea. Ce format supporte une directive #+INCLUDE permettant d'inclure le contenu d'un autre fichier lors du rendu. C'est une fonctionnalite legitime dans Emacs, ou l'utilisateur controle son environnement. Mais dans Gitea, cette directive est traitee cote serveur, avec un simple appel a ioutil.ReadFile sur le chemin specifie par l'attaquant — sans aucune validation, sans restriction de chemin, sans sandboxing. Resultat : un attaquant peut lire n'importe quel fichier accessible au processus Gitea sur le systeme de fichiers du serveur.

Ce qui transforme cette lecture de fichier en RCE potentiel, c'est la chaine d'exploitation qui s'ensuit. Le fichier app.ini contient un parametre INTERNAL_TOKEN, un secret cryptographique utilise pour authentifier les communications entre les composants internes de la plateforme. Avec ce token, un attaquant peut appeler l'API interne de Gitea pour injecter un hook Git — un script execute automatiquement lors d'operations Git comme un clone. Il lui suffit ensuite de declencher ce hook via une operation de clone anonyme. La chaine complete : lecture d'un fichier de configuration, recuperation d'un secret interne, injection d'un hook, execution de commandes arbitraires. Et tout cela sans le moindre compte utilisateur sur l'instance.

Ce pattern — une bibliotheque tierce traitant des inputs non fiables avec des privileges trop larges — est recurrent dans les forges Git. On retrouve des vulnerabilites similaires dans les parseurs de contenu Markdown, les generateurs de diagrammes (Mermaid, PlantUML), les previsualiseurs de fichiers. Chaque fonctionnalite de rendu de contenu est une surface d'attaque potentielle si la bibliotheque sous-jacente n'a pas ete concue pour des inputs hostiles. La lecon : toute dependance qui lit des fichiers, execute des commandes ou effectue des requetes reseau doit etre traitee comme un risque de securite et isolee en consequence.

Pour les organisations utilisant Forgejo, le fork de Gitea, la situation est identique : le code base etant quasi-identique a Gitea au moment de la divergence, les instances Forgejo non mises a jour sont tres probablement affectees par le meme vecteur d'attaque.

L'inventaire que personne ne fait : ce que contient vraiment votre forge

Avant de parler de solutions, il faut avoir une vision claire de ce qu'une forge Git detient reellement. Dans la grande majorite des organisations que j'audite, les equipes ne peuvent pas repondre precisement a cette question. Elles savent qu'il y a du code sur la forge, mais l'inventaire precis de ce code et de ce qu'il contient est rarement formalise.

Voici ce qu'on trouve systematiquement dans une forge Git d'une organisation de taille moyenne. Du code source proprietaire, evidemment — mais aussi : des fichiers de configuration d'infrastructure avec des adresses IP internes, des noms de serveurs, des ranges reseau ; des fichiers .env commites par erreur avec des mots de passe de base de donnees, des tokens Stripe ou Twilio, des cles AWS ; des cles SSH privees de deploiement stockees temporairement dans un depot de configuration ; des tokens Kubernetes en clair dans des fichiers de configuration Helm ; des identifiants de comptes de service cloud (AWS IAM keys, service accounts GCP) dans des scripts d'infrastructure-as-code ; des certificats TLS et leurs cles privees ; et parfois des exports de bases de donnees commites comme fixtures de test qui n'ont jamais ete supprimes de l'historique Git.

La problematique des secrets dans Git est aggravee par un facteur souvent sous-estime : la permanence de l'historique. Meme si un fichier contenant un secret est supprime dans un commit ulterieur, il reste accessible via git log, git show, ou un simple git checkout sur l'ancien commit. La suppression d'un secret dans un depot Git ne supprime pas le secret — elle ne fait que le rendre moins visible. La seule facon de vraiment nettoyer un secret de l'historique Git est une reecriture d'historique via git filter-branch ou BFG Repo-Cleaner, une operation complexe et impactante pour les equipes.

Des outils comme truffleHog, gitleaks ou git-secrets permettent de scanner les depots — y compris l'historique complet — pour detecter des secrets. Selon une etude publiee par GitGuardian en 2026, plus de 10 millions de secrets ont ete detectes dans des depots publics GitHub au cours de l'annee 2025. Dans les depots prives auto-heberges, la proportion est generalement plus elevee encore, precisement parce que les developpeurs se sentent en securite et font moins attention.

Les 7 erreurs de configuration que je retrouve systematiquement en audit

Apres des dizaines d'audits impliquant des forges Git auto-hebergees, j'ai identifie un ensemble d'erreurs qui reviennent avec une regularite decourageante.

1. L'exposition directe sur Internet sans reverse proxy. La forge est accessible directement sur son port par defaut (3000 pour Gitea, 80/443 pour GitLab). Aucun WAF, aucun rate limiting applicatif, aucune protection contre les scans automatises. Cela concerne environ 60% des instances que j'audite en environnement PME.

2. Pas de MFA sur les comptes avec des droits eleves. Les comptes administrateurs accedent a la forge avec un simple mot de passe. Dans un contexte ou les attaques par credential stuffing sont massives, c'est une invitation a la compromission. Gitea supporte TOTP nativement, GitLab CE supporte TOTP et WebAuthn. L'activation du MFA pour les comptes sensibles est une action de cinq minutes.

3. Des depots publics par accident. Un developpeur cree un depot public pensant que la forge est sur le reseau interne, sans realiser qu'elle est exposee sur Internet. J'ai trouve des depots contenant du code proprietaire sensible en acces public dans des organisations convaincues que tout etait prive.

4. Des cles SSH de deploiement sans rotation et sans restriction. Des cles SSH de deploiement creees des annees auparavant, avec des droits en ecriture sur des depots critiques, sans date d'expiration, souvent stockees sur des serveurs CI dont les acces n'ont jamais ete audites. Si l'un de ces serveurs CI est compromis, l'attaquant a acces en ecriture a vos depots les plus sensibles.

5. Pas de monitoring des acces et des actions sensibles. La forge est installee, les logs tournent quelque part, mais personne ne les surveille. Les connexions suspectes, les clonages massifs de depots, les creations de webhooks inhabituelles — tout cela se produit sans qu'aucune alerte ne soit levee. Dans les organisations plus matures, les logs de la forge ne sont meme pas dans le SIEM.

6. Des instances non patchees depuis des mois. Mettre a jour Gitea ou GitLab n'est pas trivial — ca demande du temps et une fenetre de maintenance. Alors on reporte. J'ai audite des instances GitLab CE a deux versions majeures de retard, avec des dizaines de CVE critiques en attente. La fenetre d'exploitation entre la publication d'un CVE et son exploitation active est mesuree par Rapid7 a moins de 48h pour les vulnerabilites les plus critiques en 2026.

7. Des webhooks non valides pointant vers des systemes internes. Gitea et GitLab permettent de configurer des webhooks qui envoient des requetes HTTP sur des evenements Git. Si un attaquant peut creer un webhook pointant vers un service interne (Kubernetes API, Jenkins, AWS metadata endpoint), il a potentiellement un vecteur SSRF vers votre reseau interne depuis la forge.

Guide de durcissement : 12 actions concretes

1. Mettez a jour votre instance immediatement et maintenez-la a jour. Abonnez-vous aux release notes de votre forge. Ciblez une mise a jour dans les 72 heures pour les CVE critiques (CVSS >= 9). Pour les CVE moderees, une semaine est un maximum raisonnable.

2. Placez votre forge derriere un reverse proxy avec WAF. Nginx ou Caddy avec des regles de filtrage basiques : rate limiting sur les endpoints d'authentification, blocage des patterns d'exploitation connus (path traversal, injection de directives dans les requetes markup), limitation des user agents de scanners connus.

3. Activez le MFA pour tous les comptes avec des droits etendus. Administrateurs, proprietaires de groupes et d'organisations, developpeurs avec acces a des depots critiques. Si votre organisation dispose d'un fournisseur SSO/SAML (Okta, Keycloak, Azure AD), integrez la forge dedans.

4. Auditez et nettoyez vos depots publics. Inventoriez tous les depots marques comme publics sur votre instance. Configurez Gitea pour que les nouveaux depots soient prives par defaut (parametre DEFAULT_PRIVATE dans app.ini).

5. Scannez l'historique de vos depots pour les secrets. Utilisez truffleHog ou gitleaks sur l'ensemble de votre base de code, y compris l'historique Git complet. Pour les secrets trouves : revoquez-les immediatement. Integrez ce scan dans votre pipeline CI/CD pour bloquer les nouveaux commits contenant des secrets.

6. Auditez et limitez les deploy keys. Listez toutes les deploy keys configurees sur vos depots. Supprimez celles qui ne sont plus utilisees. Pour celles encore actives, verifiez qu'elles sont en lecture seule si l'ecriture n'est pas necessaire. Mettez en place une rotation annuelle minimale.

7. Integrez les logs de la forge dans votre SIEM. Definissez des alertes sur : connexions admin depuis des IPs inconnues, echecs d'authentification repetes, creations de webhooks ou de deploy keys, acces a des depots sensibles en dehors des horaires habituels.

8. Bloquez les webhooks vers les reseaux internes. Dans Gitea, le parametre WEBHOOK_ALLOWED_HOST_LIST dans app.ini permet de restreindre les URLs de destination des webhooks. Configurez-le pour exclure les plages reseau internes (RFC 1918). Cela previent les attaques SSRF via webhooks.

9. Isolez la forge sur un reseau dedie. La forge Git ne devrait pas etre sur le meme segment reseau que vos serveurs de production, votre Active Directory ou vos bases de donnees. Utilisez des VLAN et des regles de pare-feu strictes.

10. Limitez l'acces a l'API interne de Gitea. L'API interne de Gitea est le vecteur exploite dans la chaine CVE-2026-59774. Elle ne devrait etre accessible que depuis localhost ou depuis les processus Gitea eux-memes. Verifiez votre configuration reseau pour vous assurer qu'elle n'est pas accessible de l'exterieur du conteneur.

11. Activez la protection contre les push forces sur vos branches critiques. Des branch protection rules empechent les push forces sur les branches principales, qui pourraient etre utilises pour reecrire l'historique et effacer des preuves apres une compromission, ou pour injecter du code malveillant.

12. Faites des exercices de reponse a incident incluant votre forge. Que faites-vous si votre forge est compromise ? Qui est contacte ? Comment isolez-vous l'instance ? Comment auditez-vous les depots pour des modifications non autorisees ? Ces questions meritent des reponses documentees avant l'incident, pas pendant.

Questions fréquentes

Qu'est-ce que securite forge Git auto-hebergee et pourquoi est-ce important ?

La réponse dépend du contexte organisationnel, mais les principes fondamentaux restent constants : évaluation du périmètre, identification des actifs critiques et priorisation par risque réel plutôt que par vulnérabilité isolée.

Comment mettre en oeuvre les bonnes pratiques liées à securite forge Git auto-hebergee ?

Une approche structurée et documentée est clé. Les outils et méthodologies évoluent rapidement — rester informé des ressources ANSSI, NIST et MITRE ATT&CK est indispensable pour adapter les recommandations génériques à chaque contexte.

Quelles ressources pour approfondir securite forge Git auto-hebergee ?

Les ressources officielles (ANSSI, CISA, CERT-FR) constituent le point de départ. Complétées par des retours d'expérience terrain, elles permettent d'adapter les recommandations aux réalités opérationnelles de chaque organisation.

Conclusion : la forge Git, le maillon faible qui concentre le plus de valeur

La securite des forges Git auto-hebergees est un angle mort structurel dans la posture de securite de nombreuses organisations. Pas par malveillance ou negligence deliberee, mais parce que ces outils ont une image d'infrastructure de developpement — donc de second rang par rapport aux vraies cibles de securite que sont les serveurs de production, les bases de donnees ou l'Active Directory.

Cette perception est fausse, et la CVE-2026-59774 sur Gitea l'illustre brutalement. Une forge Git bien exploitee par un attaquant peut donner acces a l'ensemble du code source d'une organisation, a tous ses secrets d'infrastructure, et potentiellement a ses environnements de production via les pipelines CI/CD. C'est souvent une cible plus rentable pour un attaquant sophistique que la compromission directe d'un serveur de production.

Les actions a mener ne sont pas exceptionnellement complexes ou couteuses. Mettre a jour regulierement, activer le MFA, scanner les secrets, monitorer les acces, isoler reseau. Ce sont des pratiques d'hygiene de securite standard — mais elles requierent de reconnaitre la forge Git comme ce qu'elle est : une infrastructure critique qui merite le meme niveau d'attention que le reste de votre SI sensible.