La CISA (Cybersecurity and Infrastructure Security Agency) a confirmé que CVE-2026-60004, la faille critique de Gitea que nous avions couverte le mois dernier, est aujourd’hui exploitée activement. L’agence américaine a ajouté cette vulnérabilité à son catalogue Known Exploited Vulnerabilities (KEV) le 25 août 2026. Concrètement, le correctif passe du statut « à appliquer quand vous aurez le temps » à « à appliquer maintenant » pour quiconque fait encore tourner une instance Gitea vulnérable.
Les agences fédérales américaines avaient jusqu’au 28 août 2026 pour se mettre en conformité, une échéance déjà dépassée au moment de la publication de cet article. Si vous administrez une instance Gitea auto-hébergée, la même urgence s’applique en pratique, même sans obligation fédérale.
Ce qui a changé depuis notre dernier article
Lorsque Gitea 1.27.1 avait corrigé cette faille le mois dernier, l’avis officiel du projet ne signalait aucune exploitation confirmée dans la nature, et la CVE ne figurait pas encore au catalogue KEV de la CISA. Certains sites de sécurité titraient pourtant déjà sur une « exploitation active », sans s’appuyer sur une source primaire solide. C’est désormais chose faite : l’inscription au KEV constitue la première confirmation officielle, par une source primaire, que des attaquants exploitent bel et bien cette faille contre de vraies instances Gitea.
Pour mémoire, CVE-2026-60004 permet à n’importe quel utilisateur disposant d’un simple accès en écriture sur un dépôt (ou à n’importe quel utilisateur enregistré si l’inscription ouverte est activée) de détourner l’endpoint API diffpatch de Gitea pour installer un hook Git malveillant et exécuter du code arbitraire en tant qu’utilisateur système de Gitea. Nous ne reviendrons pas ici sur le changelog complet : les correctifs liés à l’authentification à deux facteurs obligatoire et aux certificats ACME, publiés dans la même version, sont détaillés dans notre article original.
À quoi ressemble l’attaque sur le terrain
Help Net Security a rapporté le 26 août un cas documenté précis, basé sur un témoignage publié par un développeur sur le blog collaboratif russe Habr. Précisons la nature de cette source : il s’agit du récit d’un seul administrateur sur sa propre compromission, pas d’une campagne d’exploitation massive officiellement confirmée. Cela reste toutefois une illustration concrète de la chaîne d’attaque que la CISA pointe désormais du doigt.
Selon ce témoignage, l’organisation concernée faisait tourner une instance Gitea auto-hébergée obsolète, avec inscription ouverte, sans confirmation par e-mail ni CAPTCHA. Un scanner automatisé s’est inscrit, a créé un dépôt, puis a déroulé la chaîne d’exploitation jusqu’à obtenir une exécution de code en tant qu’utilisateur « git » dans le conteneur Docker de Gitea.
D’après ce récit, l’attaquant a agi vite : il a d’abord commité une « preuve » de RCE dans une branche Git, puis téléchargé un shell-loader universel, puis un logiciel de minage de cryptomonnaie. L’administrateur ne s’en est rendu compte que parce que son hébergeur a signalé une utilisation anormalement élevée du CPU. Point positif : le conteneur ne tournait pas en mode privilégié et n’a pas survécu à un redémarrage, si bien que le développeur n’a trouvé aucune trace de persistance, ni tâche cron, ni unité systemd, ni nouvelle clé SSH. Selon son témoignage, la phase active de l’attaque aurait duré environ 11 secondes.
Par la suite, l’administrateur a mis à jour vers Gitea v1.27.2, désactivé l’inscription ouverte, supprimé les méthodes d’inscription superflues, changé l’ensemble des secrets et jetons, renforcé la configuration réseau Docker du conteneur, et bloqué purement et simplement ses connexions sortantes.
Que faire maintenant
Si vous faites tourner Gitea et que ce n’est pas encore fait :
- Mettez à jour vers la version v1.27.2. C’est l’étape la plus importante, et elle devrait déjà être derrière vous si vous aviez appliqué le correctif dès la sortie de la 1.27.1.
- Désactivez l’inscription ouverte, ou, si vous devez la laisser active, exigez un CAPTCHA et une confirmation par e-mail avant qu’un compte puisse agir sur l’instance.
- Si vous faites tourner une version obsolète avec inscription ouverte, auditez votre instance : cherchez des branches ou des hooks Git inconnus, des connexions sortantes inhabituelles, et des pics de CPU inexpliqués.
- Changez vos secrets et jetons API par précaution, même en l’absence de signe visible de compromission.
- Faites tourner Gitea dans un conteneur non privilégié et restreignez son accès réseau sortant en défense supplémentaire. Comme le montre le témoignage Habr, c’est parfois ce qui fait la différence entre un incident contenu et une compromission durable.
Rien de tout cela ne justifie la panique. Cela demande simplement d’appliquer le correctif, et si vous repoussiez l’échéance, aujourd’hui est un meilleur moment que ce week-end. Pour le détail complet du correctif Gitea 1.27.1, authentification à deux facteurs et certificats ACME compris, direction notre article de référence sur le sujet.