Gitea sous attaque : la RCE critique CVE-2026-60004 figure au catalogue KEV, plus de 8 300 serveurs exposés

Une faille critique dans le diffpatch de Gitea

La vulnérabilité CVE-2026-60004 affecte Gitea antérieure à la version 1.27.1 et permet l’exécution de code à distance via l’API diffpatch, avec l’installation d’un hook Git contrôlé par l’attaquant. Le bug a été signalé par le chercheur de Salesforce Shai Rod, comme le rapporte BleepingComputer.

Gitea a publié la version corrective 1.27.1 le 27 juillet. Bien que le correctif soit disponible depuis plusieurs semaines, la situation reste critique : Shadowserver a identifié 8 393 adresses IP vulnérables en date du 27 août 2026. Le titre de BleepingComputer fait état de plus de 8 300 serveurs exposés ; dans le corps de l’article, le nombre monte à près de 8 400. La donnée précise de Shadowserver, 8 393 IP, est celle de référence.

La CISA a inscrit la CVE au Known Exploited Vulnerabilities Catalog le 25 août 2026, avec une échéance pour les agences fédérales civiles américaines (FCEB) fixée au 28 août 2026, conformément à la Binding Operational Directive BOD 26-04.

Comment fonctionne techniquement l’attaque

La CVE-2026-60004 a un score CVSS 3.1 de 9,8, considéré comme critique, avec le vecteur AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H et la classification CWE-94 (Code Injection). L’avis GitHub GHSA-rcr6-4jqh-j84m décrit le mécanisme en détail.

Le fichier services/repository/files/patch.go applique des patchs contrôlés par l’attaquant dans un clone temporaire bare partagé. En envoyant deux fois le même patch, on génère une collision add/add. À ce moment-là, le repli à trois voies de Git extrait le chemin indexé même si l’opération se fait avec --cached.

Dans un clone bare, la racine du dépôt coïncide avec $GIT_DIR. Une entrée exécutable nommée hooks/post-index-change devient ainsi un hook Git actif. Git invoque ce hook pendant qu’il écrit l’index : le contenu contrôlé par le dépôt exécute des commandes arbitraires en tant qu’utilisateur système Gitea, généralement git. Dans l’avis, un résultat montre uid=1000(git) gid=1000(git) et un chemin temporaire sous /data/gitea/tmp/.

Un détail important : la valeur de retour du hook n’est pas propagée à la réponse diffpatch. La preuve de concept jointe enregistre la sortie de la commande dans des objets Git et crée une branche avec le résultat, de sorte qu’aucune connexion sortante n’est nécessaire. Le résultat est récupéré via le smart HTTP authentifié.

L’inscription ouverte n’est nécessaire que pour la voie d’attaque sans identifiants préexistants. Avec l’inscription ouverte par défaut, un visiteur non authentifié peut s’inscrire, créer un dépôt et obtenir l’accès en écriture nécessaire. Désactiver l’inscription ouverte bloque cette voie, mais le risque subsiste pour les utilisateurs disposant d’un accès en écriture aux dépôts. Le script fourni avec l’avis, gitea_diffpatch_rce_poc.py, utilise un compte Gitea déjà existant et doit être exécuté contre des instances de test où le compte peut créer des dépôts.

Exploitation active et recommandations de la CISA

L’inscription au catalogue KEV indique que la faille n’est pas théorique : elle est exploitée activement dans la nature. La CISA n’a pas encore fourni de détails sur les attaques, mais selon BleepingComputer, la décision aurait probablement été motivée par des signalements d’exploitation avec distribution de malware de cryptominage sur des serveurs Gitea non mis à jour.

Pour les agences fédérales américaines, la date limite pour appliquer les mesures d’atténuation était le 28 août 2026. L’action requise par la CISA est d’appliquer les mesures d’atténuation conformément aux instructions du fournisseur, en accord avec la BOD 26-04 « Prioritizing Security Updates Based on Risk » et les « Forensics Triage Requirements ». Pour les services cloud, il faut suivre le guide BOD 26-04 applicable ou mettre hors service le produit si les mesures d’atténuation ne sont pas disponibles. Les responsables doivent évaluer l’exposition internet de chaque actif et garantir la conformité aux lignes directrices BOD 26-04.

Un second problème critique : CVE-2026-20896

Ce n’est pas la première faille critique récente pour Gitea. En juillet, toujours selon BleepingComputer, des acteurs malveillants ont abusé de CVE-2026-20896, une autre vulnérabilité avec un CVSS de 9,8, cette fois dans l’image Docker officielle de Gitea.

La CVE-2026-20896 est classée CWE-284 (Improper Access Control). Les versions de l’image Docker jusqu’à la 1.26.2 incluse utilisent REVERSE_PROXY_TRUSTED_PROXIES=* comme paramètre par défaut. Cela permet à n’importe quelle adresse IP source d’usurper l’identité d’un utilisateur lorsque des en-têtes d’authentification de reverse proxy tels que X-WEBAUTH-USER sont activés. BleepingComputer la décrit comme un contournement d’authentification affectant les instances Gitea avec des en-têtes d’authentification via reverse proxy activés.

La fiche NVD n’indique pas de version corrigée explicite pour CVE-2026-20896. Il apparaît que les versions jusqu’à la 1.26.2 sont concernées. En l’absence d’autres indications, il est nécessaire de vérifier les mises à jour du fournisseur pour l’image Docker.

Que faire

Pour CVE-2026-60004, la seule correction indiquée est de mettre à jour Gitea vers la version 1.27.1 ou ultérieure. Aucun contournement officiel alternatif n’apparaît dans les sources consultées. Désactiver l’inscription ouverte réduit l’exposition à la voie sans identifiants préexistants, mais n’élimine pas le risque pour ceux qui disposent d’un accès en écriture aux dépôts.

Toute personne gérant une instance Gitea exposée sur Internet devrait vérifier immédiatement la version installée. Les données de Shadowserver, 8 393 IP vulnérables au 27 août, indiquent que des milliers de serveurs n’ont pas encore appliqué le correctif.

Pour CVE-2026-20896, il faut vérifier les mises à jour de l’image Docker officielle et, en attendant, contrôler la configuration de REVERSE_PROXY_TRUSTED_PROXIES et des en-têtes d’authentification de reverse proxy. La présence de deux vulnérabilités critiques en l’espace de quelques semaines fait de Gitea une cible concrète pour ceux qui recherchent des serveurs d’hébergement de code exposés.