Gitea : 9 failles corrigées, dont une déjà exploitée

Ce qui s'est passé

Gitea, la forge Git auto-hébergée, enchaîne les correctifs de sécurité depuis l'été 2026. Deux informations comptent pour un administrateur. La première : la CVE-2026-60004, une exécution de code à distance, est exploitée dans la nature. La seconde : la version 28.1.0 (6 octobre 2026) corrige 9 CVE d'un coup. Les versions suivantes en corrigent d'autres : n'en restez pas à la 28.1.

Si vous auto-hébergez Gitea sur un VPS Linux, la mise à jour vous revient : c'est à vous de la lancer.

Précision utile : l'annonce de la 28.1.0 ne dit pas que ces 9 failles sont exploitées. La faille exploitée est une autre, corrigée plus tôt, en 1.27.1.

Vocabulaire : CVE, RCE, XSS et déni de service

Quelques termes reviennent dans cet article. Ils décrivent des notions stables, utiles pour lire une annonce de sécurité.

• CVE (Common Vulnerabilities and Exposures) : identifiant standard d'une faille de sécurité publiée, sous la forme CVE-année-numéro. Un numéro CVE ne dit pas à lui seul si la faille est exploitée.
• Faille critique : vulnérabilité notée très haut selon le score CVSS, qui mesure sa gravité. Une faille critique mérite une mise à jour rapide, surtout si le service est exposé sur Internet.
• RCE (Remote Code Execution) : exécution de code à distance. L'attaquant lance des commandes sur la machine sans y être connecté.
• XSS (Cross-Site Scripting) : injection de script dans une page web consultée par d'autres utilisateurs. Stocké, le script reste enregistré côté serveur, par exemple dans un dépôt ou un commentaire.
• Déni de service (DoS) : rendre un service inutilisable en épuisant le processeur (CPU) ou la mémoire vive (RAM), par exemple avec une boucle infinie.

CVE-2026-60004 : la faille exploitée

Selon l'annonce de Gitea 1.27.1 (27 juillet 2026), cette faille permet une exécution de code à distance via l'API diffpatch, par l'installation d'un hook Git. Les mainteneurs expliquent qu'un attaquant disposant d'un simple droit d'écriture sur un dépôt peut exécuter des commandes shell avec l'utilisateur système de Gitea. Si l'inscription est ouverte, un visiteur peut créer un compte, créer un dépôt et déclencher la faille.

CISA l'a ajoutée à son catalogue des vulnérabilités exploitées le 25 août 2026, d'après Help Net Security. Un développeur a décrit une attaque sur une instance auto-hébergée : consommation CPU soutenue, puis téléchargement d'un chargeur et d'un mineur de cryptomonnaie. Un code de démonstration public existe.

Les 9 CVE de la 28.1.0

Le lot corrigé dans Gitea 28.1.0 touche surtout les droits d'accès. Voici les grandes familles.

Ce sont des failles d'autorisation et de fuite plutôt que des exécutions de code. Elles pèsent surtout si votre instance héberge des dépôts privés ou accepte des utilisateurs extérieurs.

Et depuis la 28.1.0 ?

Le blog de Gitea annonce la 28.2.0 (18 octobre) puis la 28.3.0 (1er novembre). Chaque annonce recommande vivement de mettre à jour au plus vite. La 28.3.0 corrige à elle seule une vingtaine de CVE : jetons restreints qui accèdent à trop de fonctions, secrets exposés dans Actions, liaison de compte OAuth2 sans mot de passe quand ACCOUNT_LINKING = auto et que l'inscription est ouverte. Les annonces ne précisent pas d'exploitation pour ces failles.

Que faire maintenant

Ces étapes s'adressent aux administrateurs de l'instance. Si votre forge est gérée en infogérance par un prestataire ou par un hébergeur, demandez-lui où en est la mise à jour.

1. Identifiez votre version. En ligne de commande : gitea --version. Dans Docker, regardez le tag de l'image.
2. Sauvegardez avant de toucher à quoi que ce soit. La commande gitea dump produit une archive des données. Vérifiez d'abord que l'espace disque suffit pour l'archive, puis copiez-la hors du serveur.
3. Mettez à jour vers la dernière version stable. Pour une installation Docker Compose :

docker compose pull
docker compose up -d

Pour une installation par binaire, remplacez le binaire par celui de la page de téléchargement officielle et redémarrez le service.

4. Fermez les inscriptions si elles ne servent pas. Dans app.ini, section [service] :

