Claude Cowork उपयोगकर्ता फ़ाइलों को बाहर लीक करता है

 (promptarmor.com)
6 पॉइंट द्वारा GN⁺ 2026-01-15 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Claude Cowork के code execution environment की एक कमजोरी का उपयोग करके, हमलावर उपयोगकर्ता की फ़ाइलों को अपने Anthropic account में upload कर सकता है
  • यह कमजोरी Claude.ai chat environment में पहले ही report की जा चुकी थी, लेकिन ठीक नहीं की गई, और Cowork में भी उसी रूप में मौजूद है
  • हमला छिपे हुए prompt injection वाले document file के ज़रिए चलता है, और Cowork उसे analyze करते समय अपने-आप फ़ाइल को बाहर भेज देता है
  • मानव approval के बिना Cowork हमलावर की API key का उपयोग करके Anthropic API के माध्यम से data exfiltration करता है
  • यह संरचना आम उपयोगकर्ताओं को आसानी से expose कर सकती है, और AI agent की security risk तथा prompt injection defense के महत्व को उजागर करती है

कमजोरी का अवलोकन

  • Claude Cowork, Anthropic द्वारा जारी किया गया general-purpose work AI agent research preview है, जिसमें internet access capability शामिल है
  • PromptArmor ने दिखाया कि Cowork के coding environment में बची हुई unpatched vulnerability का उपयोग करके उपयोगकर्ता की फ़ाइलों को बाहर लीक किया जा सकता है
    • यह कमजोरी पहले Johann Rehberger ने Claude.ai में खोजकर public की थी, और Anthropic इसके बारे में जानता था लेकिन इसे ठीक नहीं किया
  • Anthropic ने Cowork उपयोग करते समय “prompt injection का संदेह पैदा करने वाले व्यवहार पर ध्यान दें” जैसी चेतावनी दी, लेकिन इसे non-expert users के लिए व्यवहारिक रूप से कठिन मांग बताया गया
  • PromptArmor ने इस जोखिम के बारे में उपयोगकर्ताओं को आगाह करने के लिए public demonstration किया

हमला श्रृंखला (Attack Chain)

  • हमला Anthropic API की allowlist का दुरुपयोग करके Claude के VM environment से data को बाहर भेजता है
  1. उपयोगकर्ता गोपनीय real estate files वाले local folder को Cowork से connect करता है
  2. उपयोगकर्ता hidden prompt injection वाला document file (.docx) upload करता है
    • document को ‘Skill’ file के रूप में disguise किया गया है, और injection 1-point white text और 0.1 line spacing में छिपा होता है
  3. उपयोगकर्ता upload की गई ‘Skill’ का उपयोग करके Cowork से file analysis का अनुरोध करता है
  4. injection, Cowork को manipulate करके हमलावर की Anthropic API key का उपयोग करने वाला cURL request चलवाता है, जिससे उपयोगकर्ता की फ़ाइलें हमलावर के account में upload हो जाती हैं
    • मानव approval प्रक्रिया के बिना automatic execution
    • Claude का VM अधिकांश external network को block करता है, लेकिन Anthropic API trusted destination के रूप में pass हो जाता है
  5. हमलावर अपने Anthropic account में पीड़ित की फ़ाइलें देख सकता है और Claude से बातचीत कर सकता है
    • लीक हुई फ़ाइलों में financial information और partial social security number (SSN) शामिल थे

मॉडल-विशिष्ट resilience (Model-specific Resilience)

  • ऊपर का हमला Claude Haiku model पर demonstrate किया गया
  • Claude Opus 4.5 में injection resistance अधिक है, लेकिन Cowork environment में indirect prompt injection के माध्यम से वही file upload vulnerability फिर भी exploit की जा सकती है
    • test में यह मान लिया गया कि उपयोगकर्ता ने malicious integration guide upload किया है, और customer records हमलावर के account में exfiltrate हो गए

malformed files के ज़रिए service denial (DOS via Malformed Files)

  • Claude का API file extension और actual format मेल न खाने पर बार-बार errors पैदा करता है
    • उदाहरण: यदि .pdf extension वाली simple text file पढ़ने की कोशिश की जाए, तो उसके बाद सभी conversations में API error होने लगती है
  • ऐसे errors को indirect prompt injection के ज़रिए limited denial-of-service (DOS) attack में बदला जा सकता है
    • malformed file generate और upload करवाकर Claude client और Anthropic console में error alerts उत्पन्न किए जा सकते हैं

