Gitea est le genre de service qu’on installe une fois, qu’on oublie dans un coin et qui finit par héberger les clés de toute la maison. Une faille critique dans sa fonction diffpatch permet à un utilisateur capable d’écrire dans un dépôt de transformer un correctif en crochet Git exécutable. CVE-2026-60004 n’est pas une théorie de chercheur : elle permet de lancer des commandes sur le serveur avec les droits du compte qui fait tourner Gitea.
Le correctif existe déjà : Gitea 1.27.1. Le problème, c’est que la version corrigée est sortie le 27 juillet, classée dans les changements divers, alors que l’avis de sécurité officiel n’est arrivé que le 28. Si tu surveilles uniquement les lignes marquées « sécurité », tu pouvais très bien passer à côté.
Le dépôt qui devient un tremplin
L’avis GitHub de Gitea classe la vulnérabilité comme critique et lui attribue un score CVSS de 9,8. Elle touche les versions 1.17 et suivantes jusqu’à la 1.27.0 incluse ; la 1.27.1 est la première version annoncée comme corrigée. Le composant visé est la route diffpatch, utilisée pour appliquer des modifications à des fichiers d’un dépôt.
Le scénario repose sur un enchaînement très Git, donc très facile à sous-estimer. Gitea applique le correctif dans un clone temporaire bare, c’est-à-dire un dépôt sans espace de travail classique. Avec Git 2.32 ou plus récent, le traitement active aussi le mécanisme de fusion à trois sources. En envoyant deux fois un correctif qui provoque une collision, ce chemin peut extraire dans le dépôt un fichier qui ressemble à un crochet Git.
Visuel : logo officiel de Gitea, récupéré sur Wikimedia Commons depuis le fichier du projet. Source : https://commons.wikimedia.org/wiki/File:Gitea_Logo.svg
Quand un fichier hooks/post-index-change devient exécutable dans ce contexte, Git peut l’appeler pendant la mise à jour de l’index. Le serveur exécute alors le contenu avec les permissions du compte système Gitea. La réponse de diffpatch ne reflète pas forcément le résultat du crochet, ce qui rend la chaîne encore moins bruyante côté application.
Le mot « authentifié » ne doit pas rassurer
Le prérequis officiel est un accès en écriture à un dépôt. Ce n’est pas la même chose qu’un compte administrateur : un développeur, un prestataire ou un compte compromis peut suffire. Et si l’instance conserve l’inscription ouverte, un visiteur peut créer un compte normal, ouvrir son propre dépôt, puis atteindre le point d’entrée sans disposer de privilèges préexistants. Le score CVSS 9,8 de l’avis officiel reflète précisément cette combinaison : réseau, complexité faible, aucune interaction utilisateur et aucun privilège requis dans le scénario d’inscription ouverte.
Le crochet s’exécute avec les droits du processus Gitea, pas avec ceux d’un superutilisateur magique. Mais ces droits sont souvent trop généreux : fichier app.ini, secrets d’application, variables d’environnement, dépôts montés, accès à la base de données ou identifiants OAuth peuvent se trouver à portée. Dans un environnement mal isolé, la compromission du service devient aussi un problème pour les intégrations et les chaînes d’intégration continue qui lui font confiance.
Le correctif est sorti sans trompette
Gitea 1.27.1 a été publié le 27 juillet. Sa page de version place la modification concernée dans la section MISC, sous « refactor: git patch apply ». L’avis GHSA-rcr6-4jqh-j84m, publié le lendemain, précise ensuite la portée et donne le CVE-2026-60004. Le décalage n’est pas anodin : les équipes qui filtrent les notes de version sur le seul mot « sécurité » peuvent laisser une instance vulnérable en production.
La mesure à prendre est donc simple, et pas négociable : mettre à jour toutes les instances vers Gitea 1.27.1 ou une version ultérieure. Commence par les installations de test, les miroirs et les petites instances oubliées ; ce sont souvent elles qui gardent les vieilles versions et des jetons encore valables. Vérifie aussi que Git répond aux conditions du scénario, que le dossier temporaire est bien isolé et que le processus Gitea ne tourne pas avec des droits système inutiles.
En attendant la mise à jour, ferme l’inscription publique et réduis les droits d’écriture au strict nécessaire. Ce ne sont pas des correctifs : ils retirent seulement les chemins les plus faciles. Il faut aussi examiner les journaux Gitea et Git à la recherche d’utilisations inattendues de diffpatch, de créations de dépôts inhabituelles et de processus enfants lancés par le compte de service.
Une forge n’est pas qu’un joli endroit pour ranger du code
Cette faille rappelle une règle que l’auto-hébergement adore faire payer : un service de développement est une machine d’exécution déguisée. Gitea reçoit du code, applique des opérations Git, lance des tâches et parle à des bases, des registres et des systèmes d’intégration. Dès qu’une fonction « pratique » accepte du contenu contrôlé par un utilisateur, elle mérite le même niveau de méfiance qu’une interface d’administration.
Le deuxième enseignement concerne la surveillance des versions. Une correction de sécurité peut être rangée dans une rubrique générique, surtout quand elle prend la forme d’un durcissement ou d’une refactorisation. Il faut donc suivre les avis de sécurité du projet, les versions corrigées et les changements de code, pas seulement les titres accrocheurs des notes de version.
Gitea 1.27.1 est disponible. Installe-la avant que ton dépôt ne découvre une nouvelle vocation : servir de terminal distant à quelqu’un d’autre.
Sources
Avis de sécurité officiel Gitea/GitHub — CVE-2026-60004, portée, versions affectées et conditions d’exploitation : https://github.com/go-gitea/gitea/security/advisories/GHSA-rcr6-4jqh-j84m
Version Gitea 1.27.1 — publication et correctif diffpatch listé dans les changements : https://github.com/go-gitea/gitea/releases/tag/v1.27.1
Wikimedia Commons — logo Gitea, source du visuel documentaire inline et licence MIT indiquée sur la page : https://commons.wikimedia.org/wiki/File:Gitea_Logo.svg
—
Recherche, relecture et illustration assistées par IA. Le contenu reflète le travail éditorial de la rédaction.
No comments yet