Sécuriser Gitea est devenu une urgence pour les PME-ETI qui hébergent leur code en interne : plus de 8 300 instances exposées sur Internet restent vulnérables à une faille d’exécution de code à distance. Une forge Git compromise, c’est l’intégralité de votre propriété intellectuelle, vos secrets de build et vos pipelines de déploiement offerts à l’attaquant en une seule opération.
Ce tutoriel détaille les étapes concrètes pour identifier votre exposition, appliquer le correctif et durcir durablement votre instance.
Pourquoi sécuriser Gitea est prioritaire pour une PME-ETI
Gitea séduit les équipes techniques françaises pour de bonnes raisons : léger, auto-hébergeable, sans coût de licence par utilisateur. Mais cette simplicité de déploiement a un revers : l’instance est souvent installée par un développeur, publiée derrière un reverse proxy, puis oubliée du cycle de patch.
Or une forge Git n’est pas un outil secondaire. Elle concentre :
- le code source de vos produits et de vos intégrations clients ;
- les jetons CI/CD et clés de déploiement stockés en variables de runner ;
- les clés SSH de vos développeurs, avec leurs droits sur la production ;
- l’historique complet, où dorment souvent des secrets commités par erreur.
Une exécution de code à distance sur cette machine donne à l’attaquant un accès en écriture aux dépôts. Il n’a plus besoin de voler des identifiants : il injecte sa charge dans un workflow, et votre propre chaîne de build la déploie en production. C’est le scénario de supply chain interne, celui que nous décrivions déjà dans notre article sur les workflows de code sécurisés.
Étape 1 : inventorier et détecter votre exposition
Identifier la version installée
La version est affichée en pied de page de l’interface web, mais la source fiable reste le binaire :
- en installation native :
gitea --version; - en conteneur :
docker exec gitea gitea --version; - à distance, sans authentification : l’endpoint
/api/v1/versionrenvoie la version — ce qui signifie aussi qu’un attaquant peut cartographier vos instances vulnérables en quelques secondes.
Vérifier ce qui est réellement joignable
Beaucoup d’équipes croient leur forge interne alors qu’un port a été ouvert « temporairement ». Depuis l’extérieur de votre réseau, testez le port HTTP(S) et le port SSH de Gitea (3000 et 22 par défaut). Si l’interface répond depuis Internet sans VPN, vous êtes dans la population des 8 300 instances à risque.
Étape 2 : appliquer le correctif sans casser la production
La mise à jour de Gitea est simple, mais elle touche une base de données. L’ordre compte :
- Sauvegardez d’abord :
gitea dumpproduit une archive contenant la base, les dépôts et la configuration. Vérifiez que l’archive n’est pas vide avant de continuer. - Arrêtez le service (
systemctl stop gitea) pour éviter une migration de schéma sur une base en écriture. - Remplacez le binaire par la dernière version stable, ou tirez l’image conteneur correspondante — évitez le tag
latest, épinglez une version précise. - Redémarrez et contrôlez les logs de migration avant de rouvrir l’accès aux utilisateurs.
Si vous ne pouvez pas patcher immédiatement, la mesure d’atténuation la plus efficace est de retirer l’instance d’Internet : placez-la derrière un VPN ou un proxy authentifiant. Une forge Git n’a presque jamais besoin d’être publique. Cette logique de réduction de la fenêtre d’exposition est détaillée dans notre article sur la réduction du délai de patch.
Étape 3 : durcir la configuration pour sécuriser Gitea dans la durée
Patcher règle la faille du jour. Le durcissement règle les suivantes. Quatre réglages du fichier app.ini changent radicalement votre surface d’attaque :
- Désactiver l’inscription libre :
DISABLE_REGISTRATION = true. Une forge d’entreprise n’a aucune raison d’accepter des comptes créés depuis Internet. - Fermer l’API anonyme :
REQUIRE_SIGNIN_VIEW = trueempêche l’énumération des dépôts et des utilisateurs par un visiteur non authentifié. - Encadrer les runners CI : les runners Gitea Actions exécutent du code arbitraire. Isolez-les sur une machine dédiée, jamais sur l’hôte de la forge, et limitez leurs jetons au strict périmètre nécessaire.
- Imposer la double authentification aux comptes administrateurs et propriétaires d’organisation.
Surveiller les signaux d’une compromission
Trois événements méritent une alerte immédiate dans votre SIEM :
- création d’un compte administrateur ou élévation de privilèges sur une organisation ;
- ajout d’une clé SSH ou d’un jeton d’accès personnel hors des heures ouvrées ;
- apparition d’un fichier de workflow modifié sur une branche par défaut, sans revue associée.
Ces signaux sont exactement ceux qu’un SOC augmenté par l’IA sait corréler : pris isolément, chacun est banal ; enchaînés en quelques minutes, ils dessinent une prise de contrôle. Complétez ce dispositif par une détection des secrets exposés, comme expliqué dans notre article sur les fuites de clés dans les dépôts.
Ce qu’il faut retenir
Sécuriser Gitea ne demande ni budget ni projet : un inventaire des instances, un patch appliqué proprement, quatre lignes de configuration et trois règles de détection. Le vrai risque n’est pas la faille elle-même, c’est l’instance que personne ne s’est attribuée. Traitez votre forge Git comme ce qu’elle est réellement : un système de production critique, au même niveau que votre ERP ou votre annuaire.