Si vous faites tourner une instance Gitea chez vous et que vous n’y avez pas touché depuis juillet, allez vérifier son numéro de version avant de lire la suite. Gitea 1.27.1 est sorti le 27 juillet 2026 avec deux correctifs de sécurité, mais l’avis officiel concernant le plus grave des deux n’a été publié que le 2 août. Cette semaine de décalage explique en bonne partie pourquoi tant d’instances tournent encore aujourd’hui sur une version vulnérable.
C’est le premier correctif de la branche 1.27. Il regroupe 48 pull requests en plus du travail de sécurité, et les mainteneurs ont été inhabituellement directs : mettez à jour dès que possible. Voici ce qui cassait.
CVE-2026-59774 : lire n’importe quel fichier sans compte
CVE-2026-59774 affiche un score CVSS de 9,8, classé critique. Toutes les versions de 1.22.1 à 1.27.0 sont concernées, et le correctif arrive avec 1.27.1. GitHub a publié l’avis formel sous la référence GHSA-6v53-hr58-556r le 2 août 2026.
La cause est banale. Gitea initialisait la bibliothèque go-org sans remplacer son callback ReadFile par défaut. Or le format Org-mode propose une directive #+INCLUDE qui insère le contenu d’un autre fichier : avec le callback d’origine en place, cette directive lisait tout ce que le compte de service Gitea pouvait lire.
Aucun compte n’est nécessaire pour la déclencher. Un attaquant interroge le point d’entrée de rendu de balisage (/markup) sur n’importe quel dépôt public, y soumet du contenu Org-mode contenant un #+INCLUDE qui pointe vers un chemin absolu, et récupère le contenu du fichier. C’est ce détail qui mérite qu’on s’y arrête : un seul dépôt public sur votre instance suffit comme surface d’attaque. Pas d’inscription, pas de jeton, pas de connexion.
Et ça ne s’arrête pas à la lecture. Lire app.ini, en extraire l’INTERNAL_TOKEN, se servir de ce jeton pour injecter un hook Git via le logger interne, puis déclencher le hook avec un clone anonyme. La lecture de fichier devient une exécution de commandes sur l’hôte.
Les pull requests #38642 et #38645 portent le correctif. XBOW Security a signalé la faille, NightRang3r l’a trouvée de son côté, et le patch vient de @wxiaoguang et @TheFox0x7.
CVE-2026-60004 : exécution de code via l’API diffpatch
La seconde faille, CVE-2026-60004, permet une exécution de code à distance en installant un hook Git par l’API diffpatch. Elle est corrigée par les pull requests #38637 et #38638, signalée par NightRang3r et patchée par @wxiaoguang.
Celle-ci demande un accès en écriture à un dépôt, ce qui la place dans une autre catégorie que CVE-2026-59774. Si votre instance est privée et que chaque compte appartient à quelqu’un à qui vous confieriez de toute façon un accès shell, le risque réel est plus faible. Si les inscriptions sont ouvertes, ou si vous hébergez les dépôts de contributeurs dont vous ne répondez pas personnellement, la nuance devient nettement moins rassurante.
Ce que disent les faits sur l’exploitation
L’avis de Gitea indique qu’aucune exploitation n’a été observée dans la nature. Au 5 août 2026, CVE-2026-59774 ne figurait pas non plus au catalogue CISA des vulnérabilités activement exploitées. Quelques sites d’actualité sécurité ont titré sur une exploitation active : la source primaire ne dit pas cela. Tant que Gitea ou la CISA n’annonce pas le contraire, considérez l’information comme non confirmée.
Ce qui ne change pas grand-chose à la priorité. Un 9,8 avec un chemin d’attaque trivial, un avis public et un correctif déjà disponible mérite d’être traité pour ce qu’il est, que quelqu’un ait appuyé sur la détente ou non.
Le reste des changements de la 1.27.1
Les 46 autres pull requests relèvent de la maintenance ordinaire, mais quelques-unes valent d’être connues :
- La politique 2FA obligatoire s’applique désormais aux points d’entrée OAuth2 authorize et grant (#38606).
- Le clone HTTP avec redirections refonctionne. La restriction introduite en 1.27.0 a été annulée (#38545).
- Gitea continue de servir un certificat ACME valide quand le renouvellement échoue au démarrage, au lieu de refuser de démarrer (#38583).
- Un lot conséquent de corrections pour Gitea Actions : les jobs bloqués en
cancellingaprès un redémarrage, les blocsrun:multilignes et la gestion depull_request_target.
Le correctif ACME fait partie de ceux qu’on n’apprécie qu’une fois qu’ils vous ont sauvé la mise. Le détail complet figure dans l’annonce officielle de la version 1.27.1.
Quoi faire sur votre instance
- Vérifiez la version que votre instance affiche réellement, pas celle qui figure dans vos notes. Tout ce qui va de 1.22.1 à 1.27.0 est concerné par CVE-2026-59774.
- Passez en 1.27.1. Si vous déployez avec Docker, récupérez le tag mis à jour plutôt que de vous fier à une image en cache.
- Si la mise à jour ne peut pas se faire tout de suite, placez l’instance derrière un VPN ou une couche d’authentification au niveau du reverse proxy, pour que le point d’entrée
/markupne soit plus joignable anonymement. - Si votre instance était accessible publiquement pendant qu’elle tournait sur une version affectée, changez l’
INTERNAL_TOKENet passez vos dépôts en revue à la recherche de hooks Git que vous n’avez pas installés.
C’est la deuxième affaire de sécurité sérieuse chez Gitea en deux mois. En juillet, nous avions couvert CVE-2026-20896, le contournement d’authentification de l’image Docker officielle, un bug distinct avec un correctif distinct. Deux découvertes critiques sans rapport en si peu de temps en dit plus long sur l’attention dont le projet fait l’objet en ce moment que sur la qualité de son code, même si ça plaide pour planifier les mises à jour plutôt que de les subir quand quelque chose casse. Si vous pesez les alternatives, Forgejo est le fork communautaire et vaut le coup d’œil, mais il partage assez d’ancêtres avec Gitea pour ne pas constituer une porte de sortie de ce type de problème.