CVE-2026-59774 : Gitea CVSS 9.8, lecture de fichiers non-auth mène au RCE

Les faits

Le 2 aout 2026, l'equipe securite de Gitea a publie l'avis de securite GHSA-6v53-hr58-556r couvrant une vulnerabilite desormais referencee CVE-2026-59774, notee CVSS v3.1 a 9,8. La faille affecte toutes les instances de Gitea entre les versions 1.22.1 et 1.27.0, soit environ deux ans de releases stables exposees simultanement. La correction est disponible dans la version 1.27.1, publiee le meme jour que l'advisory.

Techniquement, le probleme reside dans la fonctionnalite de rendu de markup des depots. L'endpoint POST /{owner}/{repo}/markup accepte du contenu de type Org-mode (extension .org) et le transmet a la bibliotheque tierce go-org pour rendu. Cette bibliotheque traite la directive #+INCLUDE propre au format Org-mode, qui permet d'inclure le contenu d'un fichier local dans le document rendu. Le code de Gitea appelle ioutil.ReadFile sur le chemin specifie sans aucune validation ni restriction de chemin. Un attaquant peut ainsi soumettre une requete anonyme sur n'importe quel depot public et lire des fichiers arbitraires sur le serveur Gitea.

L'exploitation commence par la lecture du fichier de configuration principal app.ini, situe par defaut sous /home/git/gitea/custom/conf/app.ini ou /etc/gitea/app.ini. Ce fichier contient notamment le parametre INTERNAL_TOKEN, un secret cryptographique qui permet a Gitea d'authentifier ses appels API internes entre composants. Une fois ce token en main, l'attaquant peut appeler l'API interne de Gitea pour injecter un hook Git malveillant via le logger interne, puis declencher l'execution de ce hook lors d'une operation de clone anonyme. La chaine complete, de la lecture de fichier a l'execution de commandes arbitraires, ne requiert aucun compte utilisateur.

Selon les analyses publiees par The Hacker News le 5 aout 2026 et corroborees par GBHackers, l'exploitation est possible sur n'importe quel depot public. Les instances Gitea accessibles sur Internet avec au moins un depot public sont directement exposees. Les instances purement privees beneficient d'une exposition reduite, mais restent vulnerables si un compte authentifie compromis est utilise pour amorcer l'attaque.

Rescana a publie le 7 aout 2026 une alerte d'exploitation active, indiquant que des scanners automatises ciblent deja les endpoints /markup exposes. La surface d'attaque est considerable : Gitea est la forge Git auto-hebergee la plus deployee dans les environnements DevOps independants, les PME et les collectivites. On l'estime active sur plusieurs centaines de milliers d'instances a l'echelle mondiale, dont une proportion significative directement exposee sur Internet sans reverse proxy protecteur.

Les donnees accessibles via la lecture arbitraire vont bien au-dela du seul app.ini. Un attaquant peut cibler /etc/passwd, des fichiers .env, des cles SSH stockees sous /home/git/.ssh/, des secrets Kubernetes montes dans le conteneur, des certificats TLS, ou tout autre fichier lisible par le processus Gitea. Dans les deploiements Docker, l'espace de nommage de fichiers peut exposer des secrets montes depuis des volumes ou ConfigMaps. La surface de donnees sensibles atteignable est donc considerablement plus large que la seule compromission de la configuration Gitea.

Le score CVSS AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H reflete la nature pleinement reseau de la vulnerabilite : aucune authentification, aucune interaction utilisateur, aucun prerequis technique particulier. La faille de Gitea suit un pattern bien documente dans les parseurs de markup — XML External Entity (XXE), SSRF via rendu HTML, inclusion de fichiers locaux — qui tend a reapparaitre dans des bibliotheques tierces non concues pour un contexte web expose. La bibliotheque go-org, dediee au rendu du format Emacs Org-mode, n'a pas ete initialement concue pour traiter des inputs non fiables dans un contexte serveur.

Cyberpress et Cryptika ont publie des analyses techniques complementaires les 5 et 6 aout 2026, confirmant la reproductibilite de l'exploitation et la disponibilite d'un proof-of-concept semi-public. Cybersecuritynews.com rapporte par ailleurs que la faille permet potentiellement un mouvement lateral vers d'autres systemes si les secrets recuperes dans app.ini permettent d'acceder a des systemes tiers integres a l'instance Gitea : tokens OAuth, cles de chiffrement de base de donnees, credentials SMTP.

Impact et exposition

Sont directement exposees toutes les instances Gitea entre 1.22.1 et 1.27.0 avec au moins un depot public accessible. L'impact potentiel couvre la compromission de l'ensemble du code source heberge, le vol de tokens et secrets de pipeline CI/CD, la prise de controle complete du serveur par escalade vers RCE, et le rebond vers d'autres systemes du reseau interne via les secrets recuperes. Les equipes utilisant Gitea comme forge centrale de leur pipeline DevSecOps sont particulierement exposees.

Recommandations

• Mettre a jour immediatement vers Gitea 1.27.1 — c'est la seule correction effective
• Isoler l'instance Gitea derriere un reverse proxy (Nginx, Caddy) avec regles WAF bloquant les requetes POST vers /markup contenant la directive #+INCLUDE en contournement temporaire
• Auditer les logs d'acces pour des requetes POST suspectes vers */markup depuis des IP non repertoriees dans vos pipelines CI/CD
• Rotation des secrets : considerer l'INTERNAL_TOKEN, les cles SSH de deploiement et les tokens API Gitea comme potentiellement compromis si l'instance etait exposee sans le patch
• Inventorier les fichiers sensibles montes dans le conteneur ou accessibles par le processus Gitea