CVE-2026-27771 : faille dans Gitea, 30 000 registres exposés

Quatre ans d'exposition silencieuse dans le registre de conteneurs Gitea

Les chercheurs en sécurité d'Orca Security et de Noscope ont divulgué le 27 mai 2026 une vulnérabilité critique dans le registre de conteneurs intégré à Gitea, l'une des plateformes de gestion de code source auto-hébergées les plus utilisées dans le monde. Identifiée CVE-2026-27771 et évaluée à 8.2 sur l'échelle CVSS, cette faille permet à n'importe quel individu — sans compte, sans mot de passe, sans token d'accès — de télécharger l'intégralité des images Docker stockées dans un dépôt pourtant configuré en mode privé.

L'analyse technique révèle un défaut fondamental dans le modèle de contrôle d'accès du registre OCI (Open Container Initiative) de Gitea. Lorsqu'un utilisateur marque un dépôt comme privé, l'interface web et l'API Git appliquent correctement les restrictions d'authentification : seuls les utilisateurs autorisés peuvent consulter le code source ou cloner le dépôt. Cependant, les endpoints API du registre de conteneurs — ceux qui répondent aux commandes docker pull et aux appels OCI standards — ne vérifiaient pas ces mêmes autorisations. Un simple appel HTTP anonyme vers /v2/<owner>/<repo>/manifests/<tag> suffisait à récupérer le manifeste complet de l'image, puis à télécharger toutes les couches (layers) sans la moindre accréditation.

Ce qui rend cette découverte particulièrement grave est la durée d'exposition. Selon les chercheurs de Noscope, le bug est présent dans le code Gitea depuis au moins août 2022, soit près de quatre années d'exposition silencieuse. Pendant toute cette période, les images de conteneurs marquées privées n'offraient en réalité aucune protection contre un accès non authentifié via le protocole de registre OCI. Aucune alerte de sécurité, aucun CVE préalable, aucune divulgation partielle n'avait signalé cette exposition dans les canaux habituels de la communauté sécurité.

La cartographie des instances vulnérables dressée par Noscope révèle une exposition mondiale considérable : plus de 30 000 déploiements Gitea actifs et accessibles depuis Internet dans plus de 31 pays. La concentration géographique place la Chine en tête, suivie des États-Unis, de l'Allemagne, de la France et du Royaume-Uni. Les secteurs impactés sont particulièrement sensibles : établissements de santé stockant des images d'applications médicales ou de gestion de dossiers patients, fabricants aérospatiaux hébergeant des images de systèmes embarqués, opérateurs retail gérant des applications de point de vente, et fournisseurs d'accès Internet développant des images d'infrastructure réseau.

Les données réellement à risque dans ces images de conteneurs sont souvent bien plus sensibles que le simple code source. Les images Docker construites dans des pipelines DevOps professionnels intègrent fréquemment des variables d'environnement définies au moment de la construction : clés d'API pour des services tiers, chaînes de connexion à des bases de données de production, tokens d'authentification pour des registres cloud, certificats TLS et clés privées, ou encore configurations réseau internes. Même sans secret explicite, la liste précise des dépendances et de leurs versions facilite considérablement l'identification de vulnérabilités connues dans l'environnement cible d'une attaque ultérieure.

L'aspect particulièrement préoccupant de cette vulnérabilité est son invisibilité dans les journaux de sécurité. Les chercheurs d'Orca Security ont démontré qu'une exploitation réussie ne génère aucune entrée dans les logs d'authentification Gitea, puisqu'aucune tentative de connexion n'est effectuée : la requête se présente comme un simple appel anonyme ordinaire vers l'API du registre. Une organisation disposant d'une surveillance SIEM active n'aurait donc vraisemblablement reçu aucune alerte sur d'éventuelles extractions d'images pendant les quatre dernières années. La reconstruction forensique d'une exfiltration sera difficile voire impossible sans analyse des logs réseau bruts de l'infrastructure.

La réponse de l'équipe Gitea a suivi un processus de divulgation responsable. Informés par les chercheurs dans les semaines précédant la publication, les développeurs de Gitea ont corrigé le bug dans la version 1.26.2, publiée le 26 mai 2026. Le correctif consiste à aligner la logique de vérification des droits d'accès des endpoints du registre OCI sur celle déjà appliquée aux endpoints de l'API Git et à l'interface web. Pour les administrateurs qui ne peuvent pas appliquer le patch immédiatement, un contournement est disponible : la directive [service].REQUIRE_SIGNIN_VIEW=true dans le fichier app.ini force l'authentification pour toutes les requêtes entrantes, y compris celles destinées au registre de conteneurs.

