CVE-2026-20896 : Auth bypass Gitea Docker CVSS 9.8

Les faits

La vulnérabilité CVE-2026-20896 a été identifiée dans les images Docker officielles de Gitea, la plateforme DevOps open source auto-hébergée de gestion de dépôts Git. Avec un score CVSS v3.1 de 9.8 (Critique), cette faille permet à un attaquant distant non authentifié d'obtenir un accès administrateur complet à toute instance Gitea Docker déployée en version 1.26.2 ou antérieure. La divulgation publique a eu lieu fin juin 2026, et les premiers sondages malveillants in-the-wild ont été détectés seulement 13 jours plus tard, le 6 juillet 2026, selon des recherches publiées par l'équipe Sysdig Threat Research et relayées par The Hacker News et SecurityWeek.

La cause racine est une mauvaise configuration par défaut dans le modèle de fichier de configuration app.ini livré avec l'image Docker. Dans ce fichier, la directive REVERSE_PROXY_TRUSTED_PROXIES était définie à * (wildcard universel). Gitea propose une fonctionnalité d'authentification par reverse proxy : lorsqu'un reverse proxy (nginx, Traefik, Caddy) est placé devant Gitea, il peut transmettre l'identité de l'utilisateur authentifié via l'en-tête HTTP X-WEBAUTH-USER. La directive REVERSE_PROXY_TRUSTED_PROXIES est supposée restreindre cette confiance aux seules adresses IP des proxies légitimes. En la définissant à *, les développeurs de l'image Docker ont involontairement accordé cette confiance à toutes les adresses IP source, y compris des clients Internet arbitraires non authentifiés.

Le vecteur d'attaque est purement réseau et d'une simplicité redoutable : il suffit d'envoyer une requête HTTP à n'importe quel endpoint de l'API Gitea ou de l'interface web en y ajoutant l'en-tête X-WEBAUTH-USER: admin (ou le nom de tout autre utilisateur existant). Gitea interprète cet en-tête comme une assertion d'identité provenant d'un proxy de confiance et ouvre immédiatement une session au nom du compte spécifié, sans aucune vérification de mot de passe, de token ou de second facteur. Ce comportement est classifié CWE-290 (Authentication Bypass by Spoofing) et CWE-1188 (Insecure Default Initialization of Resource). La complexité d'attaque est nulle, aucune authentification préalable n'est requise, et aucune interaction utilisateur n'est nécessaire, ce qui justifie pleinement le score CVSS maximal de 9.8.

Un attaquant exploitant CVE-2026-20896 dispose instantanément de tous les privilèges d'un administrateur Gitea. Depuis cette position, il peut exfiltrer l'intégralité du code source hébergé, créer des comptes backdoor persistants, modifier l'historique git via des force-push, accéder aux secrets et tokens stockés dans les variables d'environnement des dépôts, désactiver l'authentification à deux facteurs pour d'autres comptes, ou encore configurer des webhooks malveillants déclenchés à chaque push. Dans les architectures CI/CD intégrées — Jenkins, Drone CI, Woodpecker, pipelines auto-hébergés — la compromission de Gitea peut se propager à l'ensemble de la chaîne de compilation et déboucher sur une attaque de la chaîne d'approvisionnement logicielle (supply chain attack) si les artefacts produits sont distribués à des tiers.

Les chercheurs de Sysdig ont détecté la première tentative d'exploitation in-the-wild le 6 juillet 2026, émanant d'un nœud de sortie ProtonVPN identifié par l'adresse IP 159.26.98[.]241. À ce stade, les activités observées correspondaient à une phase de reconnaissance : l'acteur malveillant vérifiait la présence de la configuration vulnérable sans déclencher d'exploitation complète. Toutefois, compte tenu de l'existence de preuves de concept publiques, de la facilité d'exploitation (une seule ligne de commande curl suffit) et de l'intérêt démontré de la communauté offensive, une exploitation à grande échelle est considérée comme imminente par les analystes de Rescana et SecurityWeek.

La surface d'attaque exposée est significative. Des outils de cartographie Internet recensent environ 6 200 instances Gitea directement accessibles depuis Internet, ce qui sous-estime probablement la réalité en raison des déploiements intranet accessibles depuis des réseaux partiellement contrôlés ou depuis des postes de travail compromis. Les secteurs les plus à risque sont les entreprises technologiques, les équipes de développement logiciel, les laboratoires de recherche et les administrations publiques ayant choisi une infrastructure DevOps auto-hébergée pour des raisons de confidentialité ou de souveraineté des données.

