Les responsables de Gogs ont corrigé une faille de sécurité critique de type zero-day. Les attaquants peuvent l’exploiter pour compromettre des instances exposées sur Internet et accéder à tous les dépôts, y compris ceux qui sont 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 qui ne possèdent pas les privilèges d’administrateur. Toutes les versions de Gogs jusqu’à la 0.14.2 incluse et la 0.15.0+dev sont concernées.
Son exploitation permet de compromettre le serveur ciblé, de lire n’importe quel dépôt, de voler des identifiants, de se propager vers d’autres systèmes sur le réseau et de modifier le code source hébergé.
Bien que des privilèges utilisateur élémentaires soient nécessaires, le chercheur en sécurité Jonah Burgess de Rapid7 précise que tous les serveurs Gogs avec une configuration par défaut sont vulnérables.
Il a indiqué : « Gogs active par défaut l’inscription publique et n’impose aucune limite à la création de dépôts. Un attaquant non authentifié peut donc créer un compte et un dépôt sur toute instance configurée par défaut. Tout utilisateur inscrit qui crée un dépôt en devient automatiquement le propriétaire. Il suffit alors d’activer la fusion par rebase dans les paramètres pour que la chaîne d’exploitation fonctionne sans aucune interaction d’un autre utilisateur. »
Dix jours après la divulgation publique de la faille par Rapid7, faute de réponse à plusieurs demandes de mise à jour, les mainteneurs de Gogs ont publié la version 0.14.3 le 7 juin pour la corriger. Ils ont également demandé un identifiant CVE.
Burgess a ajouté : « Rapid7 recommande à tous les utilisateurs de Gogs de procéder à une mise à jour immédiate. »
La société a aussi partagé des mesures d’atténuation pour les utilisateurs qui ne peuvent pas appliquer le correctif tout de suite :
- Restreindre l’inscription des utilisateurs (DISABLE_REGISTRATION = true dans app.ini) pour empêcher des utilisateurs non fiables de créer des comptes. C’est la mesure la plus efficace car l’exploitation se confine au dépôt d’un seul utilisateur.
- Limiter la création de dépôts (MAX_CREATION_LIMIT = 0 dans app.ini) pour empêcher les utilisateurs de créer leurs propres dépôts. Ce paramètre peut aussi être défini par utilisateur via le panneau d’administration. Cela bloque la voie d’attaque la plus simple, mais n’empêche pas l’exploitation par des utilisateurs ayant un accès en écriture à des dépôts existants.
- Vérifier les paramètres de fusion par rebase : l’option « Rebase avant la fusion » peut être désactivée pour chaque dépôt, mais un utilisateur malveillant qui en est propriétaire peut la réactiver à tout moment.
Écrit en Go et conçu comme une alternative à GitHub Enterprise ou GitLab, Gogs est souvent exposé en ligne comme une plateforme de collaboration à distance.
L’organisme de veille Shadowserver recense plus de 2300 serveurs Gogs exposés sur Internet, la plupart en Asie (1839) et en Europe (312). L’outil Shodan liste un peu plus de 1000 adresses IP avec une empreinte Gogs.
Burgess a aussi précisé que cette faille ressemble beaucoup à 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, comme CVE-2024-39933, CVE-2024-39932, CVE-2026-26194 et CVE-2024-39930. Cependant, elle affecte un chemin de code différent (Merge()) qui n’avait jamais été traité.
Début décembre 2026, Gogs avait corrigé une autre vulnérabilité d’exécution de code à distance, CVE-2025-8110, après son exploitation en attaques zero-day qui ont compromis des centaines de serveurs.
Les chercheurs de Wiz, qui avaient signalé cette faille, avaient alors déclaré : « Beaucoup de ces instances sont configurées avec l’inscription publique activée par défaut, ce qui crée une surface d’attaque massive. »
Le 12 janvier, la Cybersecurity and Infrastructure Security Agency (CISA) a confirmé que CVE-2025-8110 était exploitée activement et l’a ajoutée à son catalogue des vulnérabilités exploitées. Elle a ordonné aux agences du pouvoir exécutif fédéral civil de sécuriser leurs serveurs en trois semaines, avant le 2 février.
La CISA avait averti : « Ce type de vulnérabilité est un vecteur d’attaque fréquent pour les acteurs malveillants et présente des risques significatifs pour le gouvernement fédéral. »