Au moment de la publication, la CISA américaine n'avait pas encore ajouté CVE-2026-27771 à son catalogue KEV (Known Exploited Vulnerabilities), mais plusieurs chercheurs estiment que l'exploitation active est imminente compte tenu de la facilité de l'attaque et de la disponibilité d'une preuve de concept fonctionnelle publiée par Orca Security. Le NVD/NIST est en cours de finalisation de l'entrée officielle. Les organisations utilisant Gitea comme registre de conteneurs dans des environnements exposés à Internet sont invitées à traiter ce patch en priorité absolue, sans attendre la confirmation d'une exploitation dans la nature.

Un angle mort structurel dans la sécurité des outils DevOps auto-hébergés

Cette vulnérabilité met en lumière un angle mort récurrent dans la sécurité des outils DevOps auto-hébergés. Les grandes plateformes SaaS — GitHub, GitLab.com, Bitbucket — bénéficient d'équipes de sécurité dédiées, de programmes de bug bounty actifs, et d'un niveau de scrutin permanent de la part de la communauté de recherche en sécurité. Les solutions auto-hébergées comme Gitea ou Forgejo reposent sur des communautés open source aux ressources plus limitées pour les audits de sécurité approfondis, ce qui crée une surface d'attaque moins visible mais potentiellement plus étendue dans les entreprises qui les déploient sans équipe de sécurité dédiée.

Le registre de conteneurs OCI est une fonctionnalité relativement récente dans Gitea, introduite aux alentours de 2022. Ce timing correspond précisément au début de la fenêtre d'exposition identifiée par Noscope. C'est un schéma récurrent dans les projets open source qui ajoutent rapidement des capacités avancées — registres d'artefacts, CI/CD intégré, wikis collaboratifs — sans soumettre ces nouvelles fonctionnalités au même niveau de revue de sécurité que les composants historiques. Selon les chercheurs d'Orca Security, le problème aurait pu être détecté par un test de régression basique vérifiant que les politiques de confidentialité définies pour un dépôt s'appliquent uniformément à l'ensemble de ses endpoints d'accès.

Pour les entreprises ayant intégré Gitea dans leur pipeline DevSecOps, l'impact est potentiellement grave au regard des réglementations actuelles. Les images de conteneurs constituent aujourd'hui le vecteur principal de livraison applicative dans les environnements cloud-native. Une exfiltration d'images privées peut révéler suffisamment d'informations pour faciliter une attaque ciblée ultérieure, constituer une fuite de données au sens du RGPD si des données personnelles transitent indirectement dans les configurations d'applications, ou démontrer une insuffisance dans les mesures de sécurité lors d'un audit NIS2. Les organisations des secteurs régulés — santé, finance, énergie — sont particulièrement exposées à ces implications réglementaires.

Le Cyber Resilience Act européen, qui commence à s'appliquer à partir de septembre 2026, imposera aux éditeurs de produits numériques — y compris les logiciels open source utilisés à des fins commerciales — des obligations de signalement des vulnérabilités activement exploitées. Cette faille Gitea anticipe précisément le type de situation que ce règlement cherche à encadrer : une vulnérabilité dans un composant logiciel largement déployé, restée inconnue pendant plusieurs années, et susceptible d'exploitation massive à grande échelle. Les organisations utilisant Gitea dans des contextes régulés ont tout intérêt à documenter leurs actions de remédiation pour démontrer leur conformité lors d'un prochain audit.

Ce qu'il faut retenir

• Mettre à jour Gitea vers la version 1.26.2 immédiatement ; activer REQUIRE_SIGNIN_VIEW=true comme contournement d'urgence si la mise à jour est impossible à court terme.
• Auditer les logs réseau (pare-feu, reverse proxy) pour détecter des appels anonymes vers /v2/ sur le port Gitea depuis des IP externes sur les 4 dernières années.
• Procéder à une rotation préventive de tous les secrets susceptibles d'avoir été intégrés dans des images stockées sur une instance Gitea exposée : tokens API, credentials de bases de données, certificats TLS.