Un chercheur en cryptographie vient de démontrer qu’un badge “Verified” sur GitHub ne garantit pas ce que des millions de développeurs pensent qu’il garantit. Jacob Ginesin, doctorant à Carnegie Mellon et auditeur chez Cure53, a publié le 2 juillet 2026 sur arXiv un article intitulé “Git Hash Chain Malleability” qui casse une hypothèse tenue pour acquise depuis la création du système de signature de commits par Linus Torvalds. Cinq mois après son signalement à GitHub en mars 2026, et près de trois mois après la publication de la recherche, aucun correctif public n’a été déployé. Pour un secteur qui répète depuis l’affaire XZ Utils que la chaîne d’approvisionnement logicielle doit être vérifiable de bout en bout, la nouvelle tombe mal.
Ce que révèle la recherche de Jacob Ginesin
Le postulat que Ginesin fait tomber est simple à énoncer et facile à croire vrai : un hash de commit Git signé identifierait de façon unique et immuable le contenu signé. Dans l’abstract de son article, le chercheur résume la faille en une phrase directe : “Given any signed commit, an attacker without access to the signing key, and without breaking SHA2 can produce a second, distinct commit with an identical tree, identical metadata, a valid signature, and a Verified badge from a Git Forge such as Github, differing only in its commit hash” (source). Autrement dit, sans voler la moindre clé privée et sans casser SHA-256, un attaquant peut fabriquer un second commit qui contient exactement les mêmes fichiers, le même auteur, la même date, une signature valide, et qui obtient malgré tout un hash différent.
Ginesin résume la portée de sa démonstration en une formule tranchante : “We show this invariant does not hold” (source). L’invariant en question, c’est justement l’idée que le hash d’un commit signé sert d’empreinte fiable. The Hacker News, qui a couvert la recherche dès juillet, la résume ainsi : “Given any signed commit, someone without the signing key can mint a second commit with the same files, author, and date, and a valid signature, GitHub still stamps Verified” (source). La faille ne touche donc pas le contenu du commit lui-même, mais son identifiant, ce qui change complètement la nature du risque.
Trois classes de signatures, trois mécanismes distincts
Ce qui rend la découverte particulièrement embêtante pour l’écosystème, c’est qu’elle ne repose pas sur une seule faiblesse ponctuelle mais sur trois défauts structurels distincts, chacun touchant une famille de signatures cryptographiques différente.
ECDSA : la symétrie (r, s) / (r, n − s)
Le premier mécanisme concerne ECDSA, l’algorithme de signature par courbe elliptique le plus utilisé pour signer des commits via clé SSH ou GPG. La malléabilité exploite la symétrie mathématique bien connue des signatures ECDSA : pour un couple valide (r, s), le couple (r, n − s) vérifie également la signature. Changer un seul octet dans cette portion de la signature suffit à produire un objet Git différent, avec un hash différent, tout en conservant une signature parfaitement valide.
RSA et EdDSA : les sous-paquets non hachés d’OpenPGP
Le deuxième mécanisme touche RSA et EdDSA dans leur implémentation OpenPGP. Le format PGP contient une zone dite de “sous-paquets non hachés” (unhashed subpackets), une zone de métadonnées que le processus de vérification ignore volontairement lors du calcul de la signature. Un attaquant peut y insérer des données arbitraires, ce qui modifie l’octet-à-octet du commit sérialisé et donc son hash, sans jamais invalider la signature elle-même. Le blog technique iter.ca, qui a documenté une méthode pratique d’exploitation dès le 7 juillet 2026, illustre le problème avec un exemple concret : insérer une ligne de commentaire juste après l’en-tête “—–BEGIN PGP SIGNATURE—–” suffit, car cette ligne “gets ignored when you parse the PEM” (source).
S/MIME : les encodages DER multiples
Le troisième mécanisme concerne les signatures S/MIME, où le format d’encodage DER (Distinguished Encoding Rules) autorise plusieurs représentations valides pour une même longueur de champ. Un parseur permissif acceptera plusieurs encodages ASN.1/CMS différents pour un contenu identique, chacun produisant un hash Git distinct. Dans les trois cas, le résultat final est le même : le code source, l’auteur, la date et le message de commit restent strictement identiques, mais l’identifiant technique change, et l’interface GitHub continue d’afficher le badge “Verified” sur les deux versions.
| Classe de signature | Mécanisme exploité | Élément modifié | Badge GitHub après modification |
|---|---|---|---|
| ECDSA | Symétrie (r, s) / (r, n − s) | Valeur s de la signature | Verified (les deux versions) |
| RSA / EdDSA (OpenPGP) | Sous-paquets non hachés ignorés | Métadonnées du paquet de signature | Verified (les deux versions) |
| S/MIME | Encodages DER multiples valides | Représentation ASN.1/CMS | Verified (les deux versions) |
| SHA-1 (comparaison historique, SHAttered 2017) | Collision de hash entre deux fichiers différents | Contenu du fichier PDF | Non applicable (pas un badge de signature) |
Pourquoi ce n’est pas une collision de hash classique
Il est tentant de comparer cette découverte à l’attaque SHAttered de 2017, qui avait démontré pour la première fois une collision pratique sur SHA-1 en produisant deux fichiers PDF au contenu différent partageant le même hash. Mais Ginesin est clair sur ce point : sa recherche ne repose sur aucune collision. Dans le cas SHAttered, deux entrées différentes étaient délibérément construites pour produire une empreinte identique. Dans le cas de la malléabilité de signature Git, c’est l’inverse : un seul et même commit logique, avec un seul et même contenu signé, admet plusieurs sérialisations d’octets valides, et chacune produit naturellement un hash différent puisque la fonction de hachage travaille exactement comme prévu. SHA-256, contrairement à SHA-1, n’a jamais été cassé, et migrer un dépôt de SHA-1 vers SHA-256 ne corrige strictement rien au problème : le hash s’applique toujours à une sérialisation dont la signature elle-même n’est pas canonique.
Cette distinction technique a une conséquence pratique immédiate pour les équipes de sécurité : les listes de blocage par hash (hash blocklists), utilisées pour bannir un commit malveillant identifié dans un dépôt cloné ou miroir, peuvent être contournées. Il suffit de republier une version malléée du même commit sous un hash différent pour échapper à une détection basée uniquement sur l’empreinte. Les mécanismes de vérification de provenance des miroirs, ainsi que certains outils de reproductibilité utilisés dans la génération de nomenclatures logicielles (SBOM), reposent eux aussi sur l’hypothèse qu’un hash de commit identifie une version unique du code. Cette hypothèse ne tient plus.
L’outil de démonstration et la portée réelle de l’attaque
Pour appuyer sa démonstration, Ginesin a publié un outil baptisé git-chain-malleator sur GitHub, capable de reproduire les trois classes de malléabilité décrites dans son article. Un point mérite d’être souligné avec précision, car il borne correctement le niveau de risque réel : cette attaque ne permet à aucun moment de modifier le contenu d’un commit signé sans posséder la clé privée du signataire. Le magazine hongrois LAVX News, qui a repris la recherche, le formule sans ambiguïté : “The attack does not allow someone to alter the code inside a signed commit” (source). Il ne s’agit donc pas d’une attaque de falsification de code, mais d’une attaque d’identité de commit : deux objets Git strictement équivalents en contenu, tous deux légitimement signés, mais portant des hashes différents.
Le média brésilien PRIDE SECURITY INTEL, dans sa veille dédiée à la recherche, confirme sobrement ce que montre l’outil de démonstration : “GitHub continues displaying the Verified badge” (source) même après la génération d’un second commit malléé. C’est précisément cette persistance du badge qui inquiète les auditeurs de chaîne d’approvisionnement logicielle : l’interface utilisateur continue de communiquer une garantie de canonicité que le protocole sous-jacent ne fournit plus.
Cinq mois de silence : la chronologie du signalement
La chronologie de cette divulgation mérite d’être détaillée, car elle illustre un problème récurrent de la coordination de vulnérabilités dans l’écosystème open source. Ginesin affirme avoir signalé sa découverte à GitHub dès mars 2026, soit environ quatre mois avant la publication publique de l’article scientifique. L’article arXiv “Git Hash Chain Malleability” a ensuite été mis en ligne le 2 juillet 2026. Le site spécialisé 0dayNews a publié sa couverture le 8 juillet, suivi immédiatement par le blog technique iter.ca le 7 juillet et par plusieurs relais internationaux, dont des éditions en portugais, hongrois et polonais.
Or, à la date du 22 septembre 2026, soit près de sept mois après le signalement initial et un peu plus de deux mois et demi après la publication, aucune annonce officielle de correctif n’a été identifiée du côté de GitHub, de GitLab, ou du projet Sigstore. Aucun identifiant CVE n’a été attribué à cette découverte. Un détail technique explique en partie ce délai : la correction ne nécessite pas de modifier le format des objets Git eux-mêmes, mais peut être implémentée directement au niveau de la plateforme d’hébergement (le “forge”), par exemple en imposant une canonicalisation stricte des signatures avant de délivrer le badge Verified. Le fait qu’une solution existe sans réécriture du protocole rend d’autant plus notable l’absence de réaction publique après sept mois.
| Étape | Date | Détail |
|---|---|---|
| Signalement initial à GitHub | Mars 2026 | Ginesin transmet ses résultats en amont de la publication |
| Publication arXiv | 2 juillet 2026 | “Git Hash Chain Malleability” mis en ligne |
| Premières couvertures techniques | 7-8 juillet 2026 | iter.ca et 0dayNews publient leurs analyses |
| Relais internationaux | Juillet-août 2026 | Reprises en portugais, hongrois, polonais |
| Situation à date de publication | 22 septembre 2026 | Aucun correctif public de GitHub, GitLab ou Sigstore identifié, aucun CVE attribué |
GitHub, GitLab et Sigstore : un silence à nuancer
Il faut néanmoins nuancer ce qui pourrait ressembler à de l’inaction pure. D’une part, l’absence de communication publique ne prouve pas l’absence de travail en coulisses : une plateforme peut très bien enquêter en interne sans émettre d’avis de sécurité tant que la correction n’est pas prête, une pratique courante en divulgation coordonnée. D’autre part, la documentation officielle de GitHub sur la vérification des signatures de commit reste, à ce jour, formulée en des termes qui n’ont jamais prétendu garantir l’unicité d’un hash de commit signé : elle décrit uniquement le succès de la vérification cryptographique de la signature, pas la canonicité de l’objet sérialisé (source). GitLab tient un discours similaire dans sa documentation sur les commits signés, qui définit la vérification comme la confirmation de l’identité du committer via une clé publique, sans mention d’unicité de hash (source).
Du côté de Sigstore, le projet open source soutenu par la Linux Foundation pour la signature d’artefacts logiciels, plusieurs avis de sécurité distincts ont été publiés en 2026, notamment sur des défauts de validation d’horodatage, de gestion de confiance du journal de transparence Rekor, et de liaison de type de charge utile DSSE dans le paquet @sigstore/core. Ces correctifs, bien réels, concernent des vulnérabilités différentes de celle découverte par Ginesin et ne doivent pas être confondus avec une réponse à sa recherche spécifique sur la malléabilité des commits Git. Cette confusion possible souligne d’ailleurs un problème plus large : l’écosystème de la signature de code traverse une période de correctifs multiples et dispersés, sans qu’aucun acteur ne semble avoir pris la responsabilité globale de canonicaliser la vérification des commits à la source.
Un précédent familier : la malléabilité des transactions Bitcoin
Pour les lecteurs familiers de la cryptographie appliquée, cette découverte évoque immédiatement un précédent bien documenté : la malléabilité des transactions Bitcoin, identifiée dès les premières années du réseau. Le principe était structurellement identique : une transaction Bitcoin signée pouvait être réencodée sous une forme légèrement différente, sans changer son effet économique (le même montant transféré vers la même adresse), mais en modifiant son identifiant de transaction (TXID). Ce défaut avait notamment compliqué le fonctionnement de certains portefeuilles et échanges qui s’appuyaient sur le TXID avant confirmation en bloc. Bitcoin a fini par corriger le problème par l’adoption d’un encodage DER strict pour les signatures, puis plus largement via l’activation de SegWit (Segregated Witness), qui sépare la structure de signature de celle qui détermine l’identifiant de transaction.
La leçon que l’écosystème Bitcoin a mis des années à tirer, Git semble en train de la redécouvrir en 2026 : une signature authentifie un message selon des règles de sérialisation précises, mais elle ne garantit un identifiant unique que si cette sérialisation est strictement canonicalisée. Sans cette canonicalisation, deux objets peuvent être cryptographiquement équivalents en termes de validité tout en portant des identifiants distincts, un problème qui rappelle par certains aspects les débats sur les performances comparées d’ECDSA face à RSA. La différence de gravité entre les deux cas tient à l’enjeu : chez Bitcoin, l’enjeu était économique et immédiat. Chez Git, l’enjeu est la confiance dans la provenance du code, ce qui, à l’ère du Cyber Resilience Act européen et des obligations de traçabilité logicielle, n’est pas un enjeu mineur non plus.
Impact sur la chaîne d’approvisionnement logicielle
La signature de commits n’est pas un exercice académique : elle est devenue, ces dernières années, un pilier des politiques de sécurité de la chaîne d’approvisionnement logicielle, notamment dans les environnements soumis à des obligations réglementaires. En Europe, le Cyber Resilience Act impose déjà la signature numérique du code, pour certaines catégories de produits, avec des sanctions pouvant atteindre un pourcentage significatif du chiffre d’affaires en cas de manquement. Une découverte qui affaiblit la garantie d’unicité d’un commit signé touche donc directement les mécanismes que les organismes de conformité s’apprêtent à exiger.
Les nomenclatures logicielles (SBOM), de plus en plus généralisées pour documenter la composition d’un logiciel et ses dépendances, s’appuient elles aussi largement sur des références à des commits ou des hashes de version pour établir la provenance d’un composant. Si un hash de commit signé n’est plus une empreinte unique et fiable, alors la chaîne de confiance qui va du SBOM jusqu’au code source réellement exécuté comporte un maillon plus fragile qu’annoncé. Cela ne signifie pas que les SBOM deviennent inutiles, loin de là, mais cela signifie que les outils de génération de SBOM et les vérificateurs de provenance devraient, à terme, intégrer une étape de canonicalisation des signatures avant de calculer ou de faire confiance à un hash de commit.
Le rapprochement avec le piratage de DigiCert et la révocation de 60 certificats de signature de code, ou avec l’affaire XZ Utils de 2024, est également pertinent, même si les deux cas sont de nature différente. Dans l’affaire XZ Utils, un contributeur malveillant avait patiemment gagné la confiance du projet avant d’insérer une porte dérobée dans les scripts de build, un problème de confiance humaine et de gouvernance de projet. La recherche de Ginesin touche un maillon plus bas dans la pile : même en supposant une gouvernance de projet irréprochable et des mainteneurs dignes de confiance, le mécanisme technique censé garantir qu’un commit vérifié correspond à une identité unique et immuable peut être contourné. Les deux affaires partagent une même conclusion : le badge “Verified” et la réputation d’un mainteneur ne remplacent pas une vérification cryptographique de bout en bout qui résiste à l’examen technique le plus fin.
Comparaison avec d’autres systèmes de signature
Pour situer la gravité relative de cette découverte, il est utile de la comparer à d’autres cas de malléabilité de signature documentés dans des systèmes distincts. Le tableau ci-dessous synthétise les principaux parallèles techniques identifiés par la recherche en sécurité, en distinguant le mécanisme exploité et la conséquence pratique dans chaque écosystème.
| Système | Mécanisme de malléabilité | Conséquence principale | Correction apportée |
|---|---|---|---|
| Bitcoin (transactions) | Réencodage valide de signature ECDSA | Changement du TXID avant confirmation | Encodage DER strict, puis SegWit |
| Git (commits signés, 2026) | ECDSA (r, n−s), sous-paquets PGP, encodages DER S/MIME | Changement du hash de commit malgré contenu identique | Aucune à ce jour (canonicalisation possible côté forge) |
| OpenPGP (général) | Données ignorées dans les sous-paquets non hachés | Modification de la sérialisation sans invalider la signature | Dépend de l’implémentation du vérificateur |
| Sigstore (@sigstore/core, 2026) | Liaison de type de charge utile DSSE défaillante | Mutation possible après signature | Corrigée via avis de sécurité 2026 |
Ce que les équipes de développement peuvent faire dès maintenant
En l’absence de correctif officiel côté plateforme, les équipes de sécurité applicative et les responsables de la chaîne d’approvisionnement logicielle disposent de quelques leviers pratiques pour limiter l’exposition. Le premier réflexe consiste à ne jamais s’appuyer exclusivement sur un hash de commit signé comme preuve d’unicité dans un système de détection ou de blocage : une liste de hashes bannis reste utile, mais elle doit être complétée par une vérification du contenu réel (l’arbre de fichiers) plutôt que du seul identifiant. Le second levier consiste à privilégier, lorsque c’est possible, des outils de vérification qui imposent une forme de canonicalisation stricte de la signature avant de considérer un commit comme fiable, à l’image de ce que Bitcoin a fini par imposer avec l’encodage DER strict.
Pour les organisations qui génèrent des SBOM ou qui documentent la provenance de leurs dépendances, à l’image de ce que détaille notre guide sur la signature numérique X.509 en Node.js, il est recommandé d’auditer les outils utilisés pour vérifier s’ils traitent le hash de commit comme un identifiant canonique unique, ou s’ils intègrent déjà une logique de résistance à la malléabilité. Enfin, l’outil de démonstration git-chain-malleator publié par Ginesin peut servir de base de test interne pour évaluer si une chaîne d’intégration continue donnée est vulnérable à ce type de contournement, avant même qu’un correctif officiel ne soit disponible.
Prédictions : ce qui va probablement se passer d’ici la fin de l’année
Plusieurs scénarios semblent plausibles pour les mois à venir, à la lumière de la chronologie observée et des précédents comparables dans l’écosystème de la signature cryptographique.
- GitHub finira probablement par publier un avis de sécurité ou une mise à jour de documentation clarifiant ce que le badge “Verified” garantit réellement, sans nécessairement corriger le comportement sous-jacent à court terme, à l’image de la façon dont les plateformes traitent habituellement les problèmes de sémantique plutôt que de faille exploitable directement.
- Sigstore et les outils de signature d’artefacts basés sur Rekor devraient accélérer l’intégration d’une étape de canonicalisation de signature en amont du calcul de hash, capitalisant sur les avis de sécurité déjà publiés en 2026 sur des problèmes connexes de liaison de charge utile.
- Des outils tiers de vérification de provenance (SBOM, scanners de chaîne d’approvisionnement) commenceront probablement à intégrer une détection de malléabilité de commit comme nouveau critère d’audit, un peu comme les scanners de dépendances ont intégré la détection de typosquatting après les incidents de paquets malveillants des années précédentes.
- Il est probable qu’un identifiant CVE finisse par être attribué à au moins l’une des trois classes de malléabilité documentées par Ginesin, ne serait-ce que pour faciliter le suivi par les outils de gestion de vulnérabilités, même si l’attaque ne permet pas de modifier le contenu du code.
- Des chercheurs indépendants vont vraisemblablement tester si des variantes de cette malléabilité existent dans d’autres systèmes de contrôle de version distribués ou dans d’autres formats de signature d’artefacts logiciels (conteneurs, paquets npm ou PyPI signés), élargissant le périmètre de la découverte initiale de Ginesin.
Le contexte réglementaire français et européen
Cette découverte arrive à un moment où la réglementation européenne place justement la signature du code au centre de ses exigences de conformité. Le Cyber Resilience Act impose déjà aux fabricants de produits comportant des éléments numériques de démontrer l’intégrité de leur chaîne de production logicielle, ce qui inclut typiquement la vérification de l’origine du code source via des mécanismes de signature. Une faille qui affaiblit la garantie d’unicité d’un commit signé, même si elle ne permet pas de modifier le contenu du code, complique la tâche des auditeurs qui doivent désormais tenir compte du fait qu’un même commit logique peut légitimement porter plusieurs hashes distincts, tous vérifiés.
Pour les équipes françaises et européennes soumises à des obligations de traçabilité logicielle, la prudence recommande de documenter explicitement, dans leurs procédures internes, la distinction entre “signature valide” et “identifiant unique du commit”, afin d’éviter qu’un auditeur externe ne découvre la nuance après coup. Cette clarification, simple sur le papier, demande en pratique une révision des outils de vérification automatisée déployés dans les pipelines d’intégration continue, ce qui prendra du temps à se généraliser à l’échelle du secteur.
Foire aux questions
Un attaquant peut-il modifier le code d’un commit signé grâce à cette faille ?
Non. La malléabilité découverte par Jacob Ginesin permet de produire un second commit avec un hash différent, mais le contenu (fichiers, auteur, date, message) reste strictement identique. Il ne s’agit pas d’une attaque de falsification de code.
Faut-il voler la clé privée du signataire pour exploiter cette faille ?
Non, c’est justement ce qui rend la découverte notable. L’attaque fonctionne sans accès à la clé de signature et sans casser SHA-256, en exploitant uniquement la flexibilité d’encodage des signatures ECDSA, OpenPGP et S/MIME.
Un identifiant CVE a-t-il été attribué à cette vulnérabilité ?
Non, à la date du 22 septembre 2026, aucun CVE n’a été identifié pour cette découverte spécifique, même si des avis de sécurité distincts existent pour d’autres composants de l’écosystème Sigstore.
GitHub a-t-il corrigé le problème ?
Aucun correctif public n’a été identifié du côté de GitHub, GitLab ou Sigstore à la date de publication de cet article, soit environ sept mois après le signalement initial de mars 2026.
En quoi cette faille diffère-t-elle de l’attaque SHAttered sur SHA-1 en 2017 ?
SHAttered était une collision de hash entre deux contenus différents. La malléabilité découverte par Ginesin ne repose sur aucune collision : un seul contenu signé admet plusieurs sérialisations d’octets valides, chacune produisant naturellement un hash distinct.
Migrer vers SHA-256 protège-t-il contre cette malléabilité ?
Non. Le problème ne vient pas de la fonction de hachage elle-même, mais de l’absence de canonicalisation des signatures avant le calcul du hash. SHA-256 hache fidèlement une sérialisation non canonique, ce qui reproduit le même défaut qu’avec SHA-1.
Existe-t-il un outil pour tester si un dépôt est vulnérable ?
Jacob Ginesin a publié un outil de démonstration nommé git-chain-malleator sur GitHub, qui reproduit les trois classes de malléabilité (ECDSA, OpenPGP RSA/EdDSA, S/MIME) décrites dans sa recherche.
Cette faille concerne-t-elle uniquement GitHub ?
La démonstration publique cible principalement GitHub, mais le mécanisme touche le format d’objet Git lui-même et la façon dont les vérificateurs de signature traitent les encodages non canoniques, ce qui rend d’autres plateformes (GitLab compris) potentiellement concernées selon leur implémentation de vérification.
