Gitea corrige une injection de code exploitée en 11 secondes sur les instances auto-hébergées
CVE-2026-60004, une injection de code critique dans Gitea, est exploitée dans la nature depuis le 25 août 2026 : un attaquant peut exécuter des commandes comme l’utilisateur système de la forge. Les instances auto-hébergées avec inscription ouverte sont les premières visées ; la correction tient en une mise à jour et une désactivation.
25 août 2026. CVE-2026-60004. 28 août. La CISA a inscrit au catalogue KEV une injection de code critique dans Gitea, la forge Git auto-hébergée écrite en Go, avec une exploitation confirmée dans la nature. Les agences fédérales américaines ont jusqu’au 28 août 2026 pour patcher. La faille permet à un attaquant disposant d’un simple accès en écriture à un dépôt d’exécuter des commandes arbitraires comme l’utilisateur système de la forge — et, inscription ouverte aidant, de le faire en quelques secondes, sans cible identifiée.
Ce que permet la faille
CVE-2026-60004 touche le point de terminaison diffpatch de Gitea. En abusant de ce point, un attaquant peut installer puis exécuter un hook Git à partir de contenu contrôlé par le dépôt. La conséquence, formulée par les mainteneurs eux-mêmes, est directe : « un attaquant avec un accès en écriture ordinaire à un dépôt peut exécuter des commandes shell arbitraires en tant qu’utilisateur système de Gitea ».
Le pire scénario est atteint quand l’inscription ouverte est activée. Un visiteur non authentifié s’inscrit, crée un dépôt, et déclenche la chaîne d’exploitation sans jamais avoir été invité. La vulnérabilité a été divulguée en privé aux mainteneurs, mais l’avis publié contenait un exploit de démonstration, ce qui a accéléré le passage à l’acte. Selon l’isolation du déploiement et les privilèges de l’utilisateur système, l’exploitation expose le fichier de configuration principal, les secrets d’environnement, les identifiants de base de données et les jetons OAuth d’intégration.
L’exploitation réelle, chronométrée
La première exploitation documentée vient d’un billet publié sur Habr par un développeur dont l’instance a été compromise. Son serveur tournait une version obsolète de Gitea, avec inscription ouverte et ni confirmation d’e-mail ni CAPTCHA. Un scanner automatisé s’est inscrit, a créé son propre dépôt et a déclenché l’exploit.
Le déroulé est saisissant : la partie active de l’attaque a duré environ 11 secondes. Le code a d’abord écrit une « preuve » d’exécution dans une branche Git, puis téléchargé un chargeur de shell universel, puis un dropper de type cryptomineur qui se battait pour le CPU. Comme Gitea tournait dans Docker sans privilèges, le processus malveillant n’a pas survécu au redémarrage, et aucune persistance n’a été trouvée — ni cron, ni systemd, ni clés SSH ajoutées.
Le fait que ce soit un mineur et non un voleur de code ne doit pas rassurer : c’est la signature d’un scan massif automatisé, pas d’une attaque ciblée. Le même chemin d’entrée, utilisé par un acteur patient, aurait exfiltré les dépôts avant de se faire repérer.
Pourquoi l’auto-hébergement aggrave la surface
Une forge auto-hébergée concentre trois risques que les offres managées absorbent à votre place. Premièrement, vous êtes votre propre équipe de correctifs : personne ne met à jour Gitea à votre place, et la version 1.27.1 qui corrige la faille est sortie fin juillet — un mois d’exposition pour qui n’a pas suivi. Deuxièmement, l’inscription ouverte est souvent laissée active « pour faciliter les contributions », alors qu’elle transforme une faille post-authentification en faille pré-authentification. Troisièmement, une forge contient par nature la chose la plus précieuse d’une équipe : le code source et les secrets qui l’accompagnent.
Cette faille n’est d’ailleurs pas un cas isolé : Gitea a déjà été au centre d’une lecture de fichier arbitraire transformable en RCE plus tôt dans l’année. Le rythme s’accélère à mesure que les forges auto-hébergées deviennent une cible standard des scanners.
L’ordre des actions
La correction ne se résume pas à un patch. L’ordre compte, car la faille a pu être exploitée avant que vous ne la découvriez :
- Mettre à jour vers Gitea 1.27.2, la dernière version (la 1.27.1 corrige déjà la faille, la 1.27.2 est recommandée).
- Désactiver l’inscription ouverte, ou au minimum imposer une confirmation d’e-mail et un CAPTCHA, et supprimer les méthodes d’inscription superflues.
- Faire tourner l’inventaire de compromission : la simple mise à jour ne chasse pas un accès déjà obtenu. Recherchez des hooks inattendus, des comptes récents et des branches anormales.
- Faire tourner tous les secrets : mots de passe de base de données, jetons OAuth, clés d’intégration, et tout ce que l’utilisateur système pouvait lire.
- Resserrer l’isolation : limiter les accès réseau sortants du conteneur, et ne jamais exposer la forge en frontal sans reverse proxy ni filtrage.
Forge managée contre forge auto-hébergée
Le choix d’héberger sa forge n’est pas qu’une affaire de prix ; c’est une affaire de qui porte la responsabilité des correctifs. Une forge managée applique les mises à jour dans les heures qui suivent une divulgation ; une forge auto-hébergée attend que son administrateur s’en charge. Dans le cas de CVE-2026-60004, la faille a été corrigée dans Gitea 1.27.1 fin juillet, mais l’exploitation documentée a touché une instance restée sur une version antérieure — cet écart d’un mois est le vrai facteur de risque.
L’écart se creuse encore sur l’exposition. Là où une offre managée impose un modèle de compte contrôlé, une forge auto-hébergée laisse souvent l’inscription ouverte active. C’est ce réglage, plus que la faille elle-même, qui a transformé un scan automatisé en compromission : sans lui, l’attaquant aurait eu besoin d’un compte légitime.
Que le payload soit un mineur plutôt qu’un exfiltreur est un signal en soi : l’attaquant automatisé monétise immédiatement, sans viser un dépôt précis. C’est la signature d’un marché de masse, où chaque instance exposée finit par être trouvée — ce qui rend le correctif d’autant plus urgent.
Après mise à jour, l’audit des hooks vaut la peine d’être scripté, car un hook malveillant déjà installé survit au correctif :
# Lister les hooks de dépôt non-échantillons (un hook inattendu = accès conservé)
find /var/lib/gitea/git/repositories -path '*/hooks/*' -type f \
! -name '*.sample' -exec ls -l {} \; 2>/dev/nullLa leçon tient en une phrase : auto-héberger ne dispense pas d’administrer. Une forge est un produit de sécurité comme un autre — avec des correctifs à suivre, des secrets à faire tourner et une surface à réduire.
Verdict
Si vous auto-hébergez Gitea, corrigez vers 1.27.2 aujourd’hui — la CISA a fixé l’échéance fédérale au 28 août, et un scanner automatisé n’attend pas. La mise à jour est l’étape minimale ; la vraie décision est de fermer l’inscription ouverte, car c’est elle qui transforme une faille de dépôt en porte d’entrée réseau.
Si vous exposez une forge à des contributeurs externes, ne comptez pas sur l’auto-hébergement nu : placez-la derrière une authentification externe (SSO), et considérez qu’un dépôt public sur une instance à inscription libre est une surface que vous ne contrôlez plus. Le coût d’un cryptomineur en 11 secondes est faible ; celui d’un exfiltration silencieuse des dépôts ne l’est pas.