CVE-2026-59891 Regression & Control Lab

Projet d'exercice isolé et d'audit en lecture seule qui compare les versions vulnérable et corrigée réelles de @sigstore/oci avec les mêmes entrées, et vérifie les conditions d'exposition selon l'environnement.

Le CVE Reporter de ce projet est gyubin02.

Résumé pour le recrutement et les entretiens : Cas d'automatisation de la gestion de la vulnérabilité CVE-2026-59891

Ce qui est vérifié

Le cœur de CVE-2026-59891 est la confusion de hostname qui se produit lors de la sélection des identifiants d'authentification du Registry.

0.7.0 : parce que cr.io est contenu dans la chaîne ghcr.io, les identifiants de ghcr.io peuvent être sélectionnés.
0.7.1 : après normalisation du hostname, seuls les identifiants correspondant exactement sont sélectionnés.

Ce dépôt valide d'abord automatiquement deux scénarios de sélection d'identifiants.

collision : seuls les identifiants ghcr.io existent, mais la cible est cr.io
exact : des identifiants cr.io correspondant exactement à la cible existent

La version vulnérable sélectionne les mauvais identifiants dans le premier scénario, et la version corrigée doit les rejeter. Les deux versions doivent réussir le second scénario normal.

On y ajoute une comparaison dynamique utilisant un mock Registry éphémère sur 127.0.0.1 au lieu d'un Registry externe réel. La version vulnérable 0.7.0 effectue 2 requêtes en local et, après le challenge d'authentification, un header Authorization synthétique est observé lors de la seconde requête. La version corrigée 0.7.1 est rejetée à l'étape de sélection des identifiants, ce qui donne 0 requête. Les résultats ne conservent que l'observation ou non et le nombre de requêtes, au lieu de la valeur du header.

CLI de vérification de l'exposition du projet

cve-2026-59891-audit lit uniquement les metadata du package-lock.json du projet cible et du Docker config explicitement spécifié, afin de distinguer les éléments suivants.

L'emplacement et la version d'installation de @sigstore/oci affectés
La présence de la version vulnérable et la satisfaction effective des conditions d'exposition
La collision de sous-chaîne du Registry et la cible réellement sélectionnée selon l'ordre des clés JSON
Les priorités par environnement, les mesures à prendre et la procédure de re-test
Les preuves JSON et Markdown avec les hostnames de Registry et les chemins absolus supprimés

Exécution immédiate avec un fixture synthétique :

npm run audit:demo

Inspection d'autres projets Node.js :

npm run audit:project -- \
  --project ../target-project \
  --docker-config ../review-copy/config.json \
  --image cr.io/example/demo \
  --destination-trust unknown \
  --format markdown \
  --output reports/cve-2026-59891.md

--destination-trust doit obligatoirement spécifier l'un des éléments suivants.

trusted : le code et la liste d'autorisation confirment que la destination est restreinte
untrusted : une entrée externe ou une entrée de workflow influence la destination
unknown : pas encore vérifié

Le verdict est divisé en exposure_conditions_met, potential_exposure, affected_component_only, not_detected, indeterminate. not_detected n'est toutefois qu'un résultat relatif à la plage d'entrées enregistrée et ne signifie ni « sûr » ni « conforme ».

Dispositifs de sécurité

Le laboratoire de régression ne lit ni ne modifie le véritable ~/.docker/config.json.
Il utilise uniquement un HOME dédié isolé et des valeurs sans intérêt lab-user / LAB_ONLY_FAKE_TOKEN.
Le paquet n'est appelé que lorsque HOME, le marqueur du laboratoire et les fausses valeurs sont tous exacts.
La sonde de régression sélective existante bloque tous les appels HTTP(S), TCP, TLS, DNS et fetch au moyen de tripwires.
Sur les surfaces réseau Node utilisées par la sonde dynamique, seules les requêtes HTTP vers le port 127.0.0.1 exact attribué par l'OS sont autorisées. Le HTTP externe ou vers un autre port, le résolveur DNS, TLS, UDP, le fetch global et WebSocket sont bloqués.
Les processus enfants n'héritent pas des jetons ni des variables d'environnement Docker de la session actuelle.
On teste que stdout/stderr et les résultats d'audit ne conservent même pas les faux en-têtes, et ne laissent que des booléens et le nombre de requêtes.
La CLI de vérification ne peut pas omettre --docker-config et ne déduit pas le fichier depuis HOME ou DOCKER_CONFIG.
La CLI ne décode, ne hache et n'affiche pas les valeurs d'identification, et n'exécute pas les paquets du projet cible, Docker ou les assistants d'identification, ni ne se connecte au réseau.
Si un lien symbolique, une clé JSON en double, un lockfile non pris en charge ou un npm-shrinkwrap.json de priorité supérieure est détecté, elle échoue sans affirmer que c'est sûr.

Comme des paquets vulnérables sont installés intentionnellement, la distribution du paquet npm est bloquée par "private": true. Il ne faut pas l'utiliser comme dépendance du code produit. Pour cette raison, le fait que npm audit signale la version 0.7.0 est un résultat attendu ; la portée et la raison de l'exception sont documentées dans SECURITY.md.

Exécution

Prérequis : Node.js 22.22.2+, 24.15.0+ ou 26 ou plus. La version recommandée est épinglée dans .nvmrc.

npm ci --ignore-scripts
npm test
npm run demo
npm run dynamic:demo
npm run audit:fixture
npm run audit:demo
npm run evidence

Résultat attendu clé de npm run demo :

0.7.0  collision  credential-selected
0.7.1  collision  credential-rejected
0.7.0  exact      credential-selected
0.7.1  exact      credential-selected

Regression result: PASS

Résultat attendu clé de npm run dynamic:demo :

{
  "vulnerable": {
    "packageVersion": "0.7.0",
    "credentialSelection": "credential-selected",
    "requestCount": 2,
    "authorizationObserved": true,
    "digestVerified": true,
    "networkPolicy": "exact-loopback-only"
  },
  "fixed": {
    "packageVersion": "0.7.1",
    "credentialSelection": "credential-rejected",
    "requestCount": 0,
    "authorizationObserved": false,
    "digestVerified": false,
    "networkPolicy": "exact-loopback-only"
  },
  "regressionResult": "PASS"
}

Il y a 34 tests automatisés au total. npm run evidence génère un total de 7 fichiers : les 6 artefacts à inspecter et le fichier SHA256SUMS qui vérifie leur intégrité.

Compétences démontrées par ce projet

Expliquer au niveau du code les conditions de déclenchement d'une CVE réelle et la reproduire de manière sûre
Concevoir des tests de régression comparant une version vulnérable et une version corrigée dans des conditions identiques
Concevoir un test en boucle locale (loopback-only) comparant dynamiquement si des identifiants synthétiques sont transmis localement
Évaluer les préconditions d'attaque en environnement réel indépendamment du score CVSS public
Identifier statiquement les formats package-lock v1, v2 et v3, les alias et les dépendances imbriquées
Générer automatiquement des preuves d'audit en JSON et Markdown excluant les informations sensibles
Gérer les vulnérabilités de la découverte → analyse d'impact → vérification du correctif → mesures de contrôle
Réaliser des tests de sécurité à sûreté intégrée (fail-safe) sans toucher aux identifiants réels

Populaires

cve-2026-59891-control-lab