⚠️ Utilisation éthique

Ceci reproduit une vulnérabilité corrigée et divulguée publiquement à des fins éducatives et défensives. Utilisez-le uniquement contre une infrastructure vous appartenant :

• Le dépôt HuggingFace et les données canary doivent être les vôtres.
• Le « secret » est une valeur factice (fixtures/canary.env) — n'utilisez jamais un vrai.
• Ne ciblez pas le dépôt d'un tiers ni de véritables identifiants.

Ce que cela prouve

1. Contournement d'invite (totalement déterministe) : un Claude Code vulnérable récupère un chemin huggingface.co sans invite d'approbation, alors que tout autre domaine en déclenche une — parce que huggingface.co se trouve dans une liste blanche codée en dur.
2. Chaîne d'exfiltration : un contenu non fiable oriente cette récupération auto-approuvée pour encoder et fuiter des données, récupérables à partir des métriques de téléchargement HF.

Configuration

Le conteneur est le seul endroit où la version vulnérable s'exécute ; votre hôte reste propre. Authentifiez-vous avec un jeton d'abonnement Claude (aucune clé API nécessaire) :

À l'intérieur du conteneur, exécutez claude et choisissez « Compte Claude avec abonnement » pour vous connecter de manière interactive. La version vulnérable 2.1.162 est antérieure à la variable d'environnement CLAUDE_CODE_OAUTH_TOKEN, donc un setup-token n'est pas utilisé ici — le flux interactif navigateur/coller-code évite complètement de créer un jeton de longue durée.

Reproduction — affirmation 1 (le contournement d'invite)

Le point est l'asymétrie de l'invite d'approbation par domaine, donc WebFetch est laissé disponible (il n'est pas refusé) — l'approbation est gérée par des invites, par défaut. À l'intérieur du conteneur, dans claude :

Utilisez WebFetch pour récupérer https://example.com et résumez-le.

→ Une invite d'autorisation apparaît vous demandant d'approuver example.com. Ensuite :

Utilisez WebFetch pour récupérer https://huggingface.co/<votre-compte>/canary-lab/resolve/main/config.json.

Vulnérable : la récupération de huggingface.co se déroule sans invite, tandis que example.com en nécessitait une. Cette asymétrie est le bogue — huggingface.co se trouve dans une liste blanche codée en dur. (Le dépôt HF n'a pas besoin d'exister pour ce test ; un code 401/404 prouve toujours que l'invite ne s'est jamais déclenchée.) Reconstruisez avec @anthropic-ai/[email protected] et la récupération de huggingface.co invite désormais aussi — cet avant/après est le titre.

Reproduction — affirmation 2 (exfiltration)

1. ./scripts/make_hf_canary_files.sh ./hf-repo, puis poussez hf-repo/ vers un dépôt HuggingFace public que vous possédez (<votre-compte>/canary-lab).
2. Modifiez payloads/untrusted-readme.md, définissez HF_ACCOUNT, et placez-le là où l'agent le lira en tant qu'entrée non fiable.
3. Exécutez l'agent sur ce contenu ; ensuite, lisez les métriques de téléchargement de votre dépôt pour reconstruire la chaîne canary.

Fichiers

• Dockerfile — version vulnérable épinglée 2.1.162
• .claude/settings.json — autorisation/refus vide afin que WebFetch invite par domaine
• fixtures/canary.env — canary factice
• scripts/make_hf_canary_files.sh — disposition des fichiers canary HF
• payloads/untrusted-readme.md — charge utile d'injection d'invite (nettoyée)