⚠️ Ethical use

This reproduces a patched, publicly disclosed vulnerability for educational and defensive purposes. Use it only against infrastructure you own:

• Both the HuggingFace repo and the canary data must be yours.
• The "secret" is a dummy value (fixtures/canary.env) — never use a real one.
• Do not target any third party's repository or real credentials.

What this proves

1. Prompt bypass (fully deterministic): a vulnerable Claude Code fetches a huggingface.co path with no approval prompt, while every other domain triggers one — because huggingface.co sits in a hardcoded allow-list.
2. Exfiltration chain: untrusted content steers that auto-approved fetch to encode and leak data, recoverable from HF download metrics.

Setup

The container is the only place the vulnerable version runs; your host stays clean. Authenticate with a Claude subscription token (no API key needed):

Inside the container run claude and pick "Claude account with subscription" to log in interactively. The vulnerable 2.1.162 predates the CLAUDE_CODE_OAUTH_TOKEN env var, so a setup-token is not used here — the interactive browser/paste-code flow avoids minting a long-lived token at all.

Reproduce — claim 1 (the prompt bypass)

The point is the per-domain approval prompt asymmetry, so WebFetch is left available (it is not denied) — approval is handled by prompting, the default. Inside the container, in claude:

Use WebFetch to fetch https://example.com and summarize it.

→ A permission prompt appears asking you to approve example.com. Then:

Use WebFetch to fetch https://huggingface.co/<your-account>/canary-lab/resolve/main/config.json.

Vulnerable: the huggingface.co fetch proceeds with no prompt, while example.com required one. That asymmetry is the bug — huggingface.co is in a hardcoded allow-list. (The HF repo need not exist for this test; a 401/404 still proves the prompt never fired.) Rebuild with @anthropic-ai/[email protected] and the huggingface.co fetch now prompts too — that before/after is the headline.

Reproduce — claim 2 (exfiltration)

1. ./scripts/make_hf_canary_files.sh ./hf-repo, then push hf-repo/ to a public HuggingFace repo you own (<your-account>/canary-lab).
2. Edit payloads/untrusted-readme.md, set HF_ACCOUNT, and place it where the agent will read it as untrusted input.
3. Run the agent over that content; afterward read your repo's download metrics to reconstruct the canary string.

Files

• Dockerfile — pinned vulnerable 2.1.162
• .claude/settings.json — empty allow/deny so WebFetch prompts per-domain
• fixtures/canary.env — dummy canary
• scripts/make_hf_canary_files.sh — HF canary-file layout
• payloads/untrusted-readme.md — prompt-injection payload (sanitized)