GitHub MCP का दुरुपयोग: MCP के जरिए निजी repositories तक पहुंच

• GitHub account से जुड़ा MCP agent सिर्फ public Issue पढ़कर भी private repository data leak करने का रास्ता खोल सकता है
• हमला public repository Issue में लगाए गए indirect prompt injection से शुरू होता है, जो agent के tool-use flow को बदल देता है
• demo में ukend0464/pacman के malicious Issue ने Claude 4 Opus और GitHub MCP integration के जरिए private repository जानकारी को public PR में बाहर भेज दिया
• समस्या की जड़ GitHub MCP server code की कमी से ज्यादा, trusted tools को untrusted external content के साथ इस्तेमाल करने की संरचना में है
• agent systems में per-repository least privilege, session-level access restrictions, और MCP-scan जैसी runtime security monitoring की जरूरत है

---

malicious Issue से शुरू होने वाला GitHub MCP हमला

• Invariant ने व्यापक रूप से इस्तेमाल होने वाले GitHub MCP integration में एक vulnerability खोजी, जिसमें attacker user के agent को hijack करके private repository data leak कर सकता है
  • यह GitHub MCP server GitHub पर 14k stars वाला project है
  • यह vulnerability Invariant के security analyzer द्वारा detect किए गए शुरुआती Toxic Agent Flows मामलों में से एक है
• Toxic Agent Flow ऐसा flow है जिसमें indirect prompt injection के कारण agent अनचाहे tool-use sequence को execute करता है
  • यह data leak या malicious code execution जैसी गतिविधियों तक ले जा सकता है
• coding agents और IDEs के तेजी से deploy होने की स्थिति में, इसी तरह के हमले core software development tools के users को expose कर सकते हैं

attack setup

• user Claude Desktop जैसे MCP client का इस्तेमाल करता है, और GitHub MCP server को अपने GitHub account से जोड़ चुका होता है
• attack scenario दो तरह की repositories मानकर चलता है
  • <user>/public-repo: public repository जहां कोई भी Issue और bug report बना सकता है
  • <user>/private-repo: private repository जिसमें proprietary code या company internal data होता है
• attacker GitHub के सामान्य permission rules के तहत public repository में malicious Issue बना सकता है
• जब user agent को Have a look at the open issues in <user>/public-repo जैसा legitimate request भेजता है, तो agent public repository Issues fetch करते हुए prompt injection के संपर्क में आ जाता है
• इसके बाद agent private repository data को context में लाता है और public repository में automatically generated PR के जरिए data leak कर सकता है

demo में देखी गई leak flow

• demo में public repository ukend0464/pacman और कई private repositories इस्तेमाल की गईं
  • ukend0464/pacman: एक public repository जिसमें सरल Pacman game implementation है और GitHub पर देखी जा सकती है
  • private repositories में user के personal projects और sensitive information शामिल हैं
• attacker public repository में malicious Issue रखता है
  • यह Issue ऐसा payload शामिल करता है जो agent के public repository Issue list query करते ही execute होगा
• user Claude 4 Opus को request भेजकर attack trigger करता है
  • Claude Desktop default रूप से हर individual tool call के लिए user confirmation मांगता है
  • कई users agent इस्तेमाल करते समय “Always Allow” confirmation policy चुनते हैं और individual actions की monitoring बंद कर देते हैं
• agent Issue list में चलता है, attack payload पाता है, private repository data को context में लाता है, और फिर उसे pacman repository के pull request में leak कर देता है
• public PR में user ukend0464 की private information शामिल होती है
  • Jupiter Star जैसी private repository information
  • South America में relocate करने की योजना
  • salary information
• पूरा agent reasoning और tool-use sequence Invariant Explorer के full trace में देखा जा सकता है

trusted tools में भी होने वाला Toxic Agent Flow

• यह vulnerability उन पुराने tool-poisoning attacks से अलग है जिनमें MCP tool खुद compromised होना जरूरी होता है
• जब GitHub जैसे external platform से जुड़ा agent untrusted information के संपर्क में आता है, तो tool पूरी तरह trusted होने पर भी समस्या हो सकती है
• agent systems में ऐसे flows को समझना, analyze करना और mitigate करना बड़े scale पर manually करना मुश्किल है
• Invariant ने Toxic Agent Flow detection को automate करने का तरीका विकसित किया है ताकि organizations malicious actors द्वारा abuse होने से पहले potential threats की पहचान और modeling कर सकें