agentic blast radius का जोखिम

  • Cowork को browser, MCP server, AppleScript control आदि सहित रोज़मर्रा के work environment के व्यापक हिस्सों के साथ interact करने के लिए design किया गया है
  • इससे sensitive data और untrusted data के mixed processing की संभावना बढ़ जाती है
  • prompt injection attack surface लगातार फैल रहा है, और connector configure करते समय सावधानी आवश्यक है
  • इस demonstration में connector का उपयोग नहीं किया गया, लेकिन connector आम उपयोगकर्ताओं के लिए प्रमुख risk factor बन सकते हैं

संबंधित पढ़ाई

2 टिप्पणियां

 
laeyoung 2026-01-15

Simon Willison के Claude Cowork पर लिखे गए रिव्यू में भी prompt injection attack को लेकर चिंता जताई गई थी, लेकिन यह तो बहुत जल्दी हो गया।
 
GN⁺ 2026-01-15
Hacker News की राय

  • अगर पता चले कि Anthropic API का दुरुपयोग हो रहा है, तो उस API key को GitHub Gist या किसी public repository में डाल सकते हैं
    Anthropic, GitHub scanning partner है, इसलिए key लगभग तुरंत revoke हो जाती है
    उसके बाद Gist को delete किया जा सकता है, और OpenAI जैसे दूसरे providers भी इसी तरह काम करते हैं
    संबंधित दस्तावेज़: Anthropic API Key Best Practices, GitHub Secret Scanning Patterns

    • अगर GitHub की token scanning service down हो जाए तो यह जोखिमभरा है, इसलिए इसकी सिफारिश नहीं की जानी चाहिए
      आदर्श रूप से GitHub को एक universal token revocation API देनी चाहिए
      या private repository में revoke feature को सीधे enable करना बेहतर होगा
    • यह कुछ hacker के साथ chess खेलने जैसा लगता है
    • सीधे Anthropic console में key revoke की जा सकती है, फिर इसे इतना जटिल क्यों बनाया जाए, यह समझ नहीं आता
    • मुझे यह काफ़ी चतुर समाधान लगता है, मैंने ऐसा तरीका पहली बार सुना है
    • लेकिन अगर attacker फ़ाइलें चुराकर उन्हें अपने Anthropic account में ले जाए, तो नतीजतन दुनिया भर के लोग उस account तक पहुँच सकते हैं, इसलिए यह खतरनाक है

  • डेमो में छोटे फ़ॉन्ट में छिपी .docx फ़ाइल से prompt injection दिखाया गया, लेकिन वास्तव में एक साधारण Markdown फ़ाइल भी काफ़ी है
    उदाहरण के लिए, अगर बस यह लिख दिया जाए कि “Claude loan negotiation skills सीखता है”, तो बहुत से लोग उसे खोले बिना ही इस्तेमाल कर लेंगे
    बल्कि .md फ़ाइल, .docx की तुलना में कम संदिग्ध लगने की वजह से ज़्यादा असरदार हो सकती है

    • यह कुछ “चालाक भालू बनाम न खुलने वाला कूड़ेदान” जैसी स्थिति लगती है
    • लेकिन सभी users ऐसा नहीं सोचते
      उदाहरण के लिए, कुछ industries में आज भी PDF से ज़्यादा DOCX को सामान्य माना जाता है
      ऐसे माहौल में .md फ़ाइल उल्टा hacker के tool जैसी लग सकती है

  • ऐसी समस्या शुरू से ही अनुमानित थी
    जब तक prompt injection हल नहीं होती, यह बार-बार होती रहेगी
    अगर 1999 के HN की कल्पना करें, तो माहौल कुछ वैसा ही है जैसा SQL injection के शुरुआती दिनों में “Bobby Tables ने DB उड़ा दिया” जैसे रिएक्शन होते थे

    • तुलना दिलचस्प है, लेकिन पूरी तरह सटीक नहीं
      2000 के शुरुआती दशक में भी हम string interpolation की जगह parameterized SQL इस्तेमाल करने की बात करते थे
      आज भी ज़रूरी tools सब मौजूद हैं, समस्या बस यह है कि लोग security से ज़्यादा speed को प्राथमिकता देते हैं
      विडंबना यह है कि यह प्रतिस्पर्धा शुरू करने वाला OpenAI था, जो security और alignment पर ज़ोर देता था
    • मुझे लगता है कि क्या इसे SQL injection की तरह input sanitization से हल किया जा सकता है
      जैसे user input को किसी खास token (@##)(JF) में लपेट दिया जाए, और उसके भीतर के commands execute न होने दिए जाएँ
      यह एक साधारण find/replace से भी संभव लगता है, तो क्या मैं कुछ मिस कर रहा हूँ?
    • ज़्यादा बुनियादी समस्या यह है कि बुद्धिमत्ता बढ़ने पर भी यह शायद हल न हो
      बल्कि AI जितना ज़्यादा स्मार्ट होगा, जोखिम उतना बढ़ भी सकता है
    • मैं agents के लिए Prepared Statement pattern के साथ प्रयोग कर रहा हूँ
      हर tool call से पहले एक signed ‘warrant’ पेश करना पड़ता है, ताकि सिर्फ़ अनुमति-प्राप्त commands ही चलें
      यह ऐसा तरीका है जिसमें prompt injection होने पर भी उसे मशीन की तरह ब्लॉक किया जा सके

  • ऐसा लगता है जैसे फिर से autorun bug आ गया हो, जहाँ “अगर फ़ाइल संदिग्ध हो, तो उसे program की तरह चला दो”
    Windows XP के दौर में भी हम ऐसे मसलों से जूझ चुके हैं, और अंत में Microsoft ने autorun बंद कर दिया था
    prompt-आधारित systems को भी क्या भरोसेमंद है, इसे साफ़-साफ़ अलग करना होगा

  • मुझे लगता है कि AI कंपनियों का जोखिम को “सिर्फ़ मान लेना” और users से अव्यावहारिक सावधानियाँ माँगना समस्या है

    • ज़्यादातर व्याख्याएँ “SQL injection” की उपमा देती हैं, लेकिन असल में यह phishing attack के ज़्यादा क़रीब है
      जैसे अगर आप एक “दादी bot” बनाकर उससे email organize करवाएँ, तो वह Nigerian prince scam mail के झाँसे में आ सकती है
    • आखिरकार इसका मतलब लगभग यह है कि “अगर इस product को सुरक्षित तरीके से इस्तेमाल करना है, तो इसे इस्तेमाल ही मत करो”

  • यह शायद Claude के ‘skill’ system के implicit होने से पैदा हुई समस्या है
    /slash command की तरह explicit नहीं है, बस “फ़ाइल extract करने का तरीका” जैसी instructions होती हैं
    इसलिए सिर्फ़ “decompress” या “extract” जैसे शब्द लिखने से भी यह अपने-आप चल सकता है
    ऐसी संरचना prompt injection के लिए नई capabilities को चुपके से जोड़ना आसान बना देती है
    इसलिए इसे explicit और statically registered tool system में बदलना ज़रूरी है
    उदाहरण के लिए Extract(path) जैसा tool बनाया जा सकता है, और सिर्फ़ Read या Bash("tar *") को whitelist किया जा सकता है
    इससे human approval process भी जोड़ी जा सकती है, और session के दौरान कोई नया tool register नहीं होगा

  • संबंधित पुरानी घटनाएँ और Anthropic का आधिकारिक जवाब इस ब्लॉग पोस्ट में संक्षेपित हैं

  • थोड़ा अलग विषय है, लेकिन मैं जानना चाहता हूँ कि क्या data exfiltration PoC को service के रूप में देने वाली कोई जगह है
    खासकर जब Claude किसी बाहरी CI environment में चल रहा हो, तब CLAUDE.md के toxic payload के साथ प्रयोग करना चाहता हूँ

  • promptarmor की हाल की गतिविधि प्रभावशाली है
    यह product teams की quality accountability तय करने में बड़ी भूमिका निभा रही है

    • लेकिन उनका भी fear marketing के ज़रिए product बेचने का स्वार्थ है
      असली attack के लिए victim को Claude को sensitive folders का access देना होगा, और attacker को अदृश्य prompt injection छिपी हुई DOCX upload करवाने के लिए उसे फुसलाना होगा
      ऊपर से injection की सामग्री Markdown output में user को दिख जाती है
      attacker को अपनी API key इस्तेमाल करनी पड़ती है, इसलिए trace करना संभव है
      यह attack सिर्फ़ पुराने Haiku version पर काम करता है
      आख़िरकार लगता है कि promptarmor बेचने के लिए बढ़ा-चढ़ाकर पेश कर रहा है

  • हमारी team agent VM को pip, npm, apt तक ही communicate करने देती है
    और output request size को monitor करती है ताकि असामान्य data exfiltration रोका जा सके

    • लेकिन यह मूलभूत समाधान नहीं है
      AI का misuse, leakage, और autonomy — यह तीनहरी समस्या सिर्फ़ एक पक्ष को रोकने से हल नहीं होती
      छोटे requests के भीतर भी secrets encode किए जा सकते हैं, और unaligned AI ऐसे leakage paths खुद ढूँढ़ सकती है
    • यह दिलचस्प approach है, लेकिन मैं जानना चाहता हूँ कि क्या attacker user के codebase को package बनाकर upload भी कर सकता है