La CVE-2026-20896 affiche un score CVSS de 9,8, classée critique, et elle est désormais activement exploitée contre des instances Gitea auto-hébergées qui tournent avec l’image Docker officielle du projet. Le bug permet à un attaquant de se connecter en tant que n’importe quel utilisateur, comptes administrateur compris, sans mot de passe, sans jeton, sans cookie de session. L’équipe de Gitea a corrigé le problème dans les versions 1.26.3 et 1.26.4, publiées les 20 et 21 juin 2026 (annonce officielle).
La cause racine : un joker codé en dur
Le bug se cache dans le modèle de configuration app.ini livré avec l’image Docker officielle gitea/gitea sur Docker Hub et GHCR. Ce modèle définit REVERSE_PROXY_TRUSTED_PROXIES = *, au lieu de la valeur par défaut documentée et sûre 127.0.0.0/8,::1/128 (loopback uniquement). Résultat : Gitea finit par faire confiance à l’en-tête HTTP X-WEBAUTH-USER, censé n’être posé que par un reverse proxy ayant déjà vérifié l’identité de l’utilisateur, depuis n’importe quelle IP source capable d’atteindre le conteneur. Pas seulement depuis le proxy placé devant lui. Le détail technique complet se trouve dans l’avis de sécurité officiel GitHub GHSA-f75j-4cw6-rmx4.
Comment le contournement fonctionne concrètement
Si le port de votre conteneur Gitea est joignable, que ce soit directement, via une règle de pare-feu mal configurée, ou depuis un autre conteneur sur le même réseau Docker, un attaquant n’a même pas besoin de toucher à votre reverse proxy. Il envoie une requête directement à Gitea avec un en-tête falsifié X-WEBAUTH-USER: admin (ou gitea_admin, ou tout autre nom de compte qu’il devine), et Gitea le connecte en tant que cet utilisateur. Sans mot de passe. Sans jeton. Sans cookie. Activez en plus ENABLE_REVERSE_PROXY_AUTO_REGISTRATION, et l’attaquant n’a même plus besoin de deviner un nom d’utilisateur valide : il peut carrément créer un nouveau compte à la volée.
Qui est réellement concerné
Autant être précis, tant il est facile d’exagérer la portée du problème. Le bug ne touche que les installations qui réunissent ces trois conditions à la fois :
- Utilisation de l’image Docker officielle (
gitea/giteadepuis Docker Hub ou GHCR), pas une version binaire ni une compilation maison - Version 1.26.2 ou antérieure
- Avec
ENABLE_REVERSE_PROXY_AUTHENTICATION=trueactivé, une configuration courante chez qui associe Gitea à Authentik, Authelia ou une autre couche SSO / authentification par reverse proxy
Vous avez installé Gitea à partir d’une version binaire, ou compilé vous-même en suivant le app.example.ini documenté ? Vous êtes tranquille. Ces chemins d’installation héritent de la valeur par défaut sûre, limitée au loopback, et n’ont jamais été exposés à ce bug. Seul le modèle intégré à l’image Docker officielle embarquait le joker.
Une précision qui mérite d’être ajoutée : Forgejo, le fork communautaire de Gitea, gère son propre processus de publication et de sécurité, indépendant de celui de Gitea. Nous n’avons trouvé aucune source primaire confirmant si la CVE-2026-20896 s’applique ou non à Forgejo, donc nous n’allons pas spéculer ici. Les utilisateurs de Forgejo doivent consulter directement les avis de sécurité de ce projet.
L’exploitation active a déjà commencé
Le chercheur rz1027 a découvert la faille et l’a signalée de façon responsable ; il est crédité sur l’avis publié le 21 juin 2026. L’exploitation réelle a suivi rapidement. Michael Clark, Sr. Director of Threat Research chez Sysdig, a rapporté la première tentative d’exploitation observée seulement 13 jours après la publication de l’avis, aux alentours du 4 juillet 2026, une tentative tracée jusqu’à un scanner routé via un nœud de sortie VPN. Security Affairs en a parlé le 7 juillet, BleepingComputer le 10. Les données Shodan et Sysdig évaluent à environ 6 200 le nombre d’instances Gitea actuellement joignables publiquement sur internet, même si personne ne sait combien d’entre elles tournent réellement avec la configuration Docker vulnérable. La Cyber Security Agency de Singapour a elle aussi publié une alerte publique au sujet de cette exploitation active.
Comment protéger votre instance
Mettez à jour vers Gitea 1.26.4, ou 1.26.3 au minimum. L’authentification par reverse proxy est désormais optionnelle : un administrateur doit la configurer explicitement, au lieu que Gitea fasse confiance à un joker par défaut. Un point à signaler : la 1.26.3 n’était pas un correctif isolé, ciblant un seul problème. Elle regroupait des correctifs pour huit autres CVE dans la même version, dont un renforcement contre le SSRF, une correction de rejeu TOTP, et un contournement d’authentification LFS via SSH. Vous faites tourner Gitea sous Docker ? C’est le bon moment pour mettre à jour toute la pile, pas seulement corriger ce bug précis.
Impossible de mettre à jour tout de suite ? Configurez REVERSE_PROXY_TRUSTED_PROXIES avec l’adresse IP réelle de votre reverse proxy, jamais un joker, et allez vérifier vos journaux d’accès Gitea à la recherche de toute anomalie impliquant l’en-tête X-WEBAUTH-USER.
Vous faites tourner l’image Docker officielle de Gitea derrière un reverse proxy ? Consultez notre guide d’installation Gitea, et vérifiez votre version dès maintenant.