scope और mitigations

• experiment Claude Desktop पर focused था, लेकिन vulnerability किसी खास agent या MCP client तक सीमित नहीं है
• GitHub MCP server का इस्तेमाल करने वाला कोई भी agent, underlying model या implementation से स्वतंत्र रूप से, प्रभावित हो सकता है
• अहम बात यह है कि यह समस्या GitHub MCP server code की अपनी bug नहीं है
  • सिर्फ server-side patch से GitHub अकेले इस vulnerability को solve नहीं कर सकता
  • यह एक structural issue है जिसे agent-system level पर address करना होगा

• granular permission control

  • GitHub जैसे MCP integrations का इस्तेमाल करते समय agent access को जरूरी repositories तक सीमित करना चाहिए
  • traditional token-based permissions कुछ protection देते हैं, लेकिन agent functionality को सीमित करने वाली कठोर constraints बना सकते हैं
  • Invariant agent systems के लिए tailored dynamic runtime security layer की सिफारिश करता है
  • Invariant Guardrails agent workflows के हिसाब से adapt होने वाला context-aware access control देता है
  • example policy एक session में केवल एक repository तक access सीमित करके cross-repository information leaks रोकती है
  • अलग-अलग repo या owner के लिए repository-related tool calls लगातार आएं तो इसे violation माना जाता है
  • पूरी policy github_policy.txt में देखी जा सकती है
  • apply करने का तरीका MCP-scan documentation में है
  • Guardrails Playground में deployment से पहले policy test की जा सकती है

• continuous security monitoring

  • preventive measures के साथ real-time threat detection और response के लिए monitoring जरूरी है
  • Invariant agent और MCP systems के बीच interactions को लगातार audit करने के लिए MCP-scan जैसे dedicated security scanners deploy करने की सिफारिश करता है
  • MCP-scan का proxy mode existing agent infrastructure बदले बिना MCP connections की real-time scanning सक्षम करता है
  • MCP traffic को proxy से route करने पर visibility और real-time security violation scanning मिलती है
  • comprehensive monitoring audit trail बनाती है, जिससे potential vulnerabilities, exploitation attempts, और नए attacks के खिलाफ protection status confirm करने में मदद मिलती है

model alignment भर काफी नहीं है

• experiment में latest alignment और security training वाले Claude 4 Opus का इस्तेमाल किया गया
• strong safety training के बावजूद, agent को अपेक्षाकृत simple prompt injection से manipulate किया जा सका
• कई off-the-shelf prompt injection detection defenses भी इस attack को पकड़ नहीं पाए
• agent system security context और environment पर निर्भर करती है
  • general model alignment training हर deployment scenario या organization-specific security requirement का अनुमान नहीं लगा सकती
  • system-level security measures को model-level safeguards की पूर्ति करनी चाहिए

agent security में बाकी चुनौतियां

• GitHub MCP server का इस्तेमाल करने वाले agents malicious GitHub Issue के जरिए manipulate होकर private repository data को public repository में leak कर सकते हैं
• यह vulnerability GitHub MCP के लिए specific है, लेकिन similar attacks दूसरे environments में भी लगातार सामने आ रहे हैं
  • Legit Security ने हाल ही में GitLab Duo की remote prompt injection vulnerability report की
• large-scale responsible deployment के लिए MCP integrations और agent systems में MCP-scan और Guardrails जैसे dedicated security scanners और policy controls की जरूरत है

[crawler]

बात बड़ी लगती है, लेकिन असल में यह सिर्फ prompt injection + MCP के इस्तेमाल कर सकने वाले अधिकार बहुत ज़्यादा होने से पैदा हुई समस्या है।
इसलिए यह ऐसा लगता है जैसे बाहरी रूप से MCP permissions को नियंत्रित कर सकने वाले टूल का प्रचार किया जा रहा हो।
अगर बाहर से आने वाले prompts और केवल अंदर से दिए जाने वाले prompts के लिए MCP जिन permissions का इस्तेमाल कर सकता है, उन्हें अलग रखा जाए तो अच्छा होगा।