● Korben 📅 10/05/2026 à 18:06

GitHub commit spoofing - Quand n'importe qui peut être Linus - Korben

👤 Korben ✨
🏷️ Tags : pto rte rust
Illustration
GitHub commit spoofing - Quand n'importe qui peut être Linus10 mai 2026 / PAR KORBEN ✨ / 6 MIN DE LECTURE /Catégories connexesCe qu’il faut retenirN'importe qui peut publier un commit avec l'identité d'une autre personne sur GitHub en modifiant localement user.name et user.email dans Git, sans validation côté client ni serveur.GitHub attribue les commits par email et affiche l'avatar correspondant sans vérifier que l'auteur possède réellement cet email, rendant le spoofing trivial et indétectable sans chercher le badge "Verified".Pour se protéger, signez vos commits avec SSH ou GPG et activez Vigilant Mode dans GitHub pour forcer l'affichage du statut "Unverified" sur les commits non signés.Résumé généré par IAVous avez confiance dans le nom qui est affiché à côté d'un commit GitHub ?Bah vous pouvez arrêter tout de suite car le chercheur Shani Lavi a documenté il y a quelques années ce que les devs Git sérieux savent depuis longtemps : N'importe qui peut publier un commit avec n'importe quelle identité, et bien sûr, on peut systématiquement compter sur GitHub pour lier ce commit au profil correspondant sans broncher.Allez, petite démonstration récente... Sur le repo no-as-a-service , il y a par exemple un commit signé "torvalds" qui ajoute un témoignage humoristique de Linus Torvalds dans le README. L'avatar de Linus s'affiche, et GitHub considère ça comme un commit parfaitement valide. Sauf que Linus n'a évidemment jamais touché ce projet humoristique qui est une petite API qui sort des excuses créatives pour dire "non".Et ce qui est fou, c'est que vous pouvez faire pareil en dix secondes, et c'est ce qu'on va faire ensemble. Mais avant...Pourquoi Git laisse passer çaGit, à la base, c'est un système distribué. Quand vous faites un commit, votre client local prend alors deux infos dans votre config : user.name et user.email. Ces deux champs sont libres, et jamais validés côté client. Vous pouvez donc écrire ce que vous voulez dedans, et Git s'en fiche.Côté GitHub, l'attribution se fait par l'email. Le service regarde alors l'email présent dans les métadonnées du commit, le compare aux emails enregistrés sur les comptes, et affiche le profil + l'avatar Gravatar correspondant. En fait, il n'y a aucune vérification que la personne qui a poussé le commit possède réellement cette adresse email.Du coup, n'importe qui qui connaît votre email public (et il est public si vous avez déjà commit en clair sur un repo) peut publier des commits avec votre identité affichée.Étape 1 : Reproduire le spoofing (à but pédagogique évidemment)Avant de paniquer, faisons l'exercice nous-mêmes pour bien comprendre. Dans un repo de test que vous contrôlez :# 1. Visualiser un commit cible pour récupérer name + email git log --format='%an ' | head -3 # 2. Reconfigurer Git avec une fausse identité git config --global --replace-all user.name "Linus Torvalds" git config --global --replace-all user.email "[email protected]" # 3. Vérifier la config git config --global --list | grep user # 4. Faire un commit normal echo "Hello from Linus" >> README.md git add README.md git commit -m "Important kernel fix" # 5. Pousser sur votre repo git push origin main Allez voir le commit sur GitHub. Vous verrez l'avatar de Linus, son nom cliquable qui mène vers son profil, et surtout aucun avertissement. Pas de mot de passe demandé ni de token compromis... non, non, non, c'est juste une config locale modifiée.Et si quelqu'un fait un fork de votre repo, ou si un mainteneur peu attentif valide un PR sur cette base, l'illusion est complète.Étape 2 : Repérer un commit douteuxPour ça, le badge Verified reste l'indicateur le plus utile. À côté du SHA d'un commit, GitHub affiche surtout une étiquette verte "Verified" si le commit est cryptographiquement signé avec une clé GPG ou SSH enregistrée sur le compte de l'auteur. Sinon, y'a rien du tout (par défaut). Attention quand même, l'absence de badge ne veut pas dire qu'un commit est malveillant mais juste qu'on ne peut pas garantir qui l'a écrit.Par exemple, si vous regardez le commit e6b4218 sur no-as-a-service, vous remarquerez l'absence totale de badge. C'est le signal mais il faut encore savoir le chercher car par défaut, GitHub n'affiche AUCUN avertissement pour les commits non signés. C'est surtout ça le problème...Étape 3 : Signer vos commits avec SSHAlors pour vous protéger de ça, ça commence chez vous. Plus simple que GPG, la signature SSH utilise une clé que vous avez probablement déjà. Générez une clé Ed25519 si ce n'est pas fait :ssh-keygen -t ed25519 -C "[email protected]" Configurez Git pour signer automatiquement avec cette clé :git config --global gpg.format ssh git config --global user.signingkey ~/.ssh/id_ed25519.pub git config --global commit.gpgsign true git config --global tag.gpgsign true Dernière étape, ajoutez votre clé publique sur GitHub dans Settings → SSH and GPG keys (1), mais cette fois en sélectionnant le type Signing Key (pas Authentication Key, c'est différent) (2). Vos prochains commits afficheront le badge "Verified" en vert.Si vous préférez GPG, le principe est identique avec gpg.format gpg et une clé GPG. Pour le détail GPG complet, j'avais déjà couvert le sujet dans le tuto sur Thunderbird et GPG .Étape 4 : Activer Vigilant ModeLà, on passe à l'offensive. Vigilant Mode (3) force GitHub à afficher un statut sur tous vos commits. Les signés deviennent "Verified", les non signés deviennent "Unverified" en gros et bien visible. Plus de zone grise comme ça.Direction même endroit dans Settings → SSH and GPG keys → Vigilant mode → Flag unsigned commits as unverified. Cochez la case. À partir de là, n'importe quel commit que GitHub vous attribue (via votre email vérifié) sans signature sera affiché comme "Unverified", ce qui rend le spoofing beaucoup plus difficile à dissimuler. Petite limite par contre, ça ne protège que votre propre identité et pas celle des contributeurs qui n'ont pas activé le mode.La position de GitHub (et pourquoi je trouve ça discutable)GitHub considère ce comportement comme un non-bug. Sur leur page bug bounty, l'usurpation par email Git est explicitement listée comme ineligible. Leur argument c'est que ça ne donne pas accès aux repos ni de privilèges supplémentaires, donc ce n'est pas une faille au sens strict.Sauf que dans la vraie vie, l'identité affichée influence les décisions. Par exemple, un mainteneur qui voit un PR signé d'un contributeur connu va l'examiner avec moins de paranoïa, un journaliste qui couvre un scandale va citer "le commit de tel développeur" sans vérifier la signature, et combiné à d'autres vecteurs, ça peut devenir redoutable ! Je pense surtout aux attaques supply chain récentes type Shai-Hulud où une fois le code piégé, l'attribution Git aide à le faire passer pour légitime.Bref, dire "ce n'est pas un bug" parce qu'il faut un autre vecteur derrière, c'est un peu facile, je trouve. Voilà, donc ne comptez pas sur Github pour vous défendre et signez vos commits, activez Vigilant Mode, et apprenez à vos collègues et amis dev à vérifier le badge "Verified" avant de merger quoi que ce soit en venant d'un inconnu... même si c'est ce bon cher Linus qui propose de réécrire le kernel en Rust avec systemd intégré ^^.SourceRéférenceshttps://infosecwriteups.com/the-curious-case-of-github-commit-spoofing-a-lighthearted-exploration-54ddbaaaf40aCet article peut contenir des images générées à l'aide de l'IA - J'apporte le plus grand soin à chaque article, toutefois, si vous repérez une boulette, faites-moi signe !Vous avez aimé cet article ?Alors rejoignez ma communauté sur Patreon et accédez à des articles exclusifs, des tutos avancés et plein d'autres surprises que je réserve à mes soutiens. C'est grâce à vous que je peux continuer à partager ma passion depuis 20 ans !Rejoindre l'aventure Que faire après le bac quand on est passionné de cybersécurité ?Contenu partenaireEntièrement dédiée à la cybersécurité, l'école Guardia est accessible soit directement après le bac (post-bac), soit après un bac+2 ou bac+3. En rejoignant l'école Guardia, vous deviendrez développeur informatique option cybersécurité (Bac+3) ou expert en cybersécurité (Bac+5).Guardia CS forme aussi les professionnels à la cybersécurité via plusieurs formations en ligneVoir le site internet de l'école de cybersécurité Guardia CS📬 La newsletter Korben — Un concentré de tech, d'actu et de bidouille dans votre boite mail. S'inscrire
← Retour