CVE-2026-59891 Regression & Control Lab

Progetto di laboratorio isolato e di audit in sola lettura che confronta la versione realmente vulnerabile e quella corretta di @sigstore/oci con lo stesso input e verifica le condizioni di esposizione per ambiente.

Il CVE Reporter di questo progetto è gyubin02.

Riepilogo per assunzioni e colloqui: Caso di automazione della gestione della vulnerabilità CVE-2026-59891

Cosa viene verificato

Il cuore di CVE-2026-59891 è la confusione di hostname che si verifica quando vengono selezionate le credenziali del Registry.

0.7.0: può selezionare le credenziali di ghcr.io per il solo fatto che cr.io è contenuta nella stringa ghcr.io.
0.7.1: dopo aver normalizzato l'hostname, seleziona solo le credenziali che corrispondono esattamente.

Questo repository verifica automaticamente due scenari di selezione delle credenziali.

collision: sono presenti solo le credenziali di ghcr.io, ma la destinazione è cr.io
exact: sono presenti credenziali cr.io che corrispondono esattamente alla destinazione

La versione vulnerabile deve selezionare erroneamente le credenziali nel primo scenario, mentre la versione corretta deve rifiutarle. Entrambe le versioni devono invece superare con successo il secondo scenario normale.

È stato inoltre aggiunto un confronto dinamico che utilizza un mock Registry usa-e-getta su 127.0.0.1 invece di un Registry esterno reale. La versione vulnerabile 0.7.0 effettua 2 richieste in locale e, dopo la sfida di autenticazione, nella seconda richiesta viene osservato un header Authorization sintetico. La versione corretta 0.7.1 viene rifiutata in fase di selezione delle credenziali e le richieste sono 0. Nel risultato restano solo l'osservazione e il numero di richieste, non il valore dell'header.

CLI di verifica dell'esposizione del progetto

cve-2026-59891-audit legge solo i metadati di package-lock.json del progetto target e del Docker config specificato esplicitamente, distinguendo quanto segue.

Posizione di installazione e versione di @sigstore/oci interessate
Presenza della versione vulnerabile ed eventuale soddisfacimento delle condizioni di esposizione reali
Conflitto di sottostringa del Registry e destinazione effettivamente selezionata in base all'ordine delle chiavi JSON
Priorità per ambiente, azioni correttive e procedure di retest
Prove JSON e Markdown con hostname del Registry e percorsi assoluti rimossi

Esecuzione immediata con fixture sintetiche:

npm run audit:demo

Verifica di un altro progetto 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 deve essere specificato con uno dei seguenti valori.

trusted: conferma che la destinazione è limitata dal codice e da una allowlist
untrusted: input esterni o input del workflow influenzano la destinazione
unknown: non ancora verificato

Il verdetto si divide in exposure_conditions_met, potential_exposure, affected_component_only, not_detected e indeterminate. Anche not_detected è solo il risultato relativo all'ambito di input registrato e non significa “sicuro” né “conforme alle normative”.

Salvaguardie

Il lab di regressione non legge né modifica il ~/.docker/config.json reale.
Utilizza solo una HOME dedicata e isolata e credenziali senza valore lab-user / LAB_ONLY_FAKE_TOKEN.
Chiama il pacchetto solo quando HOME, il marcatore del lab e i valori fittizi sono tutti corretti.
Le probe di regressione della selezione esistenti bloccano come tripwire tutte le chiamate HTTP(S), TCP, TLS, DNS e fetch.
Nella superficie di rete Node utilizzata dalle probe dinamiche sono consentite solo richieste HTTP sulla porta 127.0.0.1 assegnata esattamente dal sistema operativo. HTTP esterno o su altre porte, resolver DNS, TLS, UDP, fetch globale e WebSocket sono bloccati.
Non trasmette ai processi figli i token della sessione corrente né le variabili d'ambiente Docker.
Verifica tramite test che stdout/stderr e i risultati di audit non conservino nemmeno header fittizi, ma solo boolean e numero di richieste.
La CLI di verifica non può omettere --docker-config e non deduce il file da HOME o DOCKER_CONFIG.
La CLI non decodifica, non applica hash e non stampa i valori delle credenziali; non esegue i pacchetti del progetto target, Docker o credential helper e non accede alla rete.

Poiché il pacchetto vulnerabile viene installato intenzionalmente, la pubblicazione del pacchetto npm è bloccata tramite "private": true. Non deve essere usato come dipendenza di codice di produzione. Per questo motivo, la segnalazione di 0.7.0 da parte di npm audit è un risultato atteso; ambito e motivazione dell'eccezione sono documentati in SECURITY.md.

Esecuzione

Requisiti: Node.js 22.22.2+, 24.15.0+ o 26 e successive. La versione consigliata è fissata in .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

Risultati principali attesi di 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

Risultati principali attesi di 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"
}

I test automatizzati sono in tutto 34. npm run evidence genera in totale 7 file: 6 artefatti da esaminare più SHA256SUMS, che ne verifica l'integrità.

Competenze dimostrate da questo progetto

Spiegare a livello di codice le condizioni di insorgenza di una CVE reale e riprodurla in modo sicuro
Progettare test di regressione che confrontano la versione vulnerabile e quella corretta nelle stesse condizioni
Progettare test solo-loopback che confrontano dinamicamente anche l'eventuale trasmissione locale di credenziali sintetiche
Valutare i prerequisiti di attacco dell'ambiente reale separatamente dal CVSS pubblico
Identificare staticamente package-lock v1, v2 e v3, alias e dependency annidate
Generare automaticamente prove di audit JSON e Markdown prive di informazioni segrete
Gestire le vulnerabilità con un flusso che va dalla scoperta → all'analisi dell'impatto → alla verifica della correzione → al controllo
Test di sicurezza fail-safe che non toccano credenziali reali

Fonti e ambito

Questo progetto è una valutazione di controllo limitata e a scopo didattico. I risultati loopback dimostrano solo le differenze di comportamento in un ambiente sintetico e non dimostrano l'esposizione o la compromissione di credenziali, né l'efficacia dei controlli in un ambiente aziendale reale. Non implica una qualifica CISA, una certificazione ISMS-P o la conformità normativa di una specifica organizzazione. Il Node API guard è un livello di difesa per i percorsi di esecuzione osservati delle dependency bloccate, non un network namespace o un firewall a livello di sistema operativo.

La documentazione dettagliata su ambito, test, rischi e controlli è disponibile in docs/; npm run evidence genera prove di esecuzione riproducibili e un manifest SHA-256.

Più Popolari

cve-2026-59891-control-lab