Gitea CVE-2026-59774 — une lecture de fichier non authentifiée à CVSS 9.8 escalade en exécution de code sur tous les dépôts auto-hébergés

2 août 2026, 10 h 00 UTC. L’équipe Gitea publie l’avis GHSA-6v53-hr58-556r accompagnant la version 1.27.1. La vulnérabilité — CVE-2026-59774 — obtient un CVSS 9.8 (Critique). Le vecteur est simple : un attaquant non authentifié envoie une requête POST à l’endpoint de rendu de markup d’un dépôt public, et le parseur Org-mode de Gitea lui renvoie le contenu de n’importe quel fichier lisible par le compte de service.

Ce n’est pas une vulnérabilité théorique. C’est la troisième CVE critique touchant Gitea en 2026, et le pattern est désormais documenté : chaque faille est exploitée in-the-wild dans les 13 jours suivant la publication du correctif. Si vous auto-hébergez Gitea, vous n’avez pas le luxe d’attendre la prochaine fenêtre de maintenance.

La mécanique : une ligne Org-mode suffit

La vulnérabilité siège dans le rendu de markup des dépôts. Quand un utilisateur (ou un visiteur anonyme) demande le rendu d’un fichier via POST /{owner}/{repo}/markup, Gitea accepte de traiter le contenu comme du markup Org-mode si le fichier porte l’extension .org.

Le problème est dans l’initialisation de la bibliothèque go-org. Gitea ne remplace pas le callback de lecture de fichiers par défaut de go-org. Résultat : une directive Org-mode parfaitement légitime —

#+INCLUDE: "/etc/gitea/app.ini"

— suffit à lire le fichier de configuration complet de l’instance Gitea. Le fichier app.ini contient généralement :

• Le INTERNAL_TOKEN, utilisé pour l’authentification inter-services
• Les secrets OAuth (GitHub, GitLab, OpenID Connect)
• Les clés JWT (LFS, signing)
• Les identifiants de base de données
• Les clés SMTP et les tokens d’intégration

La condition d’exploitation est presque triviale : le dépôt doit être public et son unité de code activée. Aucune authentification préalable, aucune interaction utilisateur, aucun compte — juste une requête POST bien formée.

L’escalade RCE : le INTERNAL_TOKEN comme clé du royaume

Lire app.ini est déjà catastrophique. Mais l’avis GitHub classe explicitement la vulnérabilité comme CWE-22 (traversée de chemin) avec un avertissement supplémentaire : l’attaquant peut utiliser le INTERNAL_TOKEN volé pour injecter un hook Git dans un dépôt.

Le INTERNAL_TOKEN est le secret maître utilisé par Gitea pour authentifier ses propres appels internes. Avec ce token, un attaquant peut appeler l’API interne de Gitea et modifier les hooks Git d’un dépôt — par exemple, y injecter un post-receive qui exécute une commande système arbitraire.

Le hook malveillant s’exécute ensuite avec les privilèges du compte de service Gitea (souvent git ou gitea) dès qu’un utilisateur pousse sur le dépôt — ou simplement en déclenchant l’opération via l’API. Le résultat est une exécution de code distante complète sur le serveur hébergeant l’instance Gitea.

Versions affectées et correctif

La faille a été introduite avec la version 1.22.1 — ce qui signifie que toutes les instances mises à jour depuis début 2025 sont potentiellement vulnérables. La correction dans la 1.27.1 remplace le callback de lecture de fichiers par défaut de go-org par une version qui refuse les chemins absolus et limite la lecture au répertoire du dépôt.

Gitea ne fournit pas de contournement. La mise à jour est la seule mitigation.

Le contexte : troisième CVE critique pour Gitea en 2026

CVE-2026-59774 s’inscrit dans une série préoccupante. ByteIota a documenté le pattern : CVE-2026-20896 (bypass admin en un header) a été activement scannée par des acteurs malveillants dans les 13 jours suivant sa divulgation. CVE-2026-27771 (fuite d’images de conteneurs privées) a suivi la même trajectoire.

La leçon est brutale mais claire : les instances Gitea auto-hébergées sont désormais une cible prioritaire pour les scans automatisés post-divulgation. Le délai de grâce entre la publication d’un correctif et l’exploitation in-the-wild se compte en jours, pas en semaines.

Verdict : patcher ne suffit pas, pivotez vos secrets

La mise à jour vers Gitea 1.27.1 est la priorité absolue — mais elle est insuffisante. Si votre instance était exposée avant le correctif, vous devez partir du principe que votre app.ini a pu être lu. Les actions post-patch sont aussi critiques que le patch lui-même :

1. Mettre à jour toutes les instances vers Gitea 1.27.1+
2. Régénérer le INTERNAL_TOKEN (gitea generate secret INTERNAL_TOKEN)
3. Pivoter tous les secrets OAuth (GitHub, GitLab, OpenID) enregistrés dans l’instance
4. Pivoter les clés JWT (LFS, signing)
5. Changer les mots de passe de base de données et les credentials SMTP
6. Auditer les logs pour les requêtes suspectes vers /markup avec des extensions .org ou des directives #+INCLUDE

Si vous auto-hébergez Gitea sur un réseau exposé — même derrière un reverse proxy — considérez cette CVE comme une compromission potentielle de votre instance, pas comme une vulnérabilité à corriger « bientôt ». Le INTERNAL_TOKEN est une clé maîtresse : si quelqu’un l’a lue, votre instance n’est plus la vôtre.

Références

• GitHub Advisory — GHSA-6v53-hr58-556r (CVE-2026-59774)
• Cyber Security News — Critical Gitea Arbitrary File Read Vulnerability (August 4, 2026)
• ByteIota — CVE-2026-59774: Gitea File Read Escalates to RCE
• The Hacker News — Critical Gitea Flaw Let Unauthenticated Attackers Read Server Files (August 2026)
• Gitea 1.27.1 Release Notes