Une faille critique de type zero-day dans Gogs corrigée, permettant l'exécution de code à distance sur des instances exposées sur Internet
Une faille critique d'injection d'arguments de type zero-day dans **Gogs**, le populaire service Git auto-hébergé, a été corrigée, permettant à des attaquants authentifiés d'exécuter du code à distance (RCE) et d'accéder à des dépôts privés. Découverte par **Rapid7**, la vulnérabilité affecte toutes les versions de **Gogs** jusqu'à 0.14.2 et 0.15.0+dev, représentant un risque important pour les instances exposées sur Internet avec des configurations par défaut.

**Gogs** a publié un correctif pour une faille critique de sécurité de type zero-day qui pourrait permettre à des attaquants de compromettre des instances exposées sur Internet et d'accéder à n'importe quel dépôt, y compris les dépôts privés. Cette vulnérabilité d'injection d'arguments, qui n'a pas encore reçu d'identifiant CVE, peut être exploitée par des attaquants authentifiés sans privilèges d'administrateur.
Les attaquants exploitant cette faille peuvent compromettre le serveur ciblé, lire des dépôts privés, voler des identifiants, se déplacer latéralement au sein du réseau et modifier le code source hébergé.
### Chemin d'exploitation
**Jonah Burgess**, chercheur en sécurité chez **Rapid7** qui a découvert et signalé la faille, a souligné qu'elle affecte tous les serveurs **Gogs** avec des configurations par défaut, malgré la nécessité de privilèges utilisateur de base pour l'exploitation.
« Étant donné que **Gogs** est livré avec l'enregistrement ouvert activé par défaut (DISABLE_REGISTRATION = false) et aucune limite sur la création de dépôts (MAX_CREATION_LIMIT = -1), un attaquant non authentifié peut simplement créer un compte et un dépôt sur n'importe quelle instance configurée par défaut », a averti **Burgess** deux semaines avant la publication du correctif.
Il a en outre expliqué : « Tout utilisateur enregistré qui crée un dépôt en est automatiquement le propriétaire. À partir de là, l'activation de la fusion par rebase est un simple basculement dans les paramètres, et toute la chaîne d'exploitation peut être opérée sans interaction d'aucun autre utilisateur. »
### Correctif et atténuation
Au cours du week-end, 10 jours après que **Rapid7** a divulgué publiquement la vulnérabilité en raison d'un manque de réponse aux multiples mises à jour de statut, les mainteneurs de **Gogs** ont publié la version 0.14.3 le 7 juin pour corriger cette faille et ont demandé un identifiant CVE.
**Rapid7** recommande vivement à tous les utilisateurs de **Gogs** de mettre à jour immédiatement. Le correctif a été implémenté via la pull request #8301.
Pour les utilisateurs ne pouvant pas patcher leurs instances **Gogs** immédiatement, **Rapid7** a partagé des mesures d'atténuation critiques :
* **Restreindre l'enregistrement des utilisateurs** : Définissez `DISABLE_REGISTRATION = true` dans `app.ini` pour empêcher les utilisateurs non fiables de créer des comptes. C'est la mesure d'atténuation la plus impactante, car l'exploit est autonome au sein du dépôt d'un seul utilisateur.
* **Restreindre la création de dépôts** : Définissez `MAX_CREATION_LIMIT = 0` dans `app.ini` pour empêcher les utilisateurs de créer leurs propres dépôts. Cela peut également être défini par utilisateur via « Max Repo Creation » dans le panneau d'administration. Bien que cela bloque le chemin d'attaque le plus simple, cela n'empêche pas l'exploitation par des utilisateurs ayant un accès en écriture à des dépôts existants.
* **Auditer les paramètres de rebase lors de la fusion** : Désactiver « Rebase before merging » par dépôt sous Settings > Advanced est une option, mais ce n'est pas une défense efficace contre un utilisateur malveillant qui possède ou a un accès administrateur à un dépôt, car il peut réactiver le rebase à volonté.
### Exposition généralisée
Écrit en Go et conçu comme une alternative à **GitHub Enterprise** ou **GitLab**, **Gogs** est fréquemment exposé en ligne en tant que plateforme de collaboration à distance.
Le chien de garde de la sécurité Internet **Shadowserver** suit actuellement plus de 2 300 serveurs **Gogs** exposés sur Internet, la majorité étant située en Asie (1 839) et en Europe (312). Séparément, **Shodan** répertorie un peu plus de 1 000 adresses IP avec une empreinte **Gogs**.

### Un schéma de failles
**Burgess** a noté que cette dernière faille est très similaire à d'autres vulnérabilités d'injection d'arguments que l'équipe de sécurité de **Gogs** a corrigées ces dernières années, notamment **CVE-2024-39933**, **CVE-2024-39932**, **CVE-2026-26194** et **CVE-2024-39930**. Cependant, cette nouvelle vulnérabilité affecte un chemin de code différent (`Merge()`) qui n'avait pas été traité auparavant.
Début décembre 2026, **Gogs** a corrigé une autre vulnérabilité RCE, **CVE-2025-8110**, après qu'elle a été activement exploitée dans des attaques zero-day pour compromettre des centaines de serveurs. Les chercheurs en sécurité de **Wiz**, qui ont signalé cette faille, ont déclaré : « Beaucoup de ces instances sont configurées avec 'Open Registration' activé par défaut, créant une surface d'attaque massive. »
Le 12 janvier 2026, **CISA** a confirmé que **CVE-2025-8110** était utilisé activement et l'a ajouté à son catalogue de vulnérabilités activement exploitées. **CISA** a ordonné aux agences du Federal Civilian Executive Branch (FCEB) de sécuriser leurs serveurs dans les trois semaines, avant le 2 février.
« Ce type de vulnérabilité est un vecteur d'attaque fréquent pour les acteurs cyber malveillants et pose des risques importants pour l'entreprise fédérale », a averti **CISA** à l'époque.