Le Git auto-hébergé prouve son prix de souveraineté

Onze secondes ont suffi

CVE-2026-60004 est une faille d'injection de code dans Gitea, l'alternative auto-hébergée à GitHub utilisée par les équipes qui préfèrent garder leur code source sur leurs propres serveurs plutôt que sur une plateforme américaine. Le chercheur Shai Rod, connu sous le nom de NightRang3r, a découvert qu'un attaquant disposant d'un simple accès en écriture à un dépôt pouvait envoyer un correctif malveillant au point de terminaison API diffpatch de Gitea, planter un hook Git exécutable et exécuter des commandes shell arbitraires en tant que compte de service Gitea. Avec l'inscription ouverte activée par défaut chez Gitea, cet accès ne demande rien de plus qu'une inscription en tant qu'utilisateur normal.

Lors d'une attaque documentée, un hébergeur a signalé une activité inhabituelle sur une instance Gitea obsolète. Un attaquant avait créé un compte, créé un dépôt, déclenché la chaîne d'exploitation, écrit une preuve de concept dans une branche Git, téléchargé un chargeur shell et installé un logiciel de minage de cryptomonnaie qui a consommé 70 pour cent de la capacité de traitement du serveur, le tout en environ onze secondes. Aucun mécanisme de persistance n'a été installé; la charge utile a disparu au redémarrage suivant du conteneur, mais la fenêtre d'exposition ne s'est refermée que parce que quelqu'un surveillait.

La chronologie qui devrait inquiéter tout auto-hébergeur

Ce qui fait de ce cas un avertissement plutôt qu'une nouvelle de correctif ordinaire, c'est le peu de temps qui a séparé la disponibilité d'un correctif de son exploitation réelle à grande échelle.

Moins d'un mois s'est écoulé entre un correctif public et une exploitation confirmée, et les instances encore touchées étaient précisément celles qui n'avaient pas appliqué un correctif public depuis des semaines. La fenêtre de trois jours accordée par la CISA aux agences fédérales n'est pas une formalité administrative; elle reflète la vitesse à laquelle une faille connue et corrigée devient une arme active dès que les attaquants remarquent que des cibles non corrigées existent encore.

Pourquoi l'Europe a choisi ce type d'outils en premier lieu

Gitea n'est pas devenu populaire dans les organisations européennes par hasard. Sous la pression de NIS2, des règles de résidence des données et d'une volonté plus large de réduire la dépendance aux plateformes cloud de propriété américaine, de nombreuses entreprises de taille moyenne et organismes publics de l'UE ont choisi le Git auto-hébergé précisément pour que leur code source, leurs identifiants et leurs pipelines CI ne touchent jamais GitHub, Microsoft ou un autre service contrôlé par les États-Unis. C'est une décision de souveraineté légitime et souvent bien justifiée, et rien dans cette vulnérabilité ne change la logique sous-jacente qui consiste à vouloir son propre code sur une infrastructure que l'on contrôle.

Ce qui change, c'est le prix attaché à cette décision. Une plateforme gérée absorbe la surveillance des correctifs, le durcissement des configurations par défaut et la réponse aux incidents dans le cadre de ce que paie un client. Une instance auto-hébergée reporte tout cela sur l'équipe interne qui l'a mise en place, souvent des années auparavant, parfois sans qu'il ne reste personne pour se souvenir si l'inscription ouverte a un jour été désactivée.

La facture de la souveraineté se paie dans les fenêtres de correctif

La solution pratique ici n'est pas d'abandonner l'auto-hébergement. La propre recommandation de Gitea pour cette faille est concrète et immédiate: désactiver l'inscription ouverte en réglant DISABLE_REGISTRATION sur true, exiger une confirmation par courriel pour toute création de compte qui resterait ouverte, désactiver l'inscription OpenID si elle n'est pas utilisée activement, et exiger une authentification avant de laisser quiconque parcourir les pages ou appeler l'API. Toute organisation utilisant Gitea, ou une plateforme auto-hébergée comparable, devrait vérifier ces quatre paramètres dès aujourd'hui, et non après le prochain CVE.

La leçon plus large porte sur la façon dont les décisions de souveraineté sont budgétées. Choisir l'auto-hébergement pour des raisons de résidence des données ou d'indépendance est une décision réelle et défendable, mais elle n'est complète que si elle s'accompagne d'un engagement envers le travail de sécurité opérationnelle continu qu'un fournisseur géré aurait autrement assumé automatiquement. Un correctif resté inappliqué pendant un mois sur une instance exposée à internet avec inscription ouverte n'est pas un échec de la décision de souveraineté; c'est un échec à chiffrer ce que cette décision coûte réellement à exploiter en toute sécurité.

À lire ensuite: Le NCSC impose l'arrêt d'urgence des agents IA  |  Si vous utilisez Zimbra, le 21 août a tout changé