Gitea, la plateforme Git auto-hébergée, fait face à une vulnérabilité critique permettant la lecture de fichiers Gitea sans authentification. Concrètement, un attaquant peut accéder aux fichiers que le compte de service du serveur peut lire, sans avoir besoin de se connecter ni d’écrire dans un dépôt.
La correction est disponible dans Gitea 1.27.1. Comme la faille peut potentiellement évoluer vers une exécution de commandes dans certaines conditions, les administrateurs sont invités à mettre à jour rapidement et à procéder à des contrôles supplémentaires s’ils suspectent une exposition.
Ce que permet la faille : lecture sans connexion
Le point clé est simple : dans les versions concernées, il suffit d’avoir accès à un dépôt public et d’envoyer un contenu markup spécialement conçu. Même sans compte, l’attaquant peut obtenir des données issues du système de fichiers… mais uniquement celles lisibles par le compte de service de Gitea.
Il n’est pas nécessaire de disposer de droits d’écriture dans le dépôt. L’attaque s’appuie sur le chemin de rendu de contenu, via l’exécution du moteur de rendu Org-mode, qui peut être trompé pour inclure des fichiers.
Versions touchées et correctif
La vulnérabilité de lecture de fichiers Gitea concerne les versions 1.22.1 jusqu’à 1.27.0. Elle est corrigée dans Gitea 1.27.1.
Le problème est référencé sous la CVE-2026-59774 avec un niveau Critical et un score CVSS de 9.8. Le bulletin officiel de Gitea a été publié le 2 août.
À noter : Gitea 1.27.1 corrige aussi une autre faiblesse, référencée CVE-2026-60004, liée à une exécution de code à distance. Cette dernière avait déjà fait l’objet d’un précédent signalement.
Pourquoi le rendu Org-mode pose problème
La faille se situe dans le rendu Org-mode de Gitea. Dans la version 1.27.0, Gitea initialise go-org via org.New() sans remplacer correctement la fonction de lecture de fichier par défaut.
Dans le moteur go-org, la directive Org-mode # +INCLUDE peut accepter des chemins de fichier absolus, puis transmet ces chemins à une fonction de lecture. Résultat : l’attaquant peut fournir un markup Org-mode et récupérer le contenu des fichiers accessibles au processus de Gitea.
Le correctif implémente une surcharge de la fonction ReadFile : au lieu de résoudre le chemin sur le système de fichiers, le contenu d’inclusion Org-mode est renvoyé tel quel dans le rendu. Gitea ajoute également un test de non-régression pour couvrir la logique d’inclusion.
Le chemin d’attaque : endpoint de markup
La lecture de fichiers passe par l’endpoint de rendu de markup : POST /{owner}/{repo}/markup. La route accepte une connexion optionnelle, résout le dépôt et vérifie l’accès lecteur.
En requête anonyme, la vérification peut être désactivée pour un dépôt public, à condition que le code d’unité correspondant soit activé. En pratique, cela limite l’exposition : si un serveur Gitea n’héberge aucun dépôt public, le vecteur anonyme via cet endpoint n’offre pas de chemin d’attaque direct.
Ce n’est pas une exécution immédiate… mais une chaîne possible
Gitea précise que la vulnérabilité ne correspond pas, à elle seule, à une exécution de commandes en une requête. Elle fournit d’abord une primitive de lecture de fichiers.
Selon l’avis du fournisseur, un scénario d’escalade pourrait devenir une exécution de commandes si l’attaquant parvient à :
- lire le fichier app.ini ;
- en extraire un INTERNAL_TOKEN ;
- injecter un hook Git via le mécanisme interne de journalisation (internal logger) ;
- déclencher ce hook lors d’un clone anonyme.
La séquence décrite dans l’avis est présentée comme une chaîne d’exploitation possible. Cependant, le rapport indique qu’aucune démonstration d’exploit publiée de manière indépendante n’avait été identifiée.
Ce qu’il faut surveiller et vérifier
Gitea ne publie pas de guidance formelle de détection dans l’avis. Néanmoins, les administrateurs peuvent s’appuyer sur des indices concrets.
En priorité, examinez vos journaux pour repérer des requêtes anonymes vers POST /{owner}/{repo}/markup, en particulier quand le rendu ne ressemble pas à des usages attendus :
- choix explicite d’un rendu Org-mode ;
- présence de chemins de fichiers absolus dans le markup soumis ;
- tentatives d’escalade décrites dans l’avis, si votre environnement les reflète.
Si vous suspectez qu’une tentative d’escalade a eu lieu sur une version affectée, traitez cela comme une exposition potentielle de secrets accessibles au service Gitea. Dans ce cas, il est recommandé de faire pivoter :
- le INTERNAL_TOKEN ;
- les matériaux liés à OAuth ;
- les clés de signature JWT ;
- les identifiants de connexion à la base de données.
Autrement dit : même après une mise à jour, la correction peut ne pas suffire si des données ont déjà été compromises.
Origine de la découverte et état public
La faille a été identifiée par XBOW Security, un système autonome orienté offensive, puis triée par Guido Leo. Une notification indépendante a également été rapportée par Shai Rod, connu en ligne sous le nom NightRang3r.
À la date du 5 août 2026, il n’est pas fait état d’une exploitation observée dans la nature pour CVE-2026-59774, et la vulnérabilité n’avait pas encore figuré dans le catalogue CISA des vulnérabilités activement exploitées. Le rapport mentionne toutefois qu’une prévisualisation de la primitive de lecture avait été partagée publiquement avant l’avis formel.
Plan d’action recommandé pour les administrateurs
Pour réduire le risque, la recommandation principale reste la même : mettez à jour immédiatement vers Gitea 1.27.1. Pour les instances opérées via Cloud, le fournisseur indique que les mises à niveau seront effectuées automatiquement pendant la fenêtre de maintenance.
Ensuite, procédez à un contrôle orienté sécurité :
- vérifiez la présence d’éventuelles requêtes anonymes vers l’endpoint de markup ;
- contrôlez les entrées liées à la sélection Org-mode et aux inclusions de chemins ;
- si une tentative d’escalade a été observée, considérez les secrets du service comme compromis et effectuez les rotations nécessaires.
Enfin, gardez en tête que l’objectif n’est pas seulement de corriger la vulnérabilité, mais aussi de confirmer que l’environnement n’a pas été utilisé pour extraire des informations exploitables.
Conclusion
La lecture de fichiers Gitea via Org-mode est une faiblesse sérieuse : elle permet d’accéder sans authentification à des fichiers lisibles par le compte de service de Gitea, à partir d’un dépôt public et d’un markup conçu. Heureusement, Gitea 1.27.1 corrige le problème (CVE-2026-59774).
La mise à jour est essentielle, mais pas toujours suffisante : si vous constatez des traces d’exploitation sur des versions affectées, il faut traiter l’incident comme une exposition potentielle et faire pivoter les secrets.
Source: https://thehackernews.com/2026/08/critical-gitea-flaw-let-unauthenticated.html