[service]
DISABLE_REGISTRATION = true

5. Cherchez des signes de compromission si vous avez tourné en version 1.17 à 1.27.0 avec des inscriptions ouvertes : CPU anormal, processus inconnus, connexions sortantes inattendues, dépôts ou comptes récents suspects.
6. Renouvelez les secrets en cas de doute : mots de passe des bases de données, jetons, identifiants OAuth, clés de déploiement.

Si l'exécution de code a pu se produire, traitez la machine comme compromise. Notre guide pour vérifier un serveur compromis décrit une démarche de contrôle transposable.

Durcir son instance Gitea

La mise à jour règle le problème du jour, pas celui du mois prochain. Quelques réflexes limitent les dégâts :

• Faites tourner Gitea sous un utilisateur dédié, sans droits superflus (ni sudo, ni accès root), ou dans un conteneur dont le réseau sortant est restreint, comme précaution face à la CVE-2026-60004.
• Placez l'instance derrière un serveur Web en reverse proxy Nginx, en HTTPS et sur un nom de domaine dédié (son enregistrement DNS pointe vers l'adresse IP du serveur), en gardant en tête qu'il ne remplace pas la mise à jour.
• Limitez l'accès SSH avec les réglages de notre guide pour sécuriser SSH.
• Planifiez des sauvegardes (backup) hors site, par exemple avec rsync vers un serveur distant. Chez ElypseCloud, les sauvegardes sont proposées en option.
• Limitez l'accès à l'interface d'administration (admin) à quelques adresses IP (votre bureau ou votre domicile, par exemple), et ne laissez ouverts sur le pare-feu (firewall) que les ports utiles.
• Suivez les annonces du blog Gitea : les correctifs tombent à un rythme rapide.

Pour partir sur une base propre, consultez notre guide pour installer et sécuriser Forgejo ou Gitea sur un VPS, avec Docker Compose.

Vocabulaire de l'hébergement : serveur virtuel, dédié, mutualisé

Pour choisir où héberger votre forge, quelques termes reviennent. Ce sont des notions générales, utiles pour comparer les formats.

• Serveur virtuel (VPS) : machine virtuelle qui tourne sur un serveur physique partagé, avec son propre système d'exploitation et des ressources allouées. On parle aussi de serveur privé virtuel.
• Serveur dédié : machine physique entière, réservée à un seul client.
• Serveur mutualisé : hébergement où plusieurs sites partagent le même serveur et ses ressources, sans accès système complet.
• Hébergement cloud : ressources de calcul virtualisées, mises à disposition sur une infrastructure partagée.
• Système d'exploitation : logiciel de base du serveur, par exemple Debian ou Ubuntu. Il gère le matériel, les services et les droits des utilisateurs.
• Panneau de contrôle (panel) : interface web qui simplifie l'administration d'un serveur. Il n'est pas obligatoire : l'accès root suffit pour administrer une forge.
• Adresse IP : identifiant numérique d'une machine sur le réseau. Un nom de domaine pointe vers une adresse IP grâce à un enregistrement DNS.
• Bande passante : volume de données échangé avec le réseau. Les clonages et les pushs de dépôts la consomment.
• Espace disque : place disponible pour les dépôts, les bases de données et les sauvegardes (backup).
• Haute disponibilité : organisation qui limite les interruptions de service, par exemple avec une seconde instance prête à prendre le relais. Une forge à usage personnel n'en a pas forcément besoin.

Pourquoi un serveur à vous change la donne

Auto-héberger sa forge, c'est maîtriser son code, mais aussi les mises à jour. Un VPS Linux ou un serveur dédié vous donne l'accès root pour gérer le service, le pare-feu, les sauvegardes (backup) et le système d'exploitation. Les offres ElypseCloud sont sur SSD, avec un réseau jusqu'à 10 Gbit/s selon l'offre, une protection anti-DDoS et un datacenter à Paris. Cette protection ne remplace pas le correctif : une faille applicative reste à corriger côté logiciel.

Même logique chez d'autres forges : voir notre article sur la faille critique GitLab.

Serveur mutualisé, VPS ou serveur dédié : quelle différence pour une forge ?

Le format d'hébergement détermine qui applique les mises à jour et qui gère le pare-feu. Voici les trois formats courants.

Pour une forge Git, un VPS Linux offre un bon compromis : vous installez Gitea, configurez le pare-feu et appliquez les correctifs sans attendre un tiers. Le serveur dédié prend le relais si la charge l'exige.