Le correctif a été intégré dans Gitea 1.26.3, publiée fin juin 2026 selon l'advisory officiel Gitea Security Advisory 2026-06. Dans cette version, le wildcard * a été supprimé de la configuration par défaut de REVERSE_PROXY_TRUSTED_PROXIES, et l'authentification par reverse proxy est désormais désactivée par défaut (comportement opt-in). Un point de vigilance crucial : si vous avez mis à jour l'image Docker mais que vous montez un volume persistant contenant un ancien fichier app.ini, la configuration vulnérable peut subsister malgré la mise à jour. Une vérification manuelle du fichier de configuration reste indispensable après le patch. Les outils de détection ont été publiés par Tenable, Rapid7, SonicWall et runZero pour l'intégration dans les scanners de vulnérabilités.

Au moment de la rédaction, CVE-2026-20896 n'a pas encore été officiellement ajouté au catalogue KEV (Known Exploited Vulnerabilities) de la CISA, mais l'agence surveille la situation de près. Le CERT-FR a publié un avis de sécurité (CERTFR-2026-AVI-0214) recommandant l'application immédiate du correctif. Aucun contournement officiel autre que la mise à jour n'est disponible, hormis la désactivation manuelle de la fonctionnalité de proxy de confiance dans le fichier app.ini.

Impact et exposition

Toute organisation déployant Gitea via les images Docker officielles en version 1.26.2 ou antérieure est potentiellement exposée, dès lors que l'instance est accessible depuis un réseau non entièrement contrôlé. Les déploiements Gitea installés via les binaires natifs (hors Docker) avec une configuration manuelle ne sont généralement pas affectés, sauf si l'administrateur a explicitement défini REVERSE_PROXY_TRUSTED_PROXIES = * dans son app.ini. Les instances hébergées sur Gitea.com (service cloud officiel) ne sont pas concernées.

L'impact d'une exploitation va bien au-delà de la seule instance Gitea. Dans les architectures DevSecOps modernes, la plateforme de gestion de code constitue un nœud central : compromettre Gitea revient souvent à compromettre l'ensemble du cycle de vie logiciel. Les scénarios d'attaque les plus probables incluent l'injection de code malveillant dans les pipelines de build, l'exfiltration de propriété intellectuelle (code source propriétaire, algorithmes, configurations), la récupération de secrets de production (clés AWS/Azure/GCP, tokens OAuth, certificats TLS), et le pivot vers d'autres systèmes via les credentials stockés dans les webhooks ou les variables de CI/CD.

La rapidité de la réaction offensive — 13 jours entre la divulgation et le sondage actif — illustre l'efficacité croissante des processus de weaponization chez les acteurs malveillants. Pour des failles aussi simples à exploiter (aucun shellcode, aucune technique avancée, une seule requête HTTP), le délai entre la disponibilité d'un PoC public et l'exploitation généralisée peut se réduire à quelques heures. Les organisations n'ayant pas encore patché doivent considérer leurs instances Gitea Docker comme potentiellement compromises et procéder à un audit forensique en parallèle de l'application du correctif.

Recommandations immédiates

• Mettre à jour vers Gitea 1.26.3 — advisory : Gitea Security Advisory 2026-06
• Après la mise à jour, vérifier et corriger manuellement le fichier app.ini (chemin Docker typique : /data/gitea/conf/app.ini) : s'assurer que REVERSE_PROXY_TRUSTED_PROXIES n'est pas défini à * et désactiver la fonctionnalité si elle n'est pas utilisée (ENABLE_REVERSE_PROXY_AUTHENTICATION = false)
• Auditer les logs d'accès du serveur web frontal pour détecter toute requête contenant l'en-tête X-WEBAUTH-USER provenant d'adresses IP non autorisées
• Vérifier l'intégrité du code source dans tous les dépôts sensibles : commits non autorisés, branches inconnues, modifications de webhooks
• Mettre en place des règles WAF pour bloquer les requêtes contenant l'en-tête X-WEBAUTH-USER en provenance de sources extérieures aux proxies légitimes
• Indicateurs de compromission (IoC) : requêtes HTTP avec en-tête X-WEBAUTH-USER: admin dans les logs access ; IP 159.26.98[.]241 identifiée lors du premier sondage