CVE-2026-54316 — Claude Code WebFetch HuggingFace डेटा निकासी प्रयोगशाला

एक स्व-निहित, डिस्पोजेबल प्रयोगशाला जो GHSA-fg94-h982-f3mm / CVE-2026-54316 को पुन: उत्पन्न करती है: Claude Code ने huggingface.co को WebFetch उपकरण के लिए एक बेयर होस्टनेम के रूप में पूर्व-अनुमोदित किया था, इसलिए उस डोमेन पर कोई भी पथ — जिसमें हमलावर-नियंत्रित मॉडल रिपॉजिटरी शामिल हैं — बिना अनुमति संकेत के लाया गया था। प्रॉम्प्ट इंजेक्शन के साथ मिलकर, यह डेटा निकासी के लिए एक आउट-ऑफ-बैंड चैनल बन जाता है, जिसे HuggingFace के सर्वर-साइड डाउनलोड गणनाओं के माध्यम से देखा जाता है।

सलाहकार	GHSA-fg94-h982-f3mm
CVE	CVE-2026-54316
पैकेज	@anthropic-ai/claude-code (npm)
प्रभावित	>= 0.2.54, < 2.1.163
पैच किया गया	2.1.163
मूल कारण	मल्टी-टेनेंट होस्ट पर बेयर-होस्टनेम अनुमति-सूची (CWE-183)

⚠️ नैतिक उपयोग

यह एक पैच किए गए, सार्वजनिक रूप से खुलासा किए गए कमजोरी को शैक्षिक और रक्षात्मक उद्देश्यों के लिए पुन: उत्पन्न करता है। इसका उपयोग केवल आपके अपने बुनियादी ढांचे के खिलाफ करें:

• दोनों HuggingFace रिपो और कैनरी डेटा आपके ही होने चाहिए।
• "secret" एक डमी मान है (fixtures/canary.env) — कभी भी वास्तविक का उपयोग न करें।
• किसी तीसरे पक्ष की रिपॉजिटरी या वास्तविक क्रेडेंशियल्स को लक्षित न करें।

यह क्या साबित करता है

1. प्रॉम्प्ट बायपास (पूरी तरह से निर्धारणीय): एक कमजोर Claude Code huggingface.co पथ को बिना किसी अनुमोदन संकेत के लाता है, जबकि हर दूसरा डोमेन एक को ट्रिगर करता है — क्योंकि huggingface.co एक हार्डकोडेड अनुमति-सूची में बैठता है।
2. डेटा निकासी श्रृंखला: अविश्वसनीय सामग्री उस स्वतः-अनुमोदित फ़ेच को डेटा को एन्कोड और लीक करने के लिए निर्देशित करती है, जिसे HF डाउनलोड मीट्रिक्स से पुनर्प्राप्त किया जा सकता है।

सेटअप

कंटेनर ही एकमात्र स्थान है जहां कमजोर संस्करण चलता है; आपका होस्ट साफ रहता है। एक Claude सब्सक्रिप्शन टोकन से प्रमाणित करें (कोई API कुंजी आवश्यक नहीं):

docker build -t cve-2026-54316-lab .
docker run --rm -it cve-2026-54316-lab

कंटेनर के अंदर claude चलाएं और इंटरैक्टिव रूप से लॉग इन करने के लिए "Claude account with subscription" चुनें। कमजोर 2.1.162 CLAUDE_CODE_OAUTH_TOKEN env var से पहले का है, इसलिए यहां setup-token का उपयोग नहीं किया गया है — इंटरैक्टिव ब्राउज़र/पेस्ट-कोड प्रवाह एक दीर्घकालिक टोकन को मिंट करने से बचाता है।

पुन: उत्पन्न करें — दावा 1 (प्रॉम्प्ट बायपास)

बात प्रति-डोमेन अनुमोदन संकेत असममिति है, इसलिए WebFetch उपलब्ध छोड़ दिया गया है (इससे इनकार नहीं किया गया है) — अनुमोदन डिफ़ॉल्ट रूप से संकेत द्वारा नियंत्रित किया जाता है। कंटेनर के अंदर, claude में:

https://example.com लाने और उसका सारांश बनाने के लिए WebFetch का उपयोग करें।

→ एक अनुमति संकेत प्रकट होता है जो आपको example.com को अनुमोदित करने के लिए कहता है। फिर:

https://huggingface.co/<your-account>/canary-lab/resolve/main/config.json लाने के लिए WebFetch का उपयोग करें।

कमजोर: huggingface.co फ़ेच बिना किसी संकेत के आगे बढ़ता है, जबकि example.com के लिए एक की आवश्यकता थी। वह असममिति ही बग है — huggingface.co एक हार्डकोडेड अनुमति-सूची में है। (इस परीक्षण के लिए HF रिपो का अस्तित्व में होना आवश्यक नहीं है; 401/404 अभी भी साबित करता है कि संकेत कभी नहीं निकला।) @anthropic-ai/[email protected] के साथ पुनर्निर्माण करें और huggingface.co फ़ेच अब भी संकेत देता है — वह पहले/बाद हेडलाइन है।

पुन: उत्पन्न करें — दावा 2 (डेटा निकासी)

1. ./scripts/make_hf_canary_files.sh ./hf-repo चलाएं, फिर hf-repo/ को अपने स्वामित्व वाले सार्वजनिक HuggingFace रिपो (<your-account>/canary-lab) पर पुश करें।
2. payloads/untrusted-readme.md को संपादित करें, HF_ACCOUNT सेट करें, और इसे वहां रखें जहां एजेंट इसे अविश्वसनीय इनपुट के रूप में पढ़ेगा।
3. उस सामग्री पर एजेंट चलाएं; उसके बाद कैनरी स्ट्रिंग को पुनर्निर्माण करने के लिए अपनी रिपो के डाउनलोड मीट्रिक्स पढ़ें।

फ़ाइलें

• Dockerfile — पिन किया गया कमजोर 2.1.162
• .claude/settings.json — खाली अनुमति/अस्वीकार ताकि WebFetch प्रति-डोमेन संकेत दे
• fixtures/canary.env — डमी कैनरी
• scripts/make_hf_canary_files.sh — HF कैनरी-फ़ाइल लेआउट
• payloads/untrusted-readme.md — प्रॉम्प्ट-इंजेक्शन पेलोड (सैनिटाइज़ किया गया)