CVE-2026-27771 : Gitea expose vos images container privees sans authentification — 30 000 serveurs touches

Le 27 mai 2026, la societe de securite NoScope a publie les details complets de CVE-2026-27771, une vulnerabilite critique dans le registre container integre de Gitea, l'alternative open source a GitHub la plus deployee au monde. Avec un score CVSS de 8.2 sur 10, cette faille permet a n'importe quel attaquant non authentifie de telecharger l'integralite des images container marquees comme privees — sans fournir le moindre identifiant. Pas d'exploit sophistique, pas de chaine d'attaque complexe : une simple requete docker pull vers l'endpoint du registre suffit pour exfiltrer du code proprietaire, des artefacts de build et des secrets embarques.

L'ampleur de l'exposition est vertigineuse. Selon les donnees relayees par The Hacker News, plus de 30 000 instances Gitea reparties dans plus de 30 pays sont potentiellement affectees. La faille etait presente depuis environ 4 ans dans le code source de Gitea, touchant des organisations dans les secteurs de la sante, de l'aerospatial, du retail et des telecommunications. Et ce qui rend la situation encore plus inquietante, c'est le mode de decouverte : ce n'est pas un chercheur humain qui a identifie la faille, mais un agent de pentest autonome propulse par l'IA, celui de NoScope, capable d'analyser des milliers d'endpoints API en quelques heures pour detecter des patterns d'autorisation defaillants.

Pour les developpeurs open source francais qui utilisent Gitea comme forge interne — que ce soit pour heberger du code source proprietaire, gerer des pipelines CI/CD ou stocker des images Docker de production — cette CVE est un signal d'alarme critique. Si votre instance Gitea est exposee sur Internet avec le registre container active, l'ensemble de vos images privees est potentiellement accessible a n'importe qui depuis des annees. Comme nous l'avions souligne dans notre analyse de la securisation des pipelines CI/CD open source, la supply chain container est l'un des maillons les plus fragiles de l'ecosysteme DevOps.

Anatomie technique de CVE-2026-27771

La vulnerabilite reside dans le module de registre container de Gitea, introduit pour permettre aux equipes de stocker et distribuer des images Docker (et OCI) directement depuis leur instance Gitea, sans dependre de Docker Hub ou d'un registre externe. Quand un utilisateur cree un depot marque comme prive et pousse une image container associee, Gitea est cense appliquer les memes regles d'acces au registre container qu'au depot lui-meme : seuls les utilisateurs authentifies avec les permissions adequates devraient pouvoir telecharger les images.

Le probleme est une incoherence dans la couche d'autorisation entre l'API Git standard de Gitea et l'API de registre container (compatible OCI Distribution Spec). Quand un client Docker envoie une requete GET /v2/<owner>/<repo>/manifests/<tag> pour recuperer le manifeste d'une image, le middleware d'authentification de Gitea ne verifie pas correctement si le depot associe est prive. Plus precisement, la verification de visibilite est effectuee au niveau du depot Git, mais le registre container utilise un chemin de code separe qui contourne cette verification et traite toutes les images comme publiques au moment de servir les blobs et les manifestes.

Concretement, la chaine d'exploitation est d'une trivialite alarmante. Un attaquant n'a besoin que de connaitre le nom du proprietaire et du depot — des informations souvent devinables ou enumerables via l'API publique de Gitea. Il execute ensuite :

# Etape 1 : Configurer le registre Gitea comme source
docker login gitea.example.com
# Annuler l authentification — l attaque fonctionne SANS credentials

# Etape 2 : Pull direct de l image privee
docker pull gitea.example.com/organisation/app-interne:latest

# Resultat : l image est telechargee sans aucune authentification
# Le registre renvoie les manifestes et blobs sans verifier les permissions

# Etape 3 : Extraire les secrets de l image
docker save gitea.example.com/organisation/app-interne:latest | tar -xf -
# Les layers contiennent potentiellement :
# - Variables d environnement avec cles API
# - Fichiers de configuration avec tokens
# - Code source proprietaire
# - Certificats TLS

Ce qui rend cette faille particulierement devastatrice, c'est la nature des donnees exposees. Les images container sont des artefacts de build complets qui contiennent non seulement le code compile de l'application, mais aussi toutes les dependances, les fichiers de configuration, et frequemment des secrets embarques. Malgre les bonnes pratiques qui recommandent de ne jamais embarquer de secrets dans les images Docker, la realite du terrain est que des milliers d'equipes continuent d'inclure des variables d'environnement sensibles directement dans leurs Dockerfiles ou via des COPY de fichiers .env.

Une decouverte par agent IA : le pentest autonome change la donne

L'un des aspects les plus remarquables de CVE-2026-27771 est son mode de decouverte. Ce n'est pas un chercheur en securite qui a passe des heures a lire le code source de Gitea ou a fuzzer ses endpoints. C'est l'agent de penetration testing autonome de NoScope qui a identifie la faille en avril 2026, au cours d'un scan systematique des API de registres container open source. L'agent IA a analyse des milliers de combinaisons d'endpoints, de methodes HTTP et de configurations d'autorisation, detectant automatiquement que les requetes non authentifiees vers l'API OCI du registre Gitea retournaient des donnees qui auraient du etre protegees.

