En bref

  • CVE-2026-60004 (CVSS 9.8) : injection de code dans le mécanisme diffpatch de Gitea permettant une RCE avec les privilèges du compte de service
  • Toutes les instances Gitea antérieures à la version 1.27.1 sont vulnérables — l'inscription ouverte (configuration par défaut) amplifie la surface d'attaque
  • Patcher immédiatement vers Gitea 1.27.1 — la CISA exigeait une remédiation avant le 28 août 2026 pour les agences fédérales américaines

Les faits

Le 25 août 2026, la CISA a ajouté CVE-2026-60004 à son catalogue Known Exploited Vulnerabilities (KEV), confirmant l'exploitation active dans la nature. La vulnérabilité affecte Gitea dans toutes ses versions antérieures à 1.27.1. La deadline imposée aux agences civiles fédérales américaines (FCEB) était le 28 août 2026 — 72 heures seulement, signe de l'urgence absolue.

CVE-2026-60004 tire son origine d'une injection de code dans la fonctionnalité diffpatch de Gitea. Lorsqu'un utilisateur authentifié soumet un fichier patch contenant un hook Git malveillant, le serveur l'exécute sans validation suffisante, avec les privilèges du compte de service Gitea. Les métriques CVSS v3.1 sont explicites : vecteur réseau (AV:N), complexité faible (AC:L), privilèges bas requis (PR:L), sans interaction utilisateur (UI:N), impact total (C:H/I:H/A:H). Score final : 9.8 — parmi les CVE les plus critiques de 2026.

Ce qui aggrave la surface d'attaque : Gitea active l'inscription ouverte par défaut. Un attaquant externe peut créer un compte, créer un dépôt, y déposer un patch forgé et obtenir un shell sur le serveur en quelques minutes, sans intervention d'un administrateur. Cette combinaison inscription ouverte + RCE faible complexité est particulièrement dangereuse.

La chronologie révèle la réalité du patch management actuel. Gitea a publié la version 1.27.1 le 27 juillet 2026, avec l'advisory de sécurité formel le 28 juillet. En moins d'un mois, des exploits fonctionnels ont émergé. Les premiers incidents documentés — rapportés sur la plateforme Habr — montrent des attaquants ayant déployé des cryptomineurs après exploitation, avec exfiltration parallèle de tokens d'accès cloud stockés dans les pipelines CI/CD.

D'après Help Net Security (26 août 2026), des scans massifs ciblant les instances Gitea exposées ont précédé les exploitations. SOC Prime a documenté que les payloads observés incluent principalement des cryptomineurs, mais les analystes soulignent que le même vecteur peut être réorienté vers du ransomware ou l'injection de code dans les pipelines CI/CD — ce qui constituerait une attaque supply chain interne.

L'impact dans un contexte DevSecOps est particulièrement grave. Les forges Git centralisent le code source, les secrets CI/CD (tokens AWS, clés SSH, credentials de bases de données), et orchestrent les déploiements en production. Un attaquant contrôlant l'instance Gitea peut modifier les scripts de build pour injecter un backdoor dans chaque déploiement, accéder aux variables d'environnement des pipelines, et pivoter vers les environnements cloud connectés aux runners CI/CD.

SecurityWeek rappelle que CVE-2026-60004 s'inscrit dans une tendance documentée de 2026 : les forges Git et outils CI/CD auto-hébergés sont devenus des cibles prioritaires des groupes APT et opérateurs de ransomware. La CISA a d'ailleurs publié en juillet 2026 un guide spécifique sur la sécurisation des environnements DevSecOps, recommandant d'intégrer les outils de développement dans le périmètre des audits réguliers.

Le profil démographique des utilisateurs de Gitea amplifie le risque collectif. Contrairement à GitHub ou GitLab.com, Gitea est principalement déployé par des PME, universités et collectivités souhaitant une alternative économique auto-hébergée. Ces déploiements fonctionnent souvent sans équipe sécurité dédiée, avec des cycles de mise à jour irréguliers et une exposition directe sur internet sans WAF — un profil idéal pour des attaquants qui scannent automatiquement les versions vulnérables. Les estimations post-incident situent entre 20% et 35% la proportion d'instances Gitea exposées tournant encore en version vulnérable au moment de l'alerte CISA.

Impact et exposition

Toutes les instances Gitea antérieures à 1.27.1 sont vulnérables. L'exposition est maximale pour les instances accessibles depuis internet avec inscription ouverte activée. Les environnements à risque critique incluent les forges hébergeant du code de production avec secrets CI/CD intégrés, les instances connectées à des registres de containers ou environnements cloud, et les systèmes sans segmentation réseau entre la forge et les serveurs de production. Même les instances en réseau interne peuvent être exploitées si un attaquant a déjà pied sur le réseau d'entreprise.

Recommandations

  • Mettre à jour immédiatement vers Gitea 1.27.1 ou supérieur — ne pas attendre le prochain cycle de maintenance planifié
  • Désactiver l'inscription ouverte si non fonctionnellement requise : Administration → Authentication → décocher "Allow Self Registration"
  • Auditer les hooks Git existants dans tous les dépôts : find /path/to/gitea/repositories -name "pre-receive" -o -name "post-receive"
  • Analyser les logs d'accès pour des créations de comptes, dépôts ou uploads de patches suspects dans les 30 derniers jours
  • Isoler l'instance du réseau public si le patch ne peut pas être appliqué immédiatement — accès via VPN uniquement
  • Auditer les pipelines CI/CD connectés pour détecter toute modification de scripts ou injection dans les artifacts de build

Alerte critique — Exploitation active, KEV CISA

CVE-2026-60004 est activement exploitée dans la nature. Toute instance Gitea antérieure à la version 1.27.1 accessible depuis internet doit être considérée comme potentiellement compromise. Patcher maintenant ou isoler immédiatement du réseau public.

Comment vérifier si mon instance Gitea est vulnérable et si elle a déjà été compromise ?

Pour vérifier la version : interface d'administration Gitea (bas de page) ou en ligne de commande avec gitea --version. Toute version antérieure à 1.27.1 est vulnérable. Pour détecter une compromission : recherchez dans vos logs des requêtes POST inhabituelles vers les endpoints /api/v1/repos/, vérifiez les hooks Git dans vos dépôts (ls -la .git/hooks/), contrôlez les processus enfants du service Gitea pour des exécutions suspectes, et auditez les nouvelles clés SSH ou tokens API créés après le 27 juillet 2026.

Votre infrastructure est-elle exposée ?

Ayi NEDJIMI réalise des audits de sécurité ciblés pour identifier et corriger vos vulnérabilités avant qu'elles ne soient exploitées.

Demander un audit