CVE-2026-59891 Regression & Control Lab

Um projeto de laboratório isolado e auditoria somente leitura que compara as versões vulnerável e corrigida reais do @sigstore/oci com a mesma entrada e verifica as condições de exposição por ambiente.

O CVE Reporter deste projeto é o gyubin02.

Resumo para recrutamento/entrevistas: Caso de automação do gerenciamento da vulnerabilidade CVE-2026-59891

O que este projeto verifica

O núcleo do CVE-2026-59891 é a confusão de hostname que ocorre ao selecionar as credenciais do Registry.

0.7.0: pode selecionar as credenciais de ghcr.io pelo fato de cr.io estar contido na string ghcr.io.
0.7.1: normaliza o hostname e seleciona apenas as credenciais que correspondem exatamente.

Este repositório primeiro valida automaticamente dois cenários de seleção de credenciais.

collision: existem apenas credenciais de ghcr.io, mas o destino é cr.io
exact: existem credenciais de cr.io que correspondem exatamente ao destino

A versão vulnerável deve selecionar incorretamente as credenciais no primeiro cenário, e a versão corrigida deve rejeitá-las. Ambas as versões devem ter sucesso no segundo cenário, que é o normal.

Além disso, foi adicionada uma comparação dinâmica que usa um Registry mock descartável em 127.0.0.1 em vez de um Registry externo real. A versão vulnerável 0.7.0 faz 2 solicitações localmente e, após o desafio de autenticação, um header Authorization sintético é observado na segunda solicitação. A versão corrigida 0.7.1 é rejeitada na etapa de seleção de credenciais, resultando em 0 solicitações. Nos resultados, restam apenas a indicação de observação e o número de solicitações, em vez do valor do header.

CLI de verificação de exposição do projeto

O cve-2026-59891-audit lê apenas os metadados do package-lock.json do projeto alvo e do Docker config especificado explicitamente, distinguindo o seguinte:

Localização e versão da instalação afetada do @sigstore/oci
Presença de versão vulnerável e se as condições reais de exposição são atendidas
Conflito de substring do Registry e o alvo realmente selecionado de acordo com a ordem das chaves JSON
Prioridades por ambiente, ações corretivas e procedimentos de novo teste
Evidências em JSON e Markdown com o hostname do Registry e caminhos absolutos removidos

Execute diretamente com um fixture sintético:

npm run audit:demo

Para verificar outro projeto 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

O --destination-trust deve ser explicitamente definido como um dos seguintes valores:

trusted: confirma que o destination é restrito por código e allowlist
untrusted: entradas externas ou entradas de workflow afetam o destination
unknown: ainda não foi possível confirmar

O veredito é dividido em exposure_conditions_met, potential_exposure, affected_component_only, not_detected e indeterminate. O not_detected também é apenas um resultado para o escopo de entrada registrado; não significa “seguro” nem “conformidade”.

Salvaguardas

O laboratório de regressão não lê nem modifica o ~/.docker/config.json real.
Usa apenas um HOME dedicado e isolado e o lab-user / LAB_ONLY_FAKE_TOKEN sem valor.
Invoca o pacote somente quando o HOME, o marcador do laboratório e os valores falsos estão todos corretos.
A probe de regressão de seleção existente bloqueia todas as chamadas HTTP(S), TCP, TLS, DNS e fetch como tripwire.
Na superfície de rede Node usada pela probe dinâmica, apenas solicitações HTTP para a porta exata 127.0.0.1 atribuída pelo SO são permitidas. HTTP externo ou em outras portas, resolver DNS, TLS, UDP, fetch global e WebSocket são bloqueados.
Não repassa tokens da sessão atual nem variáveis de ambiente do Docker para processos filhos.
Testa que stdout/stderr e os resultados da auditoria não armazenam nem mesmo um header falso, mantendo apenas booleanos e o número de solicitações.
A CLI de verificação não permite omitir --docker-config e não infere o arquivo a partir de HOME nem de DOCKER_CONFIG.
A CLI não decodifica, calcula hash nem exibe valores de credenciais, e não executa pacotes do projeto alvo, Docker nem credential helpers, e não acessa a rede.

Como o pacote vulnerável é instalado intencionalmente, a publicação do pacote npm foi bloqueada com "private": true. Ele não deve ser usado como dependência em código de produção. Por isso, o npm audit relatar 0.7.0 é um resultado esperado; o escopo e o motivo da exceção estão documentados no SECURITY.md.

Execução

Requisitos: Node.js 22.22.2+, 24.15.0+ ou 26 ou superior. A versão recomendada está fixada no .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

Principais resultados esperados do 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

Principais resultados esperados do 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"
}

São 34 testes automatizados no total. O npm run evidence gera 7 arquivos no total: os 6 artefatos inspecionados mais o SHA256SUMS, que verifica a integridade deles.

Competências que este projeto demonstra

Explicar no nível do código as condições de ocorrência de um CVE real e reproduzi-lo com segurança
Projetar testes de regressão que comparam as versões vulnerável e corrigida nas mesmas condições
Projetar testes somente loopback que comparam dinamicamente até mesmo se credenciais sintéticas são transmitidas localmente
Avaliar as premissas reais de ataque no ambiente, de forma independente do CVSS público
Identificar estaticamente package-lock v1, v2 e v3, aliases e dependências aninhadas
Gerar automaticamente evidências de auditoria em JSON e Markdown sem segredos
Gerenciamento de vulnerabilidades que flui da descoberta → análise de impacto → verificação da correção → controle
Testes de segurança à prova de falhas que não tocam em credenciais reais

Fontes e escopo

Este projeto é uma avaliação controlada limitada, de caráter educacional. Os resultados de loopback demonstram apenas diferenças de comportamento em um ambiente sintético; eles não demonstram exposição ou comprometimento de credenciais nem a eficácia de controles em um ambiente corporativo real. Não significa qualificação CISA, certificação ISMS-P nem conformidade regulatória de qualquer organização específica. O Node API guard é uma camada de defesa para os caminhos de execução observados da dependência bloqueada; não é um network namespace nem um firewall no nível do SO.

A documentação detalhada de escopo, testes, riscos e controles está em docs/, e o npm run evidence gera evidências de execução reproduzíveis e um manifest SHA-256.

Mais Populares

cve-2026-59891-control-lab