Gitoxide corrige cinq failles de parsing qui fuient des identifiants et traversent les dossiers
Le 30 août 2026, le projet gitoxide — l’implémentation Git écrite en Rust — a publié un correctif groupé pour cinq vulnérabilités de parsing, dont une fuite d’identifiants HTTP et plusieurs traversées de dossiers via les sous-modules. La leçon pour quiconque embarque des bibliothèques Rust : la sûreté mémoire n’est pas une garantie contre les bugs de logique.
30 août 2026. Le projet gitoxide, l’implémentation du protocole Git réécrite intégralement en Rust, publie un correctif groupé pour cinq vulnérabilités de parsing. La plus grave, CVE-2026-82247, laisse un serveur hostile exfiltrer les identifiants HTTP Basic d’un clone via une simple redirection. Trois autres (CVE-2026-82251, CVE-2026-82252, CVE-2026-82253) exploitent les noms de sous-modules pour lire ou écrire hors de l’arborescence du dépôt. Une cinquième (CVE-2026-82254) transforme un pack malformé en déni de service. Le paradoxe est entier : Rust a éliminé la corruption mémoire, mais pas les bugs de logique.
Un correctif groupé qui cible le parsing, pas la mémoire
gitoxide est le projet de Sebastian Thiel, connu sous le pseudonyme Byron, qui vise depuis des années à remplacer l’écosystème Git traditionnel par une pile 100 % Rust, des crates gix jusqu’à un binaire gix qui se substitue à git. L’argument est double : d’abord la sûreté mémoire — pas de use-after-free, pas de débordement de tampon —, ensuite la portabilité, une seule implémentation compilée partout sans dépendre de libgit2 ni du git système. Le projet a gagné en maturité au point d’être tiré comme dépendance par des outils de CI, des plateformes d’analyse de code et des interfaces Git alternatives.
Les cinq failles publiées le 30 août 2026 montrent précisément où se situe le risque résiduel. Aucune n’est une corruption mémoire. Toutes sont des bugs de logique : un parseur d’URL qui ne respecte pas une RFC, une validation de nom qui ne regarde qu’une occurrence de .., un suivi de lien symbolique trop confiant. La sûreté mémoire protège contre une classe d’erreurs ; elle ne dit rien sur ce qui se passe quand le code accorde sa confiance à une chaîne de caractères hostile.
CVE-2026-82247 : la fuite d’identifiants par redirection
La faille la plus parlante est CVE-2026-82247 (CVSS 7.5). Le parseur d’URL de la crate gix-url (versions ≤ 0.32.0, corrigé en 0.37.1) ne traite pas ? ni # comme terminateurs de l’autorité, contrairement à ce qu’exige la RFC 3986. En temps normal, une URL se décompose en schéma://autorité/chemin?requête#fragment : le ? et le # marquent la fin de la partie « autorité », celle qui porte l’hôte.
En ignorant ces terminateurs, gix-url produit une autorité trop longue. Le garde-fou anti-redirection de gix-transport (versions ≤ 0.49.0, corrigé en 0.58.1), censé empêcher la réutilisation des identifiants vers un hôte tiers, compare alors la mauvaise chaîne. Résultat : un attaquant qui contrôle la réponse de redirection peut forger un en-tête Location de la forme <hôte-attaquant>?@<hôte-original>. Le parseur croit que la cible est l’hôte d’origine, et transmet les identifiants HTTP Basic au serveur de l’attaquant.
Le scénario d’exploitation est concret : un outil qui clone un dépôt privé avec un jeton d’accès ou un mot de passe CI embarqué dans l’URL, et qui passe par gitoxide, peut voir ce secret fuiter vers un serveur contrôlé, à la seule condition que l’attaquant contrôle le point de redirection. C’est exactement le genre de fuite que les audits de supply chain cherchent à éliminer.
Les sous-modules, angle mort du parsing
Les trois failles suivantes partagent la même racine : le traitement des fichiers .gitmodules, que gitoxide analyse sans réutiliser la logique éprouvée de git ou de libgit2. Réécrire un format de zéro, c’est réécrire aussi ses pièges.
CVE-2026-82251 (avant 0.52.1) : les noms de sous-modules ne sont pas validés, ce qui autorise une traversée de dossiers quand le dépôt dérive les chemins de .git/modules. Un .gitmodules malveillant peut rediriger les opérations d’état vers un dépôt contrôlé par l’attaquant — une confusion de dépôt, pas une simple lecture.
CVE-2026-82252 : gitoxide suit les liens symboliques en lisant .gitmodules, ce qui permet d’injecter et de parser des fichiers arbitraires situés hors de l’arborescence du dépôt. Un dépôt conçu pour être cloné devient un vecteur de lecture locale.
CVE-2026-82253 (crates gix ≤ 0.72.0 et gix-validate ≤ 0.10.0) : la fonction de validation ne vérifie que la première occurrence de .. via name.find(b".."). Un nom comme a..b/../../../.git/ contourne donc le contrôle — et cette validation n’est de toute façon jamais invoquée dans les chemins de code de production. Combinée à un défaut d’héritage de confiance (Submodule::open copie la confiance du dépôt parent sans vérifier la propriété), elle aboutit à une lecture de fichiers arbitraires.
Enfin, CVE-2026-82254 (avant 0.69.0) permet un déni de service pendant un git clone ou un git fetch via des données de pack spécialement conçues. C’est la moins grave, mais elle rappelle que chaque surface d’entrée — l’URL, les sous-modules, le pack binaire — doit être traitée comme hostile.
Pourquoi c’est un problème de supply chain
L’angle le plus important n’est pas technique, il est écosystémique. gitoxide est en train de devenir un composant d’infrastructure : une bibliothèque de ce type se propage à tout ce qui la consomme, sans que le consommateur ait conscience d’analyser des entrées non fiables. Une faille de parsing dans une dépendance transitive est souvent invisible dans les tableaux de bord de sécurité, qui remontent les CVE des applications mais rarement celles des bibliothèques de bas niveau.
Il faut replacer ces cinq failles dans un débat plus large. Le mouvement « réécrire en Rust » a longtemps promis que la sûreté mémoire éliminerait la majorité des vulnérabilités. La réalité, que ces CVE illustrent bien, est plus nuancée : Rust supprime les bugs de corruption mémoire, mais les bugs de logique — validation insuffisante, confiance excessive, parseurs écrits à la main — restent, eux, entièrement du ressort du programmeur. Le type de vulnérabilité change, il ne disparaît pas.
Ce qu’il faut faire
Le correctif est simple à appliquer, et la fenêtre de risque est courte si vous agissez maintenant.
- Mettre à niveau. Passez gix à ≥ 0.69.0, gix-url à ≥ 0.37.1 et gix-transport à ≥ 0.58.1. Les cinq failles sont couvertes par ces versions.
- Vérifier la dépendance transitive. Ces deux commandes disent qui, dans votre graphe, tire les crates vulnérables :
cargo tree -i gix-url
cargo tree -i gix-transportUn correctif en amont ne sert à rien si un verrou de dépendance fige une ancienne version. Mettez à jour Cargo.lock, pas seulement vos dépendances directes.
- Ne pas embarquer d’identifiants dans l’URL. La fuite de CVE-2026-82247 n’existe que parce qu’un identifiant circule dans la chaîne de connexion. Préférez un credential helper ou un jeton à portée minimale.
La leçon de fond vaut pour tout le monde, pas seulement pour les utilisateurs de Rust : un langage à sûreté mémoire protège contre une classe de bugs, pas contre toutes. Quand on réécrit un protocole aussi ancien et aussi tordu que Git, le vrai risque se déplace du compilateur vers le parseur — et un parseur écrit à la main doit être testé en différentiel contre l’implémentation de référence, comme le font les fuzzeurs de git et de libgit2.
Verdict
Si vous consommez gitoxide — directement ou en dépendance transitive — mettez à niveau gix vers ≥ 0.69.0 sans attendre, et auditez votre chaîne de clonage : tout identifiant qui transite par une URL est un identifiant qui peut fuir.
Si vous écrivez des parseurs en Rust, traitez la sûreté mémoire comme nécessaire mais jamais suffisante. Testez vos parseurs en différentiel contre l’implémentation de référence, fuzzez vos entrées, et supposez que toute donnée issue d’un dépôt distant est hostile. Le bug n’est plus la corruption mémoire — c’est la confiance que vous accordez à une chaîne de caractères.