CVE-2026-60004 : RCE critique de Gitea exploitée pour déployer des charges utiles semblables à des mineurs

Une vulnérabilité critique d’exécution de code à distance dans Gitea est passée de la divulgation à une exploitation active moins d’un mois après qu’un correctif est devenu disponible. Suivi comme CVE-2026-60004 et noté 9,8 sur l’échelle CVSS, le défaut permet à un attaquant avec un accès en écriture ordinaire au dépôt d’insérer un hook Git exécutable et de lancer des commandes shell arbitraires avec les privilèges du compte de service Gitea.

Le 25 août 2026, l’Agence américaine de cybersécurité et de sécurité des infrastructures (CISA) a ajouté la vulnérabilité exploitée Gitea à son catalogue des vulnérabilités exploitées connues (KEV), confirmant que des attaques se produisent dans la nature. Les agences civiles fédérales ont reçu l’instruction de remédier aux installations affectées avant le 28 août 2026.

Le problème devient particulièrement dangereux car Gitea permet l’inscription ouverte par défaut. Bien que l’exploitation nécessite techniquement un compte authentifié avec des permissions d’écriture sur le dépôt, un attaquant externe pourrait être en mesure de créer un compte, de créer un dépôt et d’obtenir ces privilèges sans posséder de justificatifs antérieurement volés.

Une attaque publiquement signalée contre un serveur vulnérable a abouti au déploiement d’un dropper présentant un comportement de minage de cryptomonnaie. L’incident souligne pourquoi le RCE critique de Gitea exploité activement à l’état sauvage devrait être traité comme une priorité urgente de remédiation pour l’infrastructure de développement auto-hébergée exposée à internet.

Analyse CVE-2026-60004

La vulnérabilité est classée comme CWE-94, Contrôle inadéquat de la génération de code, et réside dans la fonctionnalité diffpatch de Gitea. Le point de terminaison API affecté applique des correctifs fournis par l’utilisateur dans un dépôt Git temporaire. Dans des conditions vulnérables, un attaquant peut manipuler ce processus de sorte que le contenu contrôlé par le dépôt devienne un hook Git exécutable plutôt qu’un fichier de dépôt ordinaire.

Les détails importants pour CVE-2026-60004 se concentrent sur la manière dont Gitea a créé le dépôt temporaire utilisé pour traiter les correctifs. Les versions vulnérables utilisaient un clone Git nu, où le répertoire du dépôt agit lui-même comme répertoire de données interne de Git. Combiné avec le comportement de traitement des correctifs de Git, le contenu de dépôt spécialement construit pourrait donc atteindre le répertoire des hooks et devenir exécutable.

Un attaquant avec accès en écriture peut soumettre un contenu de correctif malveillant à l’API diffpatch. En déclenchant une condition de correctif conflictuelle, le traitement à trois voies de Git peut amener un fichier exécutable contrôlé par l’attaquant à être matérialisé en tant que hook post-changement d’index. Git exécute ensuite ce hook lors des opérations de dépôt, résultant en l’exécution de commande en tant que compte système opérant Gitea.

CVE-2026-60004 affecte les versions 1.17 et ultérieures de Gitea avant la version 1.27.1. Gitea 1.27.1, publié le 27 juillet 2026, corrige le problème en modifiant le clone temporaire affecté d’un dépôt nu à un dépôt non-nu, empêchant les chemins contrôlés par l’attaquant d’être interprétés comme des hooks Git exécutables de la même manière.

Le succès de l’exploitation nécessite un accès en écriture au dépôt. Cependant, les paramètres d’installation par défaut de Gitea affaiblissent considérablement cette condition préalable : l’inscription est généralement activée, les utilisateurs n’ont pas nécessairement besoin de l’approbation d’un administrateur ou de la vérification par email, et les utilisateurs nouvellement inscrits peuvent créer des dépôts. Un attaquant ciblant une installation inchangée exposée à internet pourrait donc être en mesure de satisfaire les permissions requises simplement en créant un nouveau compte.

