Gitea CVE-2026-20896 : un contournement d'authentification en un header, livré dans l'image Docker officielle
> En bref : CVE-2026-20896 est un contournement d'authentification critique (CVSS 9.8) dans l'image Docker officielle de Gitea. L'image livrait REVERSE_PROXY_TRUSTED_PROXIES=*, donc quand l'authentification reverse-proxy était activée, Gitea faisait confiance au header X-WEBAUTH-USER depuis n'importe quelle IP source. Un client Internet non authentifié devenait n'importe quel utilisateur — y compris admin. Exploitation active. Correctif : Gitea 1.26.3 et 1.26.4.
Pourquoi ça vous concerne
Gitea est l'alternative auto-hébergée à GitHub/GitLab que beaucoup d'équipes SaaS utilisent pour le code source, les pull requests et la CI/CD. Environ 6 200 instances sont exposées sur Internet. Si votre équipe auto-héberge Gitea en Docker — pour la souveraineté, le coût, ou pour garder le code hors du SaaS US — cette CVE est une prise de contrôle directe, non authentifiée, niveau admin, de votre code source.
Et la cause racine est un truc que toute équipe qui fait tourner des conteneurs devrait intérioriser : une configuration par défaut pratique en développement et catastrophique en production.
La faille en deux phrases
L'authentification reverse-proxy est une fonctionnalité Gitea légitime : on met Gitea derrière un proxy qui authentifie les utilisateurs et fait suivre leur identité dans le header X-WEBAUTH-USER, et Gitea lui fait confiance. Le mécanisme est sûr *si et seulement si* Gitea n'accepte ce header que depuis l'IP du proxy de confiance.
L'image Docker officielle livrait REVERSE_PROXY_TRUSTED_PROXIES=*. Ce joker signifie : faire confiance au header d'identité depuis n'importe quelle source. Donc n'importe quel client qui peut joindre le port HTTP du conteneur directement — en contournant le proxy authentifiant — peut mettre X-WEBAUTH-USER: admin et devenir admin. Aucun mot de passe, aucun token, un header. Sysdig a capté le premier scan in-the-wild 13 jours après l'advisory, un scanner depuis une sortie VPN qui récupérait l'accès.
Le pattern : confiance sans scopage
Ce bug est l'équivalent infrastructure du bug JWT que l'on voit en code applicatif : un claim d'identité est trusté sans vérifier qui l'a envoyé. Le même anti-pattern revient dans :
X-Forwarded-For pour récupérer la « vraie » IP client sans valider la chaîne de proxies.X-User-Id, X-Email) depuis une gateway, mais joignables en dehors de la gateway.Dans tous les cas, le correctif est identique : énumérer explicitement les sources de confiance, jamais de joker pour la confiance.
Ce qu'il faut faire
REVERSE_PROXY_TRUSTED_PROXIES aux IP/CIDR explicites de votre reverse proxy — pas *. Si vous n'utilisez pas réellement l'auth reverse-proxy, désactivez-la complètement.X-WEBAUTH-USER suspecte, de changements de privilèges, de nouveaux comptes admin ou de clés SSH inconnues ajoutées depuis l'advisory. La CSA singapourienne a émis une alerte — traitez la compromission comme plausible tant que les logs ne disent pas le contraire.L'angle supply chain
Pour un éditeur SaaS, une compromission de serveur Git auto-hébergé est l'un des scénarios les plus lourds : elle donne à l'attaquant votre code source et votre pipeline CI/CD en un seul mouvement. C'est le pattern SolarWinds à l'échelle d'une équipe. Si vous auto-hébergez Gitea (ou GitLab, ou Forgejo), cette CVE est le déclencheur pour le traiter comme une infrastructure de grade production : versions pinées, defaults revus, isolation réseau, et le même SLA de patch que vous appliquez à vos serveurs applicatifs.
Vous éditez un logiciel RH, paie ou recrutement ? CleanIssue réalise des audits de sécurité pour SaaS RH en conditions réelles, sans accès au code. Pour une première lecture de votre exposition, commencez par une revue externe de votre application.
Articles liés
Trois analyses proches pour continuer la lecture sur la meme surface de risque.
Nexus Repository et CVE-2026-0600 : pourquoi la configuration proxy devient une surface d attaque
CVE-2026-0600 touche Nexus Repository 3 via une SSRF dans la configuration des repositories proxy. Voici pourquoi ce sujet est critique pour les équipes supply chain.
WordPress CVE-2026-8206 : prise de contrôle admin sans authentification via le plugin Kirki
Le plugin WordPress Kirki (6.0.0 à 6.0.6) laisse un attaquant non authentifié prendre le contrôle d'un compte administrateur via un reset de mot de passe défaillant. CVSS 9.8, exploitation active, ~150 000 sites exposés. Correctif : 6.0.7.
Langflow CVE-2026-55255 : un contournement d'auth sur les workflows d'agents IA, désormais au KEV CISA
Une IDOR (CVSS 9.8) dans Langflow, le framework visuel de construction d'agents IA, permet à un attaquant authentifié d'accéder aux flows d'autres utilisateurs via l'endpoint /api/v1/responses avec l'UUID de la victime. Exploitée depuis le 25 juin 2026. KEV CISA avec un délai d'une semaine.
Sources
Services associés
Si ce sujet reflète un risque concret sur votre stack, voici les audits CleanIssue les plus pertinents.