Sécurité 14 juillet 2026 à 17:45

Collaborer avec mon assistant IA :

Faille Gitea Docker : CVE-2026-20896 permet d'usurper un utilisateur via un en-tête HTTP

CVE-2026-20896 affecte les images Docker officielles de Gitea jusqu'en 1.26.2. Avec l'authentification reverse proxy activée, un attaquant peut se faire passer pour un utilisateur, y compris administrateur.

Illustration d'une alerte de sécurité sur une faille critique Gitea Docker

Dans le cadre de notre veille sécurité, nous signalons une vulnérabilité critique dans les images Docker officielles de Gitea, la forge Git open source auto-hébergée.

CVE-2026-20896 permet à un attaquant de se faire passer pour n’importe quel utilisateur — potentiellement un administrateur — en envoyant un en-tête HTTP forgé. La vulnérabilité est notée 9,8/10 (CVSS) et fait l’objet de signaux d’exploitation active.

Le sujet ne concerne pas toutes les installations Gitea. Il vise les images Docker jusqu’à 1.26.2 lorsque l’authentification via reverse proxy est activée et que le port HTTP du conteneur reste directement joignable. C’est précisément le type de détail de déploiement qui transforme une mise à jour en incident potentiel.

CVE-2026-20896 : le défaut de confiance dans l’image Docker Gitea

Gitea peut déléguer l’authentification à un reverse proxy ou à une brique SSO. Dans ce modèle, le proxy authentifie l’utilisateur puis transmet son identité à Gitea, notamment via l’en-tête X-WEBAUTH-USER.

Ce mécanisme n’est sûr que si Gitea accepte cet en-tête uniquement lorsqu’il provient du reverse proxy attendu.

Or, les images Docker officielles vulnérables embarquaient dans leur modèle de configuration :

REVERSE_PROXY_TRUSTED_PROXIES = *

Le caractère * revient à faire confiance à toute adresse IP. Si ENABLE_REVERSE_PROXY_AUTHENTICATION est activé et qu’un attaquant peut atteindre directement le port HTTP de Gitea, il peut fournir un X-WEBAUTH-USER correspondant à un nom de compte connu ou devinable.

Il n’a alors besoin ni du mot de passe, ni d’un jeton, ni d’une session existante.

Pourquoi cette faille Gitea est critique

Une forge Git ne contient pas seulement du code source. Elle concentre souvent des éléments très sensibles :

dépôts privés et historique de développement ;
clés de déploiement et clés SSH ;
jetons d’accès personnels et jetons d’automatisation ;
variables et secrets CI/CD ;
webhooks, intégrations et registres de conteneurs ;
comptes administrateurs capables de modifier les droits et la configuration.

L’impact dépend des permissions du compte usurpé. Un compte administrateur peut ouvrir l’accès à l’ensemble de l’instance ; un compte développeur peut déjà suffire à lire du code privé, récupérer des secrets exposés par erreur ou modifier une chaîne de livraison.

Cette vulnérabilité rappelle une règle importante en infrastructure : un reverse proxy ne protège pas une application si celle-ci reste accessible en contournant le proxy.

Les installations réellement concernées par CVE-2026-20896

Les conditions d’exposition documentées sont les suivantes :

Condition	Pourquoi elle compte
Image Docker Gitea en version 1.26.2 ou antérieure	Le modèle `app.ini` vulnérable est fourni par ces images.
Authentification reverse proxy activée	C’est ce qui rend l’en-tête d’identité utilisable par Gitea.
`REVERSE_PROXY_TRUSTED_PROXIES = *`	Toute source est alors considérée comme un proxy de confiance.
Port HTTP Gitea joignable sans passer par le proxy	L’attaquant peut injecter directement l’en-tête d’identité.

Les installations binaires et les déploiements compilés qui utilisent le modèle app.example.ini documenté ne sont pas touchés par ce défaut Docker. Cela ne dispense pas de vérifier la configuration effective : une configuration personnalisée trop permissive produirait le même risque.

Vérifier rapidement son déploiement Gitea Docker

Commencez par identifier l’image et le service réellement utilisés. Dans un projet Docker Compose, adaptez gitea au nom de votre service :

docker compose ps
docker compose exec gitea gitea --version
docker compose config | grep -A 12 -B 2 'image:.*gitea'

Contrôlez ensuite la configuration effective. L’emplacement peut varier selon l’image et le volume de données ; sur l’image officielle, il se trouve généralement sous /data/gitea/conf/app.ini :

docker compose exec gitea sh -lc "grep -nE '^(ENABLE_REVERSE_PROXY_AUTHENTICATION|REVERSE_PROXY_TRUSTED_PROXIES)[[:space:]]*=' /data/gitea/conf/app.ini"

Deux vérifications sont indispensables :

ENABLE_REVERSE_PROXY_AUTHENTICATION est-il activé ?
La liste REVERSE_PROXY_TRUSTED_PROXIES contient-elle *, ou une plage bien plus large que les adresses réelles de vos proxies ?

Enfin, regardez votre compose.yml, vos règles pare-feu et votre reverse proxy. Une publication telle que 0.0.0.0:3000:3000 ou 3000:3000 peut rendre le port directement accessible selon l’hôte et son filtrage réseau. Le bon chemin d’accès doit être : Internet → reverse proxy → réseau applicatif interne → Gitea.

Remédiation : mettre à jour et fermer le chemin direct

Le correctif durable consiste à mettre à jour vers la dernière version stable de Gitea. Pour la branche 1.26, Gitea recommande de passer directement à 1.26.4, qui inclut le correctif de CVE-2026-20896 et un correctif supplémentaire apporté après 1.26.3.

Dans votre fichier Compose, utilisez un tag explicite et corrigé, puis recréez le service après avoir sauvegardé les données et testé la procédure sur un environnement de préproduction si votre forge est critique :

services:
  gitea:
    image: gitea/gitea:1.26.4

docker compose pull gitea
docker compose up -d gitea
docker compose exec gitea gitea --version

Ne vous arrêtez pas à la mise à jour. Si l’authentification reverse proxy est nécessaire, définissez explicitement les seules adresses ou sous-réseaux de vos proxies de confiance dans app.ini. L’adresse à autoriser est celle vue par Gitea, souvent l’adresse du conteneur proxy sur le réseau Docker, et non son adresse publique.

[security]
REVERSE_PROXY_TRUSTED_PROXIES = 172.20.0.10/32

Cette adresse est un exemple : elle doit être remplacée par celle de votre proxy. Évitez le joker * et les plages larges par facilité. Après une modification de app.ini, redémarrez Gitea puis testez le parcours d’authentification normal et le refus des accès directs.

En parallèle, supprimez l’exposition directe du port Gitea lorsqu’elle n’est pas nécessaire. Un proxy déployé sur le même réseau Docker peut joindre le service par son nom sans publication de 3000. Si le proxy tourne sur l’hôte, une écoute liée à 127.0.0.1 est généralement préférable à une écoute sur toutes les interfaces, sous réserve de votre architecture.

Si la mise à jour doit attendre

La mise à jour reste prioritaire, d’autant plus que l’exploitation est signalée. Si une contrainte métier impose un délai, les mesures suivantes réduisent l’exposition sans remplacer le patch :

remplacez immédiatement REVERSE_PROXY_TRUSTED_PROXIES = * par les IP ou CIDR exacts des proxies de confiance ;
bloquez tout accès direct au port HTTP du conteneur depuis Internet et les réseaux non nécessaires ;
limitez temporairement l’accès à l’interface via VPN, filtrage IP ou réseau d’administration ;
vérifiez que les en-têtes d’identité sont retirés par le proxy sur les requêtes entrantes, puis posés seulement après authentification ;
documentez la dérogation et planifiez le passage vers une image corrigée.

Une configuration de confiance explicite est une mesure de confinement. Elle ne doit pas devenir le prétexte pour rester sur une image vulnérable.

Rechercher une compromission avant de refermer le sujet

Comme l’usurpation peut viser un administrateur, il faut traiter toute exposition plausible comme une investigation, pas comme une simple opération de patch.

Contrôlez notamment :

les journaux du reverse proxy et de Gitea pour des requêtes directes ou des en-têtes X-WEBAUTH-USER inattendus ;
les connexions, créations de comptes, élévations de privilèges et modifications de clés SSH ;
les nouveaux jetons d’accès, applications OAuth, webhooks et clés de déploiement ;
les accès inhabituels aux dépôts privés et aux registres ;
les exécutions CI/CD ou changements de configuration non expliqués.

Si vous identifiez une exposition directe ou un accès suspect, conservez les journaux avant rotation, désactivez les sessions et jetons douteux, révoquez les clés concernées et faites tourner les secrets susceptibles d’avoir été lus : tokens, clés de déploiement, credentials CI/CD, mots de passe applicatifs et clés cloud.

Ce que nous retenons pour les infrastructures auto-hébergées

Cette faille ne vient pas d’un manque de sophistication chez l’attaquant. Elle exploite une confiance implicite dans une valeur par défaut d’image Docker.

Sur une application sensible, la configuration livrée par une image doit être considérée comme du code de production : versionnée, relue, contrôlée après déploiement et surveillée. Les principes restent simples : pas de port applicatif exposé sans nécessité, séparation claire entre proxy et application, listes de confiance minimales et mises à jour suivies.

Chez Forget About IT, ce travail fait partie de l’exploitation : qualification de l’exposition, correctif, durcissement, contrôle des journaux et traçabilité. L’objectif n’est pas seulement d’appliquer un patch, mais de vérifier que l’architecture ne laisse pas le même chemin ouvert demain.

Sources

FAQ : faille Gitea Docker CVE-2026-20896

Quelles versions de Gitea sont touchées par CVE-2026-20896 ?

Les images Docker officielles de Gitea jusqu’en version 1.26.2 sont concernées. Les distributions binaires et les déploiements construits depuis les sources ne sont pas affectés par ce défaut de modèle Docker.

La faille Gitea Docker est-elle exploitable sur toutes les instances ?

Non. Le scénario documenté exige que l’authentification par reverse proxy soit activée et qu’un attaquant puisse atteindre directement le port HTTP de Gitea sans passer par le proxy de confiance. Ces conditions doivent toutefois être vérifiées immédiatement.

Quelle est la correction recommandée pour CVE-2026-20896 ?

Mettre à jour l’image Gitea vers la dernière version stable disponible, au minimum 1.26.4 pour la branche 1.26, puis contrôler que REVERSE_PROXY_TRUSTED_PROXIES ne contient pas le joker *.

Faut-il changer les secrets après avoir corrigé Gitea ?

Si l’instance a pu être exposée, il faut investiguer avant de conclure : journaux, comptes administrateurs, clés SSH, jetons API, applications OAuth, dépôts privés et secrets de CI/CD. La rotation des secrets sensibles est à prévoir en cas de doute sérieux.