Des conditions d’exploitation supplémentaires identifiées dans la recherche technique comprennent une version côté serveur de Git prenant en charge le comportement de repli à trois voies pertinent, l’accès au point de terminaison diffpatch, et un système de fichiers temporaire où le service Gitea peut écrire et exécuter des fichiers. Ces exigences signifient que chaque installation vulnérable ne sera pas nécessairement exploitable via exactement la même chaîne, mais les configurations par défaut peuvent fournir un chemin pratique.

Une fois que des commandes arbitraires s’exécutent sous le compte de service Gitea, l’impact s’étend bien au-delà d’un seul dépôt. En fonction de la configuration de l’environnement, un attaquant peut accéder à des dépôts privés, des identifiants de base de données, des secrets OAuth, des configurations d’application, des variables d’environnement, des identifiants CI/CD, des registres de paquets, ou des services internes accessibles depuis l’hôte Gitea.

Pour les organisations utilisant Gitea dans le cadre des flux de développement et de déploiement de logiciels, cela crée également un risque potentiel pour la chaîne d’approvisionnement. Le compromis d’une plate-forme de gestion de code-source peut exposer le code propriétaire et les secrets de déploiement et peut fournir des opportunités de modifier des dépôts ou d’utiliser des justificatifs volés pour se propager dans l’infrastructure CI/CD et de production.

Le chercheur en sécurité Shai Rod, également connu sous le nom de NightRang3r, a découvert et signalé la vulnérabilité. Gitea a publié la version 1.27.1 le 27 juillet, suivie de l’avis de sécurité officiel le 28 juillet. Initialement, aucun rapport d’exploitation confirmée n’avait été reçu, mais cela a changé lorsque la CISA l’a ajouté au catalogue KEV le 25 août.

Une preuve de concept publique CVE-2026-60004 est disponible depuis la divulgation de la vulnérabilité, réduisant considérablement l’effort nécessaire pour comprendre et reproduire la technique d’attaque sous-jacente. Les outils de sécurité publics ont également ajouté des modèles de détection pour les instances vulnérables, augmentant la probabilité que les attaquants puissent identifier des serveurs exposés à grande échelle.

The Hacker News a également documenté un incident réel impliquant un serveur Gitea exposé à internet avec l’enregistrement ouvert activé. Selon l’administrateur, l’attaquant a atteint le service vulnérable via HTTPS, créé les conditions nécessaires à l’exploitation, et exécuté un dropper qui consommait des ressources CPU substantielles.

Le dropper a effacé certaines variables d’environnement liées aux bibliothèques, recherché des processus consommant des ressources CPU importantes, tenté de mettre fin à des processus concurrents, téléchargé une charge utile correspondant à l’architecture de l’hôte, l’a exécuté, et ensuite supprimé le fichier téléchargé. L’administrateur n’a pas récupéré suffisamment de preuves pour identifier un mineur de cryptomonnaie spécifique, un portefeuille, un pool minier, ou un acteur de la menace, de sorte que la charge utile doit actuellement être décrite comme ressemblant à un mineur plutôt que d’être attribuée de manière définitive à une famille de cryptojacking connue.

Il reste incertain si cette attaque spécifique a poussé la CISA à ajouter la vulnérabilité à KEV ou si l’agence a observé des campagnes d’exploitation distinctes. Ni la CISA ni les deux rapports cités n’ont publiquement attribué l’activité plus vaste à un acteur de menace connu.

Aucun ensemble autoritaire d’IOC pour la campagne CVE-2026-60004 n’a été publié. Les défenseurs devraient donc s’appuyer sur des preuves comportementales telles que la création de comptes suspects, des appels inhabituels à l’API diffpatch, des hooks Git inattendus, des processus lancés par le service Gitea, et une activité CPU ou réseau sortante anormale.

Atténuation de CVE-2026-60004

Les organisations exécutant Gitea auto-hébergé doivent immédiatement passer à la version 1.27.1 ou ultérieure. Les environnements Gitea Cloud devaient recevoir automatiquement la mise à jour, tandis que les administrateurs des installations auto-gérées sont responsables de l’application de la version corrigée par eux-mêmes.

