La réponse courte
Gitea, le service Git auto-hébergé populaire, présente une vulnérabilité critique de lecture arbitraire de fichiers sans authentification — CVE-2026-59774, notée CVSS 9.8 — qui permet à n'importe qui de lire des fichiers sur le serveur sans se connecter, et d'enchaîner vers l'exécution de code à distance. L'attaque ne nécessite qu'un dépôt public et un document Org-mode contrefait : une requête vers l'endpoint de rendu de balisage de Gitea exploite la directive Org-mode #+INCLUDE pour inclure des fichiers arbitraires via des chemins absolus. Les versions affectées sont 1.22.1 à 1.27.0 ; le correctif est Gitea 1.27.1, qui corrige également une faille d'exécution de code associée, CVE-2026-60004.
Si vous hébergez Gitea en propre dans votre stack CI/CD et DevOps — ce que beaucoup d'équipes font précisément pour garder le code source hors des clouds tiers — c'est un correctif à appliquer le jour même, pas un avis de routine. La première chose qu'un attaquant lira est votre fichier de configuration, et celui-ci contient les clés de tout le reste.
Ce qui s'est passé
Le 2 août 2026, le projet Gitea a publié un avis de sécurité et livré la version 1.27.1, demandant instamment à tous les utilisateurs de mettre à jour dès que possible. Le problème principal, CVE-2026-59774, est une lecture arbitraire de fichiers sans authentification signalée indépendamment par XBOW Security et le chercheur Guido Leo (NightRang3r). Il porte un score CVSS de 9.8 et affecte toutes les versions Gitea de 1.22.1 à 1.27.0.
La faille réside dans la fonction de rendu de balisage de Gitea. Une requête vers POST /{owner}/{repo}/markup rend des contenus tels que des fichiers README. La route comprend des vérifications d'attribution de dépôt et de lecture, mais un utilisateur anonyme satisfait ces vérifications pour un dépôt public dont l'unité de code est activée — une configuration très courante. Lorsque Gitea rend du contenu Org-mode, il traite la directive #+INCLUDE, et dans les versions affectées, cette directive résout des chemins absolus du système de fichiers. Résultat pratique : envoyer des balises Org-mode contrefaites et lire en retour n'importe quel fichier que le compte de service Gitea peut ouvrir.
La cause racine technique est petite et instructive. Gitea 1.27.0 initialisait la bibliothèque de parsing go-org avec org.New() mais ne remplaçait pas le callback de lecture de fichiers par défaut de la bibliothèque, qui correspond à un simple ReadFile. Rien ne limitait #+INCLUDE au dépôt, rendant le mécanisme d'inclusion un primitif de lecture par traversée de chemins. Le correctif remplace ce callback ; la solution est la version 1.27.1 ou ultérieure.
Comment une lecture de fichiers devient exécution de code
Une lecture arbitraire de fichiers est déjà sérieuse sur un serveur de contrôle de source, car le premier fichier qu'il vaut la peine de lire est la propre configuration de Gitea. Selon l'avis du projet, l'exposition s'escalade en une courte chaîne : lire app.ini pour extraire l'INTERNAL_TOKEN, utiliser ce jeton pour injecter un hook Git via le logger interne, puis déclencher le hook lors d'un clone anonyme. L'état final est l'exécution de commandes sur l'hôte. Gitea 1.27.1 corrige également une faille directement liée, CVE-2026-60004, décrite comme une exécution de code à distance via l'API diffpatch par installation de hook Git — signalée par le même chercheur.
À la date des premiers articles publics le 5 août 2026, CVE-2026-59774 n'était pas apparu dans le catalogue des vulnérabilités exploitées connues de la CISA, et aucun proof-of-concept indépendant n'avait été publié. C'est un maigre réconfort. Le comportement de lecture de fichiers avait été démontré publiquement avant l'avis formel, l'endpoint est trivial à atteindre, et le chemin d'escalade est documenté. Pour une vulnérabilité aussi facile à exploiter sur une infrastructure contenant du code source et des secrets, « pas encore dans le KEV » est un détail de planification, pas un sursis.
Découverte en partie par une IA
Un détail se situe à l'intersection de deux thèmes que nous suivons. L'un des deux rapporteurs indépendants de CVE-2026-59774 était XBOW, un système de sécurité offensive autonome qui trouve et valide des vulnérabilités sans qu'un humain dirige chaque étape. C'est un exemple concret d'un changement plus large : les outils IA compriment le temps nécessaire pour découvrir, confirmer et weaponiser des bugs. Lorsque la même catégorie d'outils est disponible pour les défenseurs et les attaquants, l'hypothèse prudente est qu'une faille fraîchement divulguée et facile à atteindre sera sondée rapidement.
Cela n'appelle pas à la panique ; cela appelle à la cadence. Les équipes qui tiennent un inventaire de leurs outils de développement auto-hébergés, s'abonnent à leurs avis de sécurité et traitent « critique, non authentifié, accessible par Internet » comme un déclencheur de correctif accéléré fermeront cette fenêtre en quelques heures. Les équipes qui découvrent quels services internes elles font tourner seulement quand l'un d'eux est compromis ne le feront pas. Un audit de sécurité périodique incluant la chaîne d'approvisionnement des développeurs — serveurs Git, runners CI, registres d'artefacts — est l'endroit où ces angles morts remontent avant qu'un attaquant les trouve.
Ce que cela signifie pour les équipes logicielles françaises
Gitea est particulièrement attractif pour les équipes qui veulent le contrôle : garder les dépôts sur leur propre infrastructure, à l'intérieur de leur propre réseau, à l'écart des SaaS tiers. Cet instinct est sain — et en France, souvent motivé par des enjeux de souveraineté numérique et de conformité au RGPD. Mais il déplace la charge des correctifs et du durcissement sur vous. Un serveur Git auto-hébergé n'est pas un stockage de fichiers passif ; il contient du code source, des clés de déploiement, des secrets de webhook et les jetons permettant au CI de pousser en production. Un accès en lecture non authentifié à la configuration de ce serveur est un point d'entrée dans toute la chaîne de livraison.
Le cadre de conformité est familier. Sous RGPD, SOC 2 et NIS2, une faille non corrigée et accessible à distance pouvant mener à l'exécution de code et à l'exposition de secrets est une lacune de contrôle avec des implications de gestion des changements et, potentiellement, de notification de violation. « C'était notre serveur Git interne » n'est pas un facteur atténuant si ce serveur était accessible et que les secrets qu'il détenait touchaient des données clients ou des systèmes de production. La démarche pragmatique est d'intégrer les outils de développement auto-hébergés dans la même SLA de correctifs et discipline d'hygiène des secrets que celle déjà appliquée aux services de production.
Ce qu'il faut faire maintenant
Il s'agit d'un incident « corriger puis supposer l'exposition ». L'ordre importe : la mise à jour arrête toute nouvelle exploitation, mais faire tourner les secrets qu'une version vulnérable aurait pu exposer rend toute lecture antérieure inutile.
- Mettre à jour vers Gitea 1.27.1 ou ultérieur. Cela ferme CVE-2026-59774 et la faille RCE associée CVE-2026-60004. Corriger toutes les instances, y compris les serveurs de staging et les serveurs internes oubliés.
- Vérifier d'abord l'exposition. Examiner les journaux d'accès pour les requêtes vers l'endpoint
/{owner}/{repo}/markupsur les versions affectées, et noter si votre Gitea était accessible depuis des réseaux non fiables ou Internet. - Faire tourner ce que la configuration révèle. Régénérer l'
INTERNAL_TOKENdansapp.ini, puis faire tourner les mots de passe de base de données, les secrets d'applications OAuth, les clés de signature JWT, les identifiants SMTP et tous les jetons d'intégration stockés dans la configuration ou le système de fichiers. - Rechercher des hooks plantés. Comme la lecture de fichiers peut enchaîner vers l'exécution de code via les hooks Git, inspecter les dépôts et le répertoire de données Gitea pour des hooks inattendus ou récemment modifiés, et traiter une exposition confirmée comme un compromis de l'hôte.
- Le retirer de l'Internet ouvert. Placer Gitea derrière un VPN ou une liste d'autorisation si possible ; les outils de développement ont rarement besoin d'être accessibles publiquement, et réduire l'exposition diminue le rayon d'explosion de la prochaine faille.
- Mettre en place le flux d'avis. S'abonner aux notes de version de Gitea et ajouter « outils de développement auto-hébergés critiques » à une SLA de correctifs accélérée afin que le prochain 9.8 soit traité le jour même.
Le signal durable de CVE-2026-59774 ne concerne pas un callback de bibliothèque. Il signifie que l'infrastructure de développement auto-hébergée porte des privilèges de niveau production et mérite des opérations de niveau production : un inventaire connu, un flux d'avis, un chemin de correctifs accéléré, et des secrets suffisamment restreints pour que la lecture d'un fichier de configuration ne déverrouille pas toute la pipeline. Les équipes qui traitent leur serveur Git comme le système précieux qu'il est corrigeront cela en une après-midi et passeront à la suite.
Questions fréquentes
Qu'est-ce que CVE-2026-59774 dans Gitea ?
CVE-2026-59774 est une vulnérabilité critique de lecture arbitraire de fichiers sans authentification dans Gitea, le service Git auto-hébergé, notée CVSS 9.8. Un attaquant sans compte peut lire n'importe quel fichier accessible au processus du service Gitea en envoyant des balises Org-mode contrefaites vers l'endpoint de rendu de balisage d'un dépôt public. Les versions 1.22.1 à 1.27.0 sont touchées ; le correctif est Gitea 1.27.1, qui corrige également une faille d'exécution de code à distance associée, CVE-2026-60004.
Comment une faille de lecture de fichiers peut-elle mener à l'exécution de code à distance ?
Selon l'avis de sécurité de Gitea, le primitif de lecture de fichiers peut être enchaîné vers l'exécution de commandes. Un attaquant lit le fichier de configuration app.ini pour extraire l'INTERNAL_TOKEN, injecte un hook Git via le logger interne, puis déclenche ce hook lors d'un clone anonyme. CVE-2026-60004 couvre l'exécution de code à distance via l'API diffpatch par installation de hook Git. Les deux sont corrigés dans Gitea 1.27.1, c'est pourquoi le projet presse tout le monde de mettre à jour immédiatement.
Quelles versions de Gitea sont affectées et quelle est la solution ?
Gitea 1.22.1 à 1.27.0 sont vulnérables à CVE-2026-59774. La solution est Gitea 1.27.1 ou ultérieur. La cause racine est que Gitea initialisait la bibliothèque go-org sans remplacer son callback de lecture de fichiers par défaut, ce qui permettait à la directive #+INCLUDE de résoudre des chemins absolus du système de fichiers. La mise à jour remplace ce comportement et ferme l'endpoint à la traversée de chemins.
Nous avons appliqué le correctif Gitea. Est-ce suffisant ?
Le correctif arrête toute exploitation ultérieure, mais si une version vulnérable était accessible, il faut supposer que des secrets ont peut-être déjà été exposés. Examinez les journaux d'accès pour les requêtes vers l'endpoint de balisage, puis faites tourner l'INTERNAL_TOKEN dans app.ini ainsi que toutes les autres informations d'identification que la configuration ou le système de fichiers serveur pourrait révéler : secrets OAuth, clés de signature JWT, mots de passe de base de données, identifiants SMTP et tokens d'intégration. Comme la lecture de fichiers peut enchaîner vers l'exécution de code, traiter une exposition confirmée comme un compromis du serveur et vérifier les hooks Git inattendus.
Pourquoi une vulnérabilité découverte par une IA est-elle importante pour notre cadence de correctifs ?
L'un des deux rapporteurs indépendants de cette faille était XBOW, un système de sécurité offensive autonome. Les outils IA découvrant et weaponisant des bugs plus rapidement, la fenêtre entre divulgation et exploitation se réduit. La leçon durable est opérationnelle, pas spécifique à un outil : tenir un inventaire de l'infrastructure de développement auto-hébergée, intégrer les avis critiques dans un SLA de correctifs accéléré, et ne pas exposer des outils de développement comme Gitea directement à Internet sans nécessité.
Sources
Gitea — Release of 1.27.1 (avis de sécurité)
The Hacker News — Critical Gitea Flaw Let Unauthenticated Attackers Read Server Files via Org-Mode Markup
Cyber Security News — Critical Gitea Arbitrary File Read Vulnerability Enables RCE