veilletech.fr
26 août Feed du jour
#02 SÉCURITÉ Faille

Gitea : la faille diffpatch est exploitée

Une forge auto-hébergée, c'est aussi un serveur à patcher.

CVE-2026-60004 entre au catalogue KEV de la CISA sur preuve d'exploitation active. Le point d'entrée diffpatch de Gitea permet d'installer un hook Git exécutable en soumettant deux fois le même patch, et d'exécuter des commandes shell sous le compte de service. Toutes les versions de 1.17 à 1.27.0 sont concernées.

3 min de lecturevidéo 1:17
Partager
Sommaire5 sections
  1. Ce qui se passe
  2. Le mécanisme
  3. Pourquoi ça compte
  4. Ce qu'il faut faire
  5. À retenir

Ce qui se passe

La CISA a ajouté CVE-2026-60004 à son catalogue KEV (Known Exploited Vulnerabilities), celui qui ne liste que les failles dont l'exploitation active est constatée. Il s'agit d'une injection de code (CWE-94) dans Gitea, la forge Git auto-hébergée.

L'avis amont, GHSA-rcr6-4jqh-j84m, était publié le 28 juillet 2026 et classé critique. Toutes les versions de 1.17 à 1.27.0 sont affectées ; le correctif est en 1.27.1. La CISA avait fixé au 28 août l'échéance de remédiation pour les agences fédérales américaines — un bon indicateur du sérieux accordé.

Le mécanisme

Le point d'entrée diffpatch de l'API applique un patch fourni par l'utilisateur dans un clone temporaire, via git apply :

Go
cmdApply := gitcmd.NewCommand("apply", "--index", "--recount", "--cached", "--binary")
if git.DefaultFeatures().CheckVersionAtLeast("2.32") {
    cmdApply.AddArguments("-3")
}

L'option --cached est censée n'écrire que dans l'index, jamais sur le disque. Le piège est dans -3, le repli en fusion à trois points activé depuis Git 2.32.

Si l'attaquant soumet deux fois le même patch, la seconde application provoque une collision add/add. Git bascule alors sur sa fusion à trois points, et celle-ci écrit le fichier sur le disque malgré --cached. Or le clone temporaire est un dépôt nu : sa racine est $GIT_DIR. Un fichier nommé hooks/post-index-change n'y est donc pas un fichier ordinaire, c'est un hook Git — et Git l'invoque lui-même en écrivant l'index.

hooks/post-index--changegit apply--cached -3API Gitea(diffpatch)Attaquanthooks/post-index--changegit apply--cached -3API Gitea(diffpatch)Attaquantla racine du dépôt nu est $GIT_DIRle fichier devient un hookpatch n°1 (fichier exécutable)application dans le clone nule MÊME patch, une secondefoiscollision add/add → replifusion 3 pointsécriture sur disque malgré--cachedinvocation à l'écriture del'indexcommandes exécutées sous le compte de service

Le retour du hook n'est pas propagé à la réponse diffpatch : la preuve de concept publiée stocke la sortie de la commande dans des objets Git et crée une branche contenant le résultat, récupérée ensuite en HTTP authentifié. Aucune connexion sortante n'est nécessaire, ce qui rend la détection réseau inutile.

Pourquoi ça compte

Le prérequis annoncé est « un accès en écriture ordinaire à un dépôt ». Cela paraît restrictif, ça ne l'est pas : avec l'inscription ouverte, qui est le réglage par défaut, un visiteur non authentifié crée un compte, crée un dépôt, et dispose de cet accès.

L'exécution a lieu sous le compte système de Gitea — celui qui possède tous les dépôts de l'instance.

Ce qu'il faut faire

  1. Passer en Gitea 1.27.1 ou plus récent.
  2. Fermer l'inscription libre (ENABLE_OPEN_ID_SIGN_IN, DISABLE_REGISTRATION) si vous ne l'utilisez pas — c'est ce qui transforme « utilisateur de confiance » en « n'importe qui ».
  3. Chercher les traces : un fichier sous hooks/ dans les dépôts, des branches inattendues, des processus lancés par l'utilisateur de service.

Trois conditions sont nécessaires au déclenchement : Git ≥ 2.32, la route diffpatch active, et un espace temporaire monté sans noexec. Une instance récente les remplit toutes les trois.

À retenir

Un dépôt nu n'a pas de répertoire de travail : ce qu'on croit écrire « dans le dépôt » s'écrit à côté de la configuration et des hooks. Toute manipulation de contenu utilisateur dans un clone nu mérite d'être relue avec cette idée en tête.

Source : CISA