Une application pas à jour suffit : la faille Gitea qui se moque de vos mots de passe et du MFA

Vous avez coché toutes les cases : mots de passe robustes, double authentification (MFA) sur la messagerie et les comptes sensibles, gestionnaire de mots de passe pour l'équipe. Et pourtant, un attaquant peut exécuter ses propres commandes sur l'un de vos serveurs sans jamais passer par votre écran de connexion. Pas en devinant un mot de passe, pas en piégeant un collaborateur : simplement parce qu'une application installée un jour, puis oubliée, n'a pas été mise à jour. C'est très exactement le scénario qu'a rendu possible une faille critique dans Gitea. L'outil importe peu — la mécanique, elle, vaut pour tout votre système d'information.

Ce qui s'est passé

Gitea est une « forge logicielle » : un logiciel libre que les entreprises installent sur leurs propres serveurs pour héberger leur code source et travailler à plusieurs dessus — l'équivalent d'un GitHub privé. Léger, gratuit et vite installé, on le retrouve dans d'innombrables PME, agences web et équipes techniques. Souvent depuis des années, souvent sans que personne n'en soit officiellement responsable.

Le 28 juillet 2026, ses développeurs ont publié un avis de sécurité critique : la vulnérabilité CVE-2026-60004, notée 9,8 sur 10 sur l'échelle de sévérité CVSS. Toutes les versions publiées depuis mi-2022 étaient concernées. Autrement dit : un serveur Gitea installé il y a trois ans et jamais suivi depuis était vulnérable le jour de l'annonce.

Le principe, débarrassé de son jargon : une fonction parfaitement légitime de l'application — proposer un correctif de code depuis l'interface web — pouvait être détournée pour déposer un fichier exécutable là où Git lance des scripts automatiques, ses « hooks ». En soumettant deux fois le même correctif piégé, l'attaquant faisait exécuter ses commandes par le serveur lui-même, avec les droits du service. C'est ce qu'on appelle une exécution de code à distance : la pire catégorie de faille, celle qui transforme une application web en porte d'entrée sur la machine.

Le correctif tient en une mise à jour, la version 1.27.1, disponible le jour de l'avis. Ceux qui l'ont appliquée dans la foulée ont fermé la porte en quelques minutes. Pour les autres, le compte à rebours a commencé : après chaque publication de ce type, des campagnes de balayage automatisées passent Internet au peigne fin pour recenser les serveurs restés en retard.

Pourquoi votre login et votre MFA n'y changent rien

Le réflexe naturel : « nos comptes sont protégés par la double authentification, nous sommes tranquilles ». C'est vrai contre le vol de mots de passe — et le MFA reste l'un des meilleurs investissements de sécurité qui soient. Mais face à une faille logicielle, il est hors sujet, pour deux raisons.

D'abord, l'attaquant n'a pas besoin de votre compte. Dans le cas présent, il lui suffisait d'un accès en écriture à un dépôt de code — n'importe lequel. Et sur les serveurs où l'inscription publique était restée ouverte, un réglage par défaut fréquent sur ce genre d'outil, n'importe quel visiteur anonyme pouvait créer son propre compte, son propre dépôt, et dérouler l'attaque dans la minute. Peu importe que vos comptes à vous exigent un code à six chiffres : l'attaquant est entré avec le sien.

Ensuite, l'authentification garde la porte d'entrée ; elle ne répare pas les murs. Une exécution de code à distance passe par une fonctionnalité de l'application elle-même : le code malveillant s'exécute côté serveur, derrière l'écran de login, avec les droits du service. Le MFA protège l'identité de vos utilisateurs. Il ne rend pas le logiciel correct.

Une fois le pied posé sur le serveur, l'attaquant lit tout ce que l'application peut lire. Pour une forge de code : la propriété intellectuelle de l'entreprise, bien sûr, mais surtout les secrets qui traînent dans le code et sa configuration — jetons d'accès, clés d'API, mots de passe de bases de données, identifiants de déploiement. Autant de passe-partout pour rebondir vers le reste du système d'information. Le serveur « secondaire » devient la tête de pont.

En conclusion

Gardez votre MFA : il ferme la porte la plus utilisée. Mais ne lui demandez pas de compenser un logiciel obsolète — ce n'est pas son rôle. Dans les incidents qui font l'actualité, le dénominateur commun n'est presque jamais l'absence de double authentification : c'est l'absence de pilotage. Personne ne savait quelle version tournait, personne ne recevait les alertes, personne n'avait testé la restauration. La sécurité n'est pas un produit qu'on installe une fois : c'est un tableau de bord qu'on regarde chaque semaine.

Vous voulez savoir combien d'applications exposées tournent réellement chez vous, mettre en place cette supervision — indicateurs, alertes, journaux — ou remettre à plat mises à jour, sauvegardes et archivage externe ? Parlons-en.