⚠️ Uso ético

Este laboratório reproduz uma vulnerabilidade corrigida e divulgada publicamente para fins educacionais e defensivos. Use-o apenas contra infraestrutura que você possui:

• Tanto o repositório do HuggingFace quanto os dados canário devem ser seus.
• O "segredo" é um valor fictício (fixtures/canary.env) — nunca use um real.
• Não ataque o repositório de terceiros nem credenciais reais.

O que isso demonstra

1. Bypass de prompt (totalmente determinístico): um Claude Code vulnerável busca um caminho em huggingface.co sem solicitação de aprovação, enquanto qualquer outro domínio gera uma — porque huggingface.co está em uma lista de permissões fixa (hardcoded).
2. Cadeia de exfiltração: conteúdo não confiável direciona essa busca pré-aprovada para codificar e vazar dados, recuperáveis a partir das métricas de download do HF.

Configuração

O contêiner é o único lugar onde a versão vulnerável é executada; seu host permanece limpo. Autentique-se com um token de assinatura do Claude (nenhuma chave de API é necessária):

Dentro do contêiner, execute claude e selecione "Claude account with subscription" para fazer login interativamente. A versão vulnerável 2.1.162 é anterior à variável de ambiente CLAUDE_CODE_OAUTH_TOKEN, portanto um setup-token não é usado aqui — o fluxo interativo de navegador/colagem de código evita totalmente a criação de um token de longa duração.

Reprodução — afirmação 1 (o bypass de prompt)

O ponto central é a assimetria da solicitação de aprovação por domínio; por isso, o WebFetch permanece disponível (não é negado) — a aprovação é tratada por meio de prompts, o comportamento padrão. Dentro do contêiner, no claude:

Use o WebFetch para buscar https://example.com e resumi-lo.

→ Uma solicitação de permissão aparece pedindo que você aprove example.com. Depois:

Use o WebFetch para buscar https://huggingface.co/<your-account>/canary-lab/resolve/main/config.json.

Vulnerável: a busca em huggingface.co prossegue sem prompt, enquanto example.com exigiu um. Essa assimetria é o bug — huggingface.co está em uma lista de permissões fixa (hardcoded). (O repositório do HF não precisa existir para este teste; um 401/404 ainda prova que o prompt nunca foi acionado.) Reconstrua com @anthropic-ai/[email protected] e a busca em huggingface.co agora também gera prompt — esse antes/depois é o destaque.

Reprodução — afirmação 2 (exfiltração)

1. ./scripts/make_hf_canary_files.sh ./hf-repo e depois envie hf-repo/ para um repositório público do HuggingFace que você possui (<your-account>/canary-lab).
2. Edite payloads/untrusted-readme.md, defina HF_ACCOUNT e coloque-o onde o agente o lerá como entrada não confiável.
3. Execute o agente sobre esse conteúdo; depois, leia as métricas de download do seu repositório para reconstruir a string canário.

Arquivos

• Dockerfile — versão vulnerável fixada 2.1.162
• .claude/settings.json — allow/deny vazios para que o WebFetch solicite prompt por domínio
• fixtures/canary.env — canário fictício
• scripts/make_hf_canary_files.sh — estrutura de arquivos canário do HF
• payloads/untrusted-readme.md — payload de injeção de prompt (sanitizado)