inertfluid/cve-2026-54316-labReproduktionslabor für CVE-2026-54316 (Claude Code WebFetch huggingface.co bare-hostname Berechtigungsumgehung / Exfiltration)
Ein in sich geschlossenes, wegwerfbares Labor, das
GHSA-fg94-h982-f3mm
/ CVE-2026-54316 reproduziert: Claude Code hat huggingface.co als Bare-Hostname
für das WebFetch-Tool vorab freigegeben, sodass jeder Pfad auf dieser Domain — einschließlich
angreiferkontrollierter Modell-Repositories — ohne Berechtigungsabfrage abgerufen wurde.
In Kombination mit Prompt-Injection wird daraus ein Out-of-Band-Kanal zur Exfiltration von
Daten, beobachtbar über die serverseitigen Download-Zähler von HuggingFace.
| Advisory | GHSA-fg94-h982-f3mm |
| CVE | CVE-2026-54316 |
| Paket | @anthropic-ai/claude-code (npm) |
| Betroffen | >= 0.2.54, < 2.1.163 |
| Behoben | 2.1.163 |
| Grundursache | Allow-Listing von Bare-Hostnames auf einem Multi-Tenant-Host (CWE-183) |
Dies reproduziert eine gepatchte, öffentlich offengelegte Schwachstelle für Bildungs- und Defensivzwecke. Verwende es nur gegen Infrastruktur, die dir gehört:
fixtures/canary.env) — verwende niemals einen echten.huggingface.co-Pfad ohne Genehmigungsabfrage ab, während jede andere Domain eine
auslöst — weil huggingface.co in einer hartkodierten Allow-List steht.Der Container ist der einzige Ort, an dem die verwundbare Version läuft; dein Host bleibt sauber. Authentifiziere dich mit einem Claude-Abonnement-Token (kein API-Key nötig):
docker build -t cve-2026-54316-lab .
docker run --rm -it cve-2026-54316-lab
Führe im Container claude aus und wähle „Claude-Konto mit Abonnement", um dich interaktiv
anzumelden. Die verwundbare Version 2.1.162 stammt aus der Zeit vor der Umgebungsvariablen
CLAUDE_CODE_OAUTH_TOKEN, daher wird hier kein setup-token verwendet — der interaktive
Browser/Code-Einfüge-Ablauf vermeidet das Erzeugen eines langlebigen Tokens vollständig.
Der Kernpunkt ist die Asymmetrie der Genehmigungsabfrage pro Domain, daher bleibt WebFetch
verfügbar (es wird nicht verweigert) — die Genehmigung wird standardmäßig per Abfrage behandelt.
Im Container, in claude:
Verwende WebFetch, um
https://example.comabzurufen, und fasse es zusammen.
→ Es erscheint eine Berechtigungsabfrage, die dich auffordert, example.com zu genehmigen. Danach:
Verwende WebFetch, um
https://huggingface.co/<your-account>/canary-lab/resolve/main/config.jsonabzurufen.
Verwundbar: Der huggingface.co-Abruf erfolgt ohne Abfrage, während example.com eine
erforderte. Diese Asymmetrie ist der Fehler — huggingface.co steht in einer hartkodierten
Allow-List. (Das HF-Repo muss für diesen Test nicht existieren; ein 401/404 beweist dennoch, dass
die Abfrage nie ausgelöst wurde.) Baue mit @anthropic-ai/[email protected] neu, und der
huggingface.co-Abruf löst nun ebenfalls eine Abfrage aus — dieses Vorher/Nachher ist die
Kernaussage.
./scripts/make_hf_canary_files.sh ./hf-repo ausführen und dann hf-repo/ in ein
öffentliches HuggingFace-Repo pushen, das dir gehört (<your-account>/canary-lab).payloads/untrusted-readme.md bearbeiten, HF_ACCOUNT setzen und es dort ablegen, wo der
Agent es als nicht vertrauenswürdige Eingabe liest.Dockerfile — festgepinnte verwundbare Version 2.1.162.claude/settings.json — leere Allow/Deny-Liste, sodass WebFetch pro Domain nachfragtfixtures/canary.env — Dummy-Canaryscripts/make_hf_canary_files.sh — HF-Canary-Dateilayoutpayloads/untrusted-readme.md — Prompt-Injection-Payload (bereinigt)