,

Forgejo 16.0.4 et 15.0.8 corrigent une faille RCE critique dans les modèles de dépôt

Padlock on a computer circuit board, illustrating a critical security patch for a self-hosted Git service like Forgejo

Forgejo a publié dans l’urgence les versions 16.0.4 et 15.0.8 le 10 septembre 2026, refermant une faille critique d’exécution de code à distance dans la fonctionnalité qui crée un nouveau dépôt à partir d’un modèle. Le projet a annoncé les deux versions sur son dépôt officiel Codeberg ainsi que sur son compte Fediverse, qualifiant le correctif de critique. Toute instance auto-hébergée tournant en 16.0.3 ou antérieure sur la branche stable, ou en 15.0.7 ou antérieure sur la branche LTS, est vulnérable et doit être mise à jour sans délai.

Ce qui a été corrigé

Les notes de version listent deux correctifs de sécurité. Le premier est une faille critique d’exécution de code à distance, référencée CVE-2026-89094 et notée 9,9 sur 10 sur l’échelle CVSS, tout juste en dessous du score maximal. Le second est un contournement d’autorisation plus circonscrit, touchant l’API. Les deux problèmes sont résolus dans la 16.0.4, la version stable actuelle, et rétroportés vers la 15.0.8, la branche LTS qui ne reçoit que des mises à jour de sécurité.

Comment fonctionne la RCE via les modèles de dépôt

Forgejo permet à tout utilisateur disposant du droit de créer des dépôts de générer un nouveau dépôt à partir d’un modèle existant, une fonctionnalité pratique qui, sur de nombreuses instances, est accessible à n’importe quel compte enregistré et pas seulement aux administrateurs. La création d’un dépôt depuis un modèle déroule quatre étapes en coulisses :

  1. Cloner le dépôt modèle.
  2. Supprimer le dossier .git de la copie clonée.
  3. Développer les variables de modèle trouvées dans les fichiers sous le chemin .forgejo/template.
  4. Exécuter git init pour transformer le résultat en un dépôt neuf.

C’est l’étape de développement des variables qui abrite la faille. Un modèle malveillant peut être construit de façon à ce que le développement de ses variables recrée un dossier .git complet, sous-dossier hooks compris, avec des scripts exécutables à l’intérieur. Quand Forgejo exécute ensuite git init, Git trouve ce dossier .git déjà en place et l’adopte au lieu d’en créer un propre. Les scripts hooks deviennent alors actifs et s’exécutent avec les privilèges du compte de service Forgejo dès qu’une action Git correspondante se déclenche. Un modèle piégé peut ainsi obtenir une exécution de code à distance dès qu’un utilisateur s’en sert pour créer un dépôt.

Le correctif est ciblé : Forgejo supprime désormais tout dossier .git qui réapparaît après le développement des variables, avant que git init ne s’exécute. Cela ferme la voie qu’un attaquant aurait dû emprunter pour déposer des hooks sur le serveur.

Second correctif : contournement de permissions sur l’API

Les mêmes versions corrigent également une faille d’autorisation dans l’API de Forgejo. Forgejo dispose d’un contrôle de permission qui autorise les mainteneurs d’un dépôt à modifier des branches qui ne leur appartiennent pas, lorsqu’une pull request a l’option « autoriser les modifications par les mainteneurs » activée. Ce contrôle ne tenait pas compte des restrictions propres à l’API, notamment les jetons d’accès limités à un dépôt. Un jeton volontairement restreint à des permissions étroites et cantonnées à un dépôt pouvait donc servir à effectuer des modifications en dehors de ce périmètre, ce qui annule l’intérêt même de limiter la portée du jeton.

Qui est concerné, et que faire

Les versions 16.0.3 et antérieures sur la branche stable, ainsi que 15.0.7 et antérieures sur la branche LTS, sont toutes deux vulnérables. Les correctifs sont livrés en 16.0.4 (stable) et 15.0.8 (LTS). Déclencher la faille ne nécessite pas de droits administrateur : si les utilisateurs ordinaires de votre instance peuvent créer des dépôts à partir de modèles, le comportement par défaut sur de nombreuses installations auto-hébergées, traitez cette mise à jour comme une urgence du jour et non comme une tâche pour la prochaine fenêtre de maintenance planifiée.

Forgejo est né en 2022 sous la forme d’un fork communautaire de Gitea, et les deux projets sont souvent cités ensemble. Sur ce point précis, pourtant, le code vulnérable appartient bien à Forgejo : la convention .forgejo/template utilisée lors du développement des variables n’existe pas dans la base de code de Gitea. Les notes de version récentes de Gitea ne mentionnent aucun correctif correspondant, et rien ne confirme à ce jour que Gitea partage cette faille précise. Si vous utilisez Gitea plutôt que Forgejo, il n’y a rien à faire suite à cet avis en particulier, même si maintenir à jour n’importe quelle plateforme d’hébergement Git reste toujours une bonne pratique.

Récupérer la mise à jour

Forgejo 16.0.4 et 15.0.8 sont disponibles dès maintenant sur la page officielle des releases du projet sur Codeberg, ainsi que via forgejo.org. Comme pour toute release de sécurité, sauvegardez votre instance avant de mettre à jour, et vérifiez le changelog complet pour tout autre changement inclus dans cette mise à jour.

selfhostlab.io avait couvert le passage de Forgejo à la version 16.0 en juillet dernier, notamment le durcissement SSRF et les changements de notifications de cette version. Cet article vaut le détour pour comprendre ce qui a changé depuis, maintenant que ce correctif de sécurité vient s’y ajouter.

Related guides