CVE-2026-60004 : comment un compte Gitea ordinaire plante un hook Git pour exécuter des commandes comme le service

Rapport CTI technique du 26 août 2026

Résumé exécutif

CISA a ajouté le 25 août 2026 la vulnérabilité CVE-2026-60004 à son catalogue Known Exploited Vulnerabilities, avec une échéance de correction fixée au 28 août pour les agences fédérales américaines. La faille touche Gitea, la plateforme de forge Git open source largement déployée en interne par des équipes DevOps, dans toutes les versions comprises entre 1.17 et 1.27.0. Elle permet à un utilisateur disposant d'un simple accès en écriture sur un dépôt, obtenu par une inscription libre sur une instance en configuration par défaut, d'installer un hook Git exécutable et de faire tourner des commandes shell sous l'identité du compte de service Gitea.

Le vecteur d'entrée est l'endpoint diffpatch, censé se contenter d'appliquer des patchs sur un dépôt. En soumettant deux fois le même patch contenant un fichier exécutable nommé hooks/post-index-change, un attaquant provoque une collision add/add que le mécanisme de fusion à trois voies de Git résout en écrivant le fichier litigieux directement dans le répertoire de hooks du clone temporaire nu utilisé par le serveur. Une preuve de concept publique, incluse dans l'avis GHSA-rcr6-4jqh-j84m publié par le mainteneur Gitea, exécute des commandes arbitraires et exfiltre leur sortie via des objets Git sans connexion sortante. Le correctif est disponible depuis la version 1.27.1, sortie fin juillet.

Chronologie

Date	Événement
Fin juillet 2026	Gitea publie la version 1.27.1 et l'avis GHSA-rcr6-4jqh-j84m documentant la faille et sa preuve de concept
28 juillet 2026	Publication de l'avis de sécurité par le mainteneur TheFox0x7, crédit du signalement à NightRang3r
Fin juillet 2026	The Hacker News publie une première couverture technique de la chaîne d'exploitation
25 août 2026	CISA ajoute CVE-2026-60004 au catalogue KEV, citant des preuves d'exploitation active
28 août 2026	Échéance de remédiation fixée par CISA pour les agences fédérales américaines

Fiche vulnérabilité (format fiche CTI)

CVE-2026-60004 | CVSS 3.1 : 9.8 (Critique) | Gitea 1.17 à 1.27.0

Vecteur CVSS : CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Classification CWE-94 (Improper Control of Generation of Code, injection de code). La faille réside dans services/repository/files/patch.go, où Gitea applique les patchs reçus via git apply --index --recount --cached --binary -3 sur un clone bare temporaire partagé. Comme ce clone est nu, sa racine correspond directement à $GIT_DIR : un fichier exécutable déposé au chemin hooks/post-index-change devient donc un hook Git actif, invoqué automatiquement par Git à chaque écriture d'index.

Conditions d'exploitation : Git 2.32 ou supérieur côté serveur (pour bénéficier du fallback three-way avec l'option -3), la route diffpatch activée (comportement par défaut), un système de fichiers temporaire à la fois inscriptible et exécutable. L'attaquant a besoin d'un accès en écriture ordinaire sur un dépôt, ce qui est trivial sur une instance à inscription ouverte : créer un compte, créer un dépôt privé, soumettre deux fois le même patch contenant le hook malveillant. Le code retour du hook n'est jamais renvoyé dans la réponse de diffpatch, ce qui rend l'exploitation silencieuse côté client HTTP ; la PoC contourne cette absence de canal de sortie en committant la sortie de la commande dans un objet Git puis en la récupérant via un fetch HTTP authentifié classique.

PoC disponible : oui, publiée par le mainteneur Gitea dans l'avis GHSA-rcr6-4jqh-j84m (script gitea_diffpatch_rce_poc.py), et une seconde implémentation est référencée sur le dépôt GitHub 0xBlackash/CVE-2026-60004. Patch/mitigation : mise à jour vers Gitea 1.27.1 ou supérieur. À défaut de mise à jour immédiate, désactiver l'inscription libre (DISABLE_REGISTRATION) réduit la surface au strict périmètre des comptes déjà provisionnés, mais ne corrige pas la faille pour un attaquant interne ou un compte déjà compromis.

Diagramme de la chaîne d'attaque

Chaîne d'exploitation CVE-2026-60004 : de l'inscription Gitea au shell sur le service
Chaîne d'exploitation reconstruite à partir de l'avis GHSA-rcr6-4jqh-j84m et de la preuve de concept publiée par Gitea.

Analyse technique

Étape 1 : obtention d'un accès en écriture

Sur une instance Gitea en configuration par défaut, l'inscription est ouverte. Un attaquant sans le moindre accès préalable crée un compte via /api/v1/user/repos après authentification basique, puis initialise un dépôt privé (auto_init: true). Aucune interaction avec un mainteneur ni aucune validation de pull request n'est nécessaire : le dépôt appartient entièrement à l'attaquant.

Étape 2 : construction du patch piégé

Le hook malveillant est un script shell POSIX classique, encodé comme le contenu d'un nouveau fichier hooks/post-index-change dans un diff au format git. La commande à exécuter est injectée telle quelle dans le corps du hook (/bin/sh -c "<commande>"), sa sortie combinée stdout/stderr étant redirigée vers un objet blob Git créé avec git hash-object.

Étape 3 : déclenchement de la collision add/add

Le patch est soumis deux fois d'affilée à POST /api/v1/repos/{owner}/{repo}/diffpatch. La première soumission ajoute le fichier normalement. La seconde crée un conflit add/add sur le même chemin : git apply -3 retombe alors sur une fusion à trois voies qui, pour résoudre le conflit, écrit le contenu du fichier directement sur le disque dans le répertoire hooks/ du clone bare, avec le bit exécutable positionné par le mode 100755 déclaré dans le patch.

Étape 4 : exécution et exfiltration sans canal sortant

Au prochain événement post-index-change du dépôt (déclenché par Git lui-même pendant l'opération), le hook s'exécute sous l'identité du compte de service Gitea. Comme la réponse HTTP de diffpatch ne relaie pas le code de retour du hook, la PoC fait écrire la sortie de la commande dans un nouvel objet commit local, référencé par une branche dédiée. L'attaquant récupère ensuite cette branche par un simple git fetch authentifié, sans jamais avoir besoin d'établir une connexion sortante depuis le serveur compromis.

Étape 5 : pivot post-exploitation

Une fois l'exécution de commande confirmée, l'accès au compte de service Gitea expose potentiellement app.ini et les secrets applicatifs qu'il contient, les variables d'environnement du processus, l'ensemble des dépôts montés sur le disque, les identifiants de connexion à la base de données, ainsi que les jetons OAuth et clés d'intégration configurés sur l'instance (CI/CD, webhooks, registries de conteneurs).

Indicateurs de compromission

Type	Valeur
Chemin de fichier suspect	Présence d'un fichier exécutable hooks/post-index-change dans un clone bare temporaire du répertoire de données Gitea
Pattern d'appel API	Deux requêtes POST /api/v1/repos/{owner}/{repo}/diffpatch consécutives portant un diff identique introduisant un fichier sous hooks/
Artefact Git	Commits ou branches créés hors du flux normal de l'utilisateur, référencés par un nom généré aléatoirement (schéma output-<hex> observé dans la PoC publique)
Comportement serveur	Exécution de processus enfants (/bin/sh) issus directement du processus Gitea au moment d'une opération d'indexation Git

Les IOC réseau spécifiques (IP ou domaines d'attaquants) n'ont pas été publiés par Gitea ni par CISA au moment de la rédaction ; l'exploitation documentée repose sur un vecteur applicatif local à l'instance plutôt que sur une infrastructure C2 identifiable.

MITRE ATT&CK

Tactique	Technique	ID	Justification
Initial Access	Valid Accounts	T1078	L'inscription ouverte permet d'obtenir des identifiants légitimes sur l'instance ciblée sans compromission préalable
Execution	Exploitation for Client Execution / Command and Scripting Interpreter	T1203 / T1059.004	Le hook shell planté est exécuté nativement par le serveur au moment d'une opération Git interne
Persistence	Server Software Component	T1505	Le hook post-index-change reste actif tant qu'il n'est pas supprimé du dépôt bare, constituant un point de persistance applicatif
Defense Evasion	Indicator Removal (via absence de canal de sortie observable)	T1070	L'exfiltration par objets Git plutôt que par réponse HTTP directe évite les journaux d'application classiques
Exfiltration	Exfiltration Over Alternative Protocol	T1048	La sortie de commande transite par le protocole Git natif (smart HTTP) plutôt que par un canal applicatif surveillé

Cette cartographie est une lecture technique construite à partir de l'avis GHSA-rcr6-4jqh-j84m et de la preuve de concept associée ; aucune cartographie ATT&CK officielle n'a été publiée par Gitea ou CISA pour cette CVE.

Remédiation : checklist opérationnelle

Mettre à jour toute instance Gitea vers la version 1.27.1 ou supérieure dès que possible, en priorité sur les instances exposées à Internet.
Vérifier dans les journaux applicatifs la présence de requêtes diffpatch dupliquées portant sur un chemin sous hooks/, remontant jusqu'à fin juillet 2026.
Auditer manuellement le contenu du répertoire hooks/ de chaque dépôt bare hébergé, à la recherche de fichiers exécutables non déployés par une procédure connue.
Désactiver l'inscription libre (DISABLE_REGISTRATION=true) sur les instances où elle n'est pas strictement nécessaire, en mesure compensatoire immédiate avant mise à jour.
Faire tourner les secrets exposés au compte de service Gitea (jetons d'intégration CI/CD, clés API stockées côté serveur, identifiants de base de données) si une exploitation antérieure au patch est suspectée.
Restreindre les permissions du compte OS exécutant Gitea au strict nécessaire (principe du moindre privilège), pour limiter l'impact d'une exécution de commande obtenue via ce vecteur.
Surveiller les processus enfants générés par le binaire Gitea en production via l'EDR ou l'auditd, en alertant sur tout appel /bin/sh non attendu dans ce contexte.