Parce que l’exploitation est maintenant confirmée dans la nature, le patching ne doit pas être retardé jusqu’à la prochaine fenêtre de maintenance de routine. L’inclusion KEV de CISA fournit des preuves fortes que la vulnérabilité présente un risque opérationnel immédiat, avec des agences civiles fédérales américaines requises de remédier d’ici le 28 août 2026.

Les organisations incapables de patcher immédiatement devraient désactiver l’enregistrement public là où il n’est pas requis. Le fait de régler l’enregistrement en mode contrôlé par l’administrateur empêche un utilisateur Internet non authentifié de simplement créer un compte et un dépôt pour obtenir l’accès en écriture nécessaire à l’exploit. Cette mesure réduit l’exposition mais ne corrige pas la vulnérabilité car les utilisateurs existants avec des permissions d’écriture sur le dépôt peuvent encore accéder à la fonctionnalité vulnérable.

Les administrateurs devraient également restreindre la création de dépôts et les permissions d’écriture, réduire l’accès externe à Gitea si possible, et éviter d’exposer l’infrastructure de développement directement à internet sauf s’il y a une nécessité commerciale claire.

La détection de CVE-2026-60004 devrait commencer par l’identification de toutes les installations Gitea, vérifiant leurs versions exactes, et déterminant si l’enregistrement public était activé pendant que le serveur fonctionnait avec une version affectée. Les instances exposées à internet qui ont autorisé des visiteurs anonymes à enregistrer des comptes méritent la plus haute priorité d’enquête.

Pour détecter les tentatives d’exploitation de CVE-2026-60004 et l’activité post-compromission, les défenseurs devraient examiner les télémetries Gitea, API, système d’exploitation, et réseau pour :

• – Requêtes répétées ou inattendues à /api/v1/repos/{owner}/{repo}/diffpatch
• – Comptes nouvellement créés suivis rapidement par la création de dépôts et opérations de correctifs
• – Shells ou processus inconnus lancés par le compte de service Gitea
• – Utilisation soutenue et inhabituelle du CPU sur les hôtes Gitea
• – Téléchargements ou exécutions inattendues à partir de répertoires temporaires
• – Nouvelles connexions sortantes originaires de Gitea ou de ses processus enfants
• – Modifications de dépôts non autorisées
• – Accès inattendu à la configuration de l’application, aux identifiants, ou aux secrets

La présence de ces comportements ne prouve pas de manière indépendante une exploitation, mais des combinaisons telles que l’enregistrement d’un nouveau compte suivi de la création de dépôt, des requêtes diffpatch, et de nouveaux processus enfants devraient faire l’objet d’une enquête urgente.

Les administrateurs devraient également revoir les comptes créés pendant que la version vulnérable était exposée. Les utilisateurs inconnus, les dépôts créés peu après l’enregistrement, et les comptes qui ont immédiatement effectué des opérations API peuvent aider à identifier les tentatives d’exploitation survenues avant que le serveur ne soit corrigé.

Le processus d’atténuation CVE-2026-60004 devrait aller au-delà de l’installation de la version 1.27.1 si un compromis est soupçonné. Parce que l’exploitation réussie permet l’exécution de code avec les privilèges de l’utilisateur du système d’exploitation de Gitea, les équipes de sécurité devraient traiter l’hôte affecté comme potentiellement compromis et enquêter sur les secrets accessibles et les systèmes connectés.

Les intervenants d’incidents devraient faire tourner les identifiants de base de données, les jetons OAuth et API, les secrets CI/CD, les clés SSH, les identifiants de déploiement, et d’autres matériels sensibles accessibles à Gitea lorsqu’il semble qu’une exécution de code arbitraire est survenue. Les dépôts privés devraient également être examinés pour des changements non autorisés, et les systèmes de construction ou de déploiement connectés devraient être examinés pour des mouvements latéraux.

CVE-2026-60004 démontre comment une vulnérabilité dans l’infrastructure de développement peut évoluer rapidement d’un bug logiciel à un chemin de compromis actif. Avec les informations d’exploitation publique disponibles et une exploitation confirmée en cours, les organisations exécutant des instances auto-hébergées vulnérables de Gitea devraient prioriser à la fois le patching et la chasse aux menaces rétrospective.

Contacter le service commercial