Cette decouverte marque un tournant dans le paysage de la securite open source. Les agents de pentest autonomes sont capables de tester des scenarios d'autorisation a une echelle et une vitesse impossibles pour un humain. Alors qu'un auditeur humain aurait pu passer a cote de cette incoherence entre l'API Git et l'API container — parce que les deux systemes semblent fonctionner correctement pris individuellement — l'agent IA a detecte la divergence de comportement entre un depot marque prive et son registre container associe. C'est exactement le type de faille qui echappe aux audits traditionnels : chaque composant fonctionne « comme prevu » en isolation, mais leur composition cree une breche de securite.

Impact geographique et sectoriel : 30 000 serveurs dans 30+ pays

Les donnees de scan collectees par NoScope revelent une exposition massive. Plus de 30 000 instances Gitea accessibles depuis Internet ont ete identifiees a travers le monde, reparties dans plus de 30 pays. Si toutes n'ont pas necessairement le registre container active, les scans montrent qu'une proportion significative utilise cette fonctionnalite pour stocker des images Docker internes.

Les secteurs les plus touches sont ceux qui privilegient l'auto-hebergement pour des raisons de conformite ou de souverainete des donnees — ce qui est ironique, car c'est precisement cette volonte de controler ses donnees qui les a exposees. Le secteur sante utilise Gitea pour heberger des applications de gestion de donnees patients, avec des images container contenant potentiellement des informations medicales protegees (donnees RGPD sensibles). L'aerospatial et la defense utilisent des forges Gitea internes pour des projets classifies ou sensibles. Le retail deploie Gitea pour ses plateformes e-commerce sur mesure. Et de nombreux FAI et hebergeurs fournissent des instances Gitea mutualisees a leurs clients.

En France specifiquement, on estime entre 1 500 et 2 500 instances Gitea exposees sur Internet. Beaucoup sont deployees par des PME, des ESN (Entreprises de Services Numeriques), des laboratoires de recherche et des collectivites territoriales qui ont choisi Gitea pour sa legerete et sa capacite a tourner sur des serveurs modestes. L'ironie est que ces organisations ont souvent choisi l'auto-hebergement precisement pour garder le controle de leurs donnees, sans realiser que le registre container de leur forge privee etait ouvert a tous.

Versions affectees vs. corrigees : tableau comparatif

Le tableau suivant recapitule les versions de Gitea affectees par CVE-2026-27771 et les correctifs disponibles. La regle est simple : toute version anterieure a 1.26.2 est vulnerable si le registre container integre est active.

Un point important : Forgejo, le fork communautaire de Gitea, partage la meme base de code pour le registre container. Les utilisateurs de Forgejo doivent verifier aupres de leur projet si un patch equivalent a ete applique. Au moment de la publication de cet article, Forgejo n'a pas encore publie d'advisory specifique.

Ce que ca signifie pour vous

Si vous gerez une instance Gitea en France — que ce soit pour une startup, une PME, un laboratoire de recherche ou une collectivite — cette CVE a des implications directes et concretes sur votre securite. Voici les scenarios les plus critiques et les actions a entreprendre.

Scenario 1 : Vous utilisez le registre container de Gitea en production

C'est le cas le plus urgent. Toutes les images que vous avez poussees dans le registre container de votre Gitea depuis son activation ont potentiellement ete accessibles sans authentification. Cela inclut le code source compile, les fichiers de configuration, les variables d'environnement et les secrets embarques dans les layers Docker. Votre action immediate :

1. Mise a jour vers Gitea 1.26.2 dans l'heure
2. Audit des logs d'acces du registre container pour les 4 dernieres annees
3. Rotation de tous les secrets presents dans vos images (cles API, tokens, certificats)
4. Scan de vos images avec trivy ou grype pour identifier les secrets embarques

Scenario 2 : Vous utilisez Gitea mais pas le registre container

Vous n'etes pas directement affecte par CVE-2026-27771, mais mettez quand meme a jour vers 1.26.2. Les versions anterieures pourraient contenir d'autres vulnerabilites non encore divulguees. Verifiez egalement que le registre container est bien desactive dans votre app.ini :

# app.ini — section packages
[packages]
ENABLED = false

# Ou plus specifiquement pour le registre container
[packages.container]
ENABLED = false

Scenario 3 : Vous envisagez de migrer vers Gitea

Ne renoncez pas a Gitea a cause de cette CVE. C'est un projet open source mature avec une communaute active et un processus de reponse aux vulnerabilites qui fonctionne. Mais integrez la securite du registre container dans votre plan de deploiement des le depart. Deployez Gitea derriere un reverse proxy avec authentification, limitez l'acces au registre container aux reseaux internes, et configurez des scans d'images automatises dans votre pipeline CI/CD.

Remediation complete : les 5 actions a mener

La remediation de CVE-2026-27771 ne se limite pas a une simple mise a jour de version. Etant donne la duree d'exposition (~4 ans), il faut considerer l'ensemble des donnees qui ont pu etre exfiltrees et agir en consequence.

Action 1 : Mise a jour vers Gitea 1.26.2

C'est la priorite absolue. La mise a jour corrige le bypass d'authentification dans l'API OCI du registre container. Pour les deployements Docker :

# Mise a jour de l image Docker Gitea
docker pull gitea/gitea:1.26.2

# Arreter et supprimer l ancien container
docker stop gitea && docker rm gitea

# Relancer avec la nouvelle version
docker run -d --name gitea \
  -p 3000:3000 -p 2222:22 \
  -v /data/gitea:/data \
  -v /etc/timezone:/etc/timezone:ro \
  gitea/gitea:1.26.2

# Verifier la version
docker exec gitea gitea --version
# Gitea version 1.26.2 built with ...

Action 2 : Audit des logs du registre container

Analysez les logs d'acces pour identifier d'eventuels pulls non autorises. Recherchez les requetes vers l'API /v2/ sans token d'authentification valide :

# Rechercher les acces non authentifies au registre
grep -E "GET /v2/.*/manifests|GET /v2/.*/blobs" /var/log/gitea/access.log \
  | grep -v "Authorization:" \
  | awk '{print $1, $4, $7}' \
  | sort | uniq -c | sort -rn | head -50

Action 3 : Rotation des secrets

Tout secret present dans une image container privee doit etre considere comme compromis. Utilisez trivy pour scanner vos images et identifier les secrets embarques, puis effectuez une rotation systematique.

Action 4 : Durcissement de l'acces reseau

Meme apres le patch, limitez l'acces au registre container de Gitea aux reseaux de confiance. Deployez un reverse proxy avec authentification supplementaire et restreignez les IP sources autorisees.

Action 5 : Monitoring continu

Mettez en place des alertes pour detecter les acces anormaux au registre container. Configurez Dependabot ou Renovate pour etre alerte des prochaines mises a jour de securite Gitea. Pour aller plus loin, consultez notre guide complet sur la securisation des pipelines CI/CD open source.

Implications pour la supply chain container

CVE-2026-27771 s'inscrit dans une tendance plus large de vulnerabilites ciblant la supply chain container. Les registres d'images Docker sont devenus un maillon critique de l'infrastructure logicielle moderne, et leur securisation est souvent negligee par rapport a celle du code source ou des pipelines CI/CD. En 2026, la majorite des equipes de developpement utilisent des images container comme format de livraison — mais combien d'entre elles auditent regulierement les controles d'acces de leurs registres ?

Cette CVE rejoint une serie d'incidents recents qui ciblent les artefacts de build plutot que le code source directement. Que ce soit les attaques supply chain sur npm que nous avons analysees dans notre article sur la securisation des pipelines npm, ou les compromissions de registres PyPI, le pattern est clair : les attaquants se deplacent vers les points de la chaine de livraison ou les controles de securite sont les plus faibles. Et les registres container auto-heberges, souvent deployes sans audit de securite approfondi, sont une cible de choix.

Pour les equipes francaises soumises aux exigences de NIS2 et DORA, cette CVE a des implications reglementaires directes. Les deux textes imposent aux organisations de maintenir un inventaire des actifs numeriques, de gerer les vulnerabilites dans des delais definis, et de notifier les incidents de securite. Une exposition de 4 ans de donnees proprietaires via un registre container non securise pourrait etre consideree comme un manquement aux obligations de diligence, surtout si l'organisation n'avait pas mis en place de processus d'audit regulier de ses outils d'infrastructure.

Lecons de securite pour les registres container open source

Au-dela de Gitea, CVE-2026-27771 offre des lecons applicables a tout registre container open source — qu'il s'agisse de Harbor, du registre integre de GitLab, de Docker Registry ou de solutions comme Quay. Voici les principes de securite que chaque equipe DevOps devrait appliquer.

Principe 1 : Ne jamais faire confiance au controle d'acces par defaut. Testez systematiquement les permissions de votre registre en tentant un docker pull sans authentification depuis une machine externe. C'est le test le plus simple et le plus efficace pour detecter un bypass d'authentification.

Principe 2 : Defense en profondeur. Le controle d'acces applicatif ne doit pas etre votre seule ligne de defense. Ajoutez un reverse proxy (NGINX, Caddy, Traefik) avec authentification supplementaire, et restreignez l'acces reseau au registre aux seuls CIDR autorises.

Principe 3 : Ne jamais embarquer de secrets dans les images. Utilisez des gestionnaires de secrets (Vault, AWS Secrets Manager, Doppler) et injectez les secrets au runtime via des variables d'environnement ou des volumes montes. Scannez chaque image avec trivy ou gitleaks avant le push pour detecter les fuites accidentelles.

Principe 4 : Auditer regulierement. Integrez un audit de votre registre container dans votre cycle de securite trimestriel. Verifiez les permissions, les acces, les images obsoletes, et les secrets embarques. Pour un guide complet, consultez notre article compagnon : comment auditer la securite de vos registres container open source en 7 etapes.

FAQ