Gitea CVE-2026-20896 : bypass admin en un header HTTP, exploitation active

Un seul header HTTP suffit à prendre le contrôle de Gitea

Le 25 juin 2026, l'équipe Gitea a publié les versions 1.26.3 et 1.26.4 de sa forge logicielle open source, corrigeant pas moins de neuf vulnérabilités. Parmi elles, la CVE-2026-20896 se distingue par sa criticité et sa simplicité d'exploitation : avec un score CVSS de 9.8, elle permet à un attaquant non authentifié d'accéder à n'importe quel compte, y compris les comptes administrateurs, en ajoutant un unique en-tête HTTP à sa requête.

La faille réside dans la combinaison de deux comportements configurés par défaut dans les images Docker officielles de Gitea. Le premier est le paramètre REVERSE_PROXY_TRUSTED_PROXIES, positionné à * par défaut, ce qui signifie que Gitea considère toutes les connexions entrantes comme provenant d'un reverse proxy de confiance. Le second est la fonctionnalité d'authentification par reverse proxy (ENABLE_REVERSE_PROXY_AUTHENTICATION) : lorsqu'elle est activée, Gitea fait confiance à l'en-tête HTTP X-WEBAUTH-USER comme source d'autorité pour identifier l'utilisateur connecté.

Dans la pratique, l'exploitation est triviale. Un attaquant envoie une requête HTTP ordinaire vers n'importe quel point d'entrée de l'instance Gitea, en y ajoutant l'en-tête X-WEBAUTH-USER: admin. Gitea accepte cet en-tête comme preuve d'identité, ouvre une session administrateur et donne accès à l'intégralité de la plateforme : tous les dépôts, les paramètres d'organisation, les tokens d'accès des autres utilisateurs, les webhooks et les pipelines CI/CD. Aucun mot de passe, aucun token valide, aucun second facteur d'authentification n'est requis. Il ne s'agit pas d'une faille théorique : l'exploitation est reproductible en quelques secondes avec des outils standards comme curl.

Selon l'analyse de Rescana et de Security Affairs, la vulnérabilité affecte toutes les images Docker Gitea jusqu'à la version 1.26.2 incluse, quelle que soit la version du système d'exploitation hôte ou la configuration réseau environnante. Les instances déployées directement depuis le binaire sans passer par l'image Docker officielle sont moins susceptibles d'être concernées, car la valeur par défaut problématique du paramètre REVERSE_PROXY_TRUSTED_PROXIES a été introduite spécifiquement dans les images Docker.

La divulgation publique s'est faite fin juin 2026, simultanément à la sortie du patch. Treize jours plus tard — soit aux alentours du 7 juillet 2026 — les équipes de surveillance des menaces ont détecté les premières sondes actives contre des instances vulnérables. D'après The Hacker News, la première IP identifiée dans les scans de reconnaissance est 159.26.98[.]241, un nœud de sortie du service ProtonVPN, ce qui complique l'attribution directe à un acteur spécifique. Ce type de nœud est classiquement utilisé par des groupes organisés souhaitant masquer leur origine réelle lors d'une phase d'énumération préliminaire.

SecurityWeek et Daily Security Review estiment qu'environ 6 200 serveurs Gitea étaient accessibles depuis Internet et potentiellement vulnérables au moment du début de l'exploitation. Ce chiffre inclut les instances hébergées par des PME, des équipes de développement indépendantes, des organismes publics et des prestataires de services qui ont choisi Gitea comme alternative auto-hébergée à GitHub ou GitLab Enterprise. Beaucoup de ces déploiements datent de plusieurs années et n'ont jamais été mis à jour de manière systématique.

La nature du vecteur d'attaque — un en-tête HTTP — signifie qu'elle est exploitable aussi bien depuis Internet que depuis un réseau interne en cas de compromission d'un poste de travail. Une fois l'accès admin obtenu, les conséquences potentielles comprennent l'exfiltration du code source complet, le vol de secrets CI/CD (clés SSH, tokens API, credentials cloud), l'injection de code malveillant dans les pipelines de déploiement, et la création de backdoors persistantes dans les dépôts. Dans les environnements où Gitea est couplé à un système de déploiement continu, un attaquant peut potentiellement compromettre des environnements de production sans jamais toucher directement aux serveurs cibles.

Le correctif introduit par les versions 1.26.3 et 1.26.4 supprime le wildcard * du paramètre REVERSE_PROXY_TRUSTED_PROXIES et rend l'authentification par reverse proxy explicitement opt-in, avec une liste blanche stricte des adresses IP de confiance. Hive Security et le blog officiel de Gitea recommandent également un audit des logs d'accès des deux dernières semaines pour détecter d'éventuelles requêtes contenant l'en-tête X-WEBAUTH-USER.

Pourquoi cette faille révèle un angle mort critique des forges auto-hébergées

Gitea est l'une des forges logicielles open source les plus populaires pour les organisations qui souhaitent héberger leur code sur leur propre infrastructure plutôt que de dépendre de plateformes SaaS comme GitHub. Sa popularité repose sur sa légèreté, sa simplicité de déploiement via Docker, et sa compatibilité avec les workflows Git standards. Des dizaines de milliers d'équipes à travers le monde l'utilisent quotidiennement pour des projets allant des logiciels industriels aux applications gouvernementales sensibles.

Un accès administrateur à une forge comme Gitea donne concrètement accès aux clés du système d'information d'une organisation. Le code source constitue la propriété intellectuelle de l'entreprise, mais il contient aussi fréquemment des credentials intégrés par erreur dans l'historique des commits, des fichiers de configuration d'environnement, et des tokens d'accès aux services cloud. Les secrets CI/CD stockés dans Gitea donnent à leur tour accès aux environnements de staging et de production. Un attaquant méthodique peut ainsi pivoter depuis un seul serveur Gitea vers l'ensemble de l'infrastructure d'une organisation en quelques heures.

Le délai de treize jours entre la divulgation publique et le début de l'exploitation active illustre un phénomène bien documenté dans la communauté de la sécurité : le patch gap. Lorsqu'une vulnérabilité critique est publiée avec ses détails techniques — et dans ce cas, l'exploitation est si simple qu'un proof-of-concept peut être reconstruit en lisant simplement le changelog — les acteurs malveillants industrialisent rapidement la reconnaissance et l'exploitation, souvent avant que les équipes IT des organisations vulnérables aient eu le temps d'identifier les instances à risque, de planifier la maintenance et d'appliquer le patch. Ce délai de treize jours est d'ailleurs supérieur à ce que l'on observe sur des failles encore plus médiatisées : les vulnérabilités Apache Log4Shell en 2021 avaient été exploitées en moins de quarante-huit heures après divulgation.

La problématique des forges auto-hébergées est particulièrement sensible dans les chaînes d'approvisionnement logicielle. Depuis l'attaque SolarWinds en 2020 et la backdoor XZ Utils découverte en 2024, les attaquants cherchent systématiquement à s'infiltrer le plus en amont possible du pipeline de développement. Compromettre un serveur Gitea hébergeant le code d'un prestataire IT peut ainsi permettre d'atteindre des dizaines de clients en aval, sans que ces derniers soupçonnent quoi que ce soit. C'est précisément ce modèle d'attaque supply chain qui préoccupe les agences de cybersécurité comme l'ANSSI et le CERT-FR depuis plusieurs années.

Ce qu'il faut retenir

• Mettre à jour immédiatement vers Gitea 1.26.3 ou 1.26.4 si vous utilisez les images Docker officielles ; l'exploitation active a déjà commencé.
• Même sans mise à jour immédiate, désactiver ENABLE_REVERSE_PROXY_AUTHENTICATION ou définir explicitement REVERSE_PROXY_TRUSTED_PROXIES avec les seules IP de vos reverse proxys bloque la vulnérabilité.
• Auditer les logs d'accès des deux dernières semaines à la recherche de requêtes contenant l'en-tête X-WEBAUTH-USER pour détecter toute compromission antérieure.