एक MCP server AI मॉडल के लिए फ़ाइलें पढ़ सकता है, डेटाबेस से जानकारी निकाल सकता है और कमांड चला सकता है, इसलिए एक कमज़ोर कड़ी बहुत कुछ खोल देती है। देखें कि असली घटनाओं में खुले पोर्ट, prompt injection, tool poisoning, दुर्भावनापूर्ण पैकेज और लीक हुए सीक्रेट कैसे काम करते हैं, और वे उपाय जो सच में टिकते हैं।
MCP server एक छोटा प्रोग्राम है जिसका काम बड़ा है: यह AI मॉडल को फ़ाइलें पढ़ने, डेटाबेस क्वेरी करने, ईमेल भेजने और shell commands चलाने की शक्ति देता है। इसी वजह से MCP server vulnerabilities सुरक्षा एडवाइज़री में लगातार आती रहती हैं। प्रोटोकॉल के मुख्यधारा में आने के लगभग एक साल के भीतर, रिसर्चरों ने गंभीर remote code execution बग प्रकाशित किए, एक malicious पैकेज पकड़ा गया जो चुपचाप भेजा गया हर ईमेल कॉपी कर रहा था, और public internet पर 1,862 servers गिने गए, जिनमें से 119 के सैंपल में अजनबी बिना एक भी लॉगिन के उनके tools की सूची देख सकते थे।
यह लेख सबसे आम MCP security flaws की पड़ताल करता है, हर एक के पीछे के असली incidents दिखाता है, और एक checklist पर खत्म होता है जिसे आप आज ही लागू कर सकते हैं। हर सेक्शन एक flaw को उस fix के साथ जोड़ता है जो सच में काम करता है, ताकि आप सिर्फ़ चिंता करने के बजाय खामियाँ बंद कर सकें।
एक सामान्य वेब API सिर्फ़ एक सीमित काम करती है। MCP server उसके मुकाबले एक पावर स्ट्रिप से ज़्यादा मिलता-जुलता है: वह filesystem, git क्लाइंट, डेटाबेस, ब्राउज़र और मेल अकाउंट को एक ही कनेक्शन में जोड़ देता है, और मॉडल तय करता है कि किस सॉकेट का इस्तेमाल करना है। लोकल सर्वर आमतौर पर चाइल्ड प्रोसेस के रूप में चलते हैं और उनके पास आपके यूज़र अकाउंट जैसी ही अनुमतियाँ होती हैं। इसलिए कोई कंप्रोमाइज़ हुआ टूल मशीन पर SSH कॉन्फ़िग, ब्राउज़र प्रोफ़ाइल, क्लाउड क्रेडेंशियल और हर प्रोजेक्ट फ़ोल्डर पढ़ सकता है।
Remote servers भी ज़्यादा सुरक्षित नहीं हैं। उनके पास अक्सर एक साथ कई services के OAuth tokens होते हैं, जिससे एक breach कई systems तक पहुँच में बदल जाता है।
पारंपरिक software में एक ही trust boundary होती है: अविश्वसनीय input अंदर जाता है, और validate किया हुआ data बाहर आता है। MCP में ऐसी कम से कम चार boundaries हैं।
Claude Sonnet 5 और GPT 5.6 Sol जैसे मॉडल instructions को फ़ॉलो करने के लिए बने हैं, और वे भरोसेमंद तरीके से यह अलग नहीं कर पाते कि instruction यूज़र की है या उस document के अंदर छिपी है जिसका summary बनाने को कहा गया था। यही एक कमज़ोरी नीचे के ज़्यादातर attacks को ताकत देती है।
💡 नियम: मॉडल तक पहुँचने वाली हर string को untrusted code मानें, भले ही वह उस tool से आई हो जिसे आपने खुद इंस्टॉल किया है।
सुरक्षा की सबसे पुरानी गलती फिर से दिखती है: ऐसी services जो दस्तक देने वाले हर किसी को जवाब देती हैं।
कई local MCP servers 127.0.0.1 की बजाय 0.0.0.0 पर bind होते हैं, जिससे उसी Wi-Fi नेटवर्क पर मौजूद कोई भी उन तक पहुँच सकता है। रिसर्चरों ने इसके बाद होने वाले attack को NeighborJacking नाम दिया। आधिकारिक MCP Inspector, एक debugging tool, दिखाता है कि यह कितना गंभीर हो सकता है: 0.14.1 से पहले के versions में browser client और local proxy के बीच कोई authentication नहीं था। इससे CVE-2025-49596 बना, एक 9.4 severity remote code execution flaw, जिसमें Inspector दूसरे tab में चलते समय कोई malicious web page developer की मशीन पर commands भेज सकती थी।
Public internet की तस्वीर और बुरी है। Knostic के scan में 1,862 exposed MCP servers मिले। जिन 119 की जाँच हुई, उनमें से एक भी tools की सूची लौटाने से पहले authentication नहीं माँगता था। कोई भी browser या script वाला व्यक्ति देख सकता था कि हर server क्या कर सकता है, और कई मामलों में उसे call भी कर सकता था।
कई servers जो login के पीछे होते हैं, वे भी connection को authenticate करके किसी चीज़ को authorize नहीं करते। जो भी अंदर पहुँचता है, वह हर tool call कर सकता है, विनाशकारी tools सहित। MCP specification remote servers के लिए OAuth पर आधारित authorization flow परिभाषित करता है, लेकिन यह वैकल्पिक है, और कई builders इसे जल्दी के डेमो के लिए छोड़ देते हैं, जो बाद में production बन जाता है।
Fixes छोटे हैं:
127.0.0.1 पर bind करें और DNS rebinding रोकने के लिए HTTP transports पर Origin header validate करें।delete_record call न कर सके।
MCP की सबसे खतरनाक flaw coding bug नहीं है। वह text है। सुरक्षा रिसर्चर Simon Willison इस जोखिम भरे setup को lethal trifecta कहते हैं: ऐसा agent जो निजी डेटा पढ़ सकता है, untrusted content ग्रहण कर सकता है और जानकारी बाहर भेज सकता है। किसी एक agent को ये तीनों दे दें, तो हमलावर को बस कुछ वाक्य लगाने होते हैं।
दो असली मामले यह पैटर्न दिखाते हैं:
दोनों servers में कोई classic vulnerability नहीं थी। दोनों ने वही किया जो उन्हें कहा गया था, बस गलत पक्ष के कहने पर।
Tool poisoning हमले को tool के अपने metadata में ले जाता है। Invariant Labs ने यह तरीका अप्रैल 2025 में प्रकाशित किया: एक tool जो add function जैसा हानिरहित दिखता है, अपने description में छिपे instructions रखता है, जो model को निजी SSH files पढ़ने और उन्हें एक parameter के ज़रिए बाहर भेजने के लिए कहते हैं। Approval dialog में यूज़र को "add two numbers" दिखता है। Model पूरा description देखता है और उसका पालन करता है।
कुछ variants payload को zero-width Unicode characters या Base64 blocks में छिपाते हैं, इसलिए तेज़ visual review में कुछ गलत नहीं दिखता।
Rug pull धैर्य वाला रूप है। एक server पहले दिन ठीक व्यवहार करता है, approvals जमा करता है, फिर tools/list_changed notification के ज़रिए नई tool definitions प्रकाशित करता है। ज़्यादातर clients दूसरी approval नहीं माँगते, version pin नहीं करते, या hash की तुलना नहीं करते। एक संबंधित तरकीब, tool shadowing, एक malicious server को भरोसेमंद server के tools के इस्तेमाल का तरीका फिर से लिखने देती है, क्योंकि हर description एक ही context window में पहुँचता है।
इस तरह के हमलों के खिलाफ़ जो काम करता है:
MCP servers आम तौर पर एक कमांड से इंस्टॉल होते हैं, आमतौर पर npx या uvx, जो public registry से code डाउनलोड करके चलाता है। सितंबर 2025 में Koi Security ने उसकी रिपोर्ट दी जिसे असली दुनिया में मिला पहला malicious MCP server बताया गया: postmark-mcp नाम का एक npm पैकेज, जिसने एक असली email library की नकल की थी। Version 1.0.16 में एक ही पंक्ति जोड़ी गई थी जो हर outgoing email को हमलावर के नियंत्रण वाले पते पर blind-copy करती थी। पैकेज हटाए जाने से पहले उसे 1,643 बार डाउनलोड किया गया था।
एक ही पंक्ति काफ़ी थी, क्योंकि पाँच मिनट बचाने के लिए इंस्टॉल किए गए server का source लगभग कोई नहीं पढ़ता।
दूसरा परिवार साधारण command injection का है। एक tool फ़ाइल नाम, URL या branch name लेता है और उसे shell string में डाल देता है। mcp-remote proxy में यही पैटर्न CVE-2025-6514 के रूप में आया, जिसका स्कोर 9.6 था: किसी untrusted MCP server से connect करने पर proxy चलाने वाली मशीन पर मनमाने operating system commands चल सकते थे।
इसके रिश्तेदार हर जगह हैं:
| बग का प्रकार | आम ट्रिगर | सुरक्षित पैटर्न |
|---|---|---|
| Shell injection | कमांड स्ट्रिंग में चिपकाया गया फ़ाइल नाम या URL | आर्गुमेंट्स को array में पास करें, कभी shell से नहीं |
| Path traversal | फ़ाइल पाथ में ../ sequences या symlinks | असली path resolve करें, फिर उसे allowed root से मिलाएँ |
| SSRF | internal addresses की ओर इशारा करता fetch tool | Private IP ranges और cloud metadata endpoints block करें |
| SQL injection | मॉडल की लिखी क्वेरी पूरे अधिकारों के साथ चलती हैं | Parameterized queries और read-only database role |
एक सामान्य MCP setup access token सीधे JSON config में चिपका देता है। वह फ़ाइल repository में commit हो जाती है, cloud drive पर sync हो जाती है, या कोई poisoned tool उसे पढ़ लेता है जिसे उसे ढूँढने को कहा गया था। Logging इसे और बिगाड़ती है: जो servers पूरा request payload प्रिंट करते हैं, वे tokens ऐसी log files में लिख देते हैं जिन्हें कोई rotate नहीं करता।
यह सफ़ाई का काम नियमित है, पर शायद ही कभी किया जाता है। secrets को environment variables या secrets manager से लोड करें, कम अवधि वाले (short-lived) tokens जारी करें, CI में secret scanning चलाएँ, और हर log line से authorization headers छिपा दें।
एक server जिसे सिर्फ़ एक table पढ़नी है, उसे पूरे database के लिए service role token मिल जाता है। हर repository तक पहुँचने वाला GitHub token एक injected issue को पूरे leak में बदल देता है। Supabase का अपना documentation डिफ़ॉल्ट रूप से read-only, project-scoped mode की सलाह देता है, जो हर server के लिए सही प्रवृत्ति है।
दो protocol level गलतियाँ नाम की हक़दार हैं:
💡 तेज़ परीक्षण: अगर किसी server का token आज किसी public chat में चिपका दिया जाए, तो कितना नुकसान हो सकता है? जवाब को तब तक छोटा करें जब तक वह कम चुभने न लगे।
यह पूरा लेख एक table में संक्षेप में दिया गया है, जिसे आप किसी pull request template में चिपका सकते हैं।
| खामी | यह कैसी दिखती है | Fix |
|---|---|---|
| Open ports | 0.0.0.0 पर bind किया गया server, कोई login नहीं | Localhost पर bind करें, tokens माँगें |
| Prompt injection | Agent ticket या issue के text का पालन करता है | पढ़ने और भेजने की शक्तियाँ अलग करें, outbound actions को approve करवाएँ |
| Tool poisoning | लंबे या अजीब tool descriptions | पूरा text दिखाएँ, अदृश्य characters हटाएँ |
| Rug pull | Approval के बाद tools बदलते हैं | Versions pin करें, definitions का hash बनाएँ |
| Malicious package | npm पर मिलते-जुलते नाम | Publisher verify करें, pin करें, diffs review करें |
| Command injection | Shell strings के अंदर user input | Argument arrays और allowlists |
| Secret leakage | JSON configs और logs में tokens | Secrets manager, short lifetimes |
| Overbroad scopes | पढ़ने के काम के लिए admin token | हर server के लिए least privilege |
हर tool call को उसके arguments और उसके पीछे की identity के साथ log करें। नया tool दिखने या definition बदलने पर alert करें। महँगे tools की rate limit तय करें, tokens को शेड्यूल पर rotate करें, और एक kill switch रखें जो एक ही बार में हर server disconnect कर दे। पहले हफ़्ते के बाद logs की समीक्षा करें, क्योंकि अजीब व्यवहार आम तौर पर तभी दिखता है।
Llama Guard 4 12B एक safety classifier है जिसे आप PicassoIA पर चला सकते हैं। यह safe या unsafe verdict देता है, साथ में वह harm category भी जो मेल खाई। यह कोई समर्पित prompt injection detector नहीं है, इसलिए इसे tool descriptions और tool output के लिए एक अतिरिक्त सुरक्षा जाँच मानें, अकेले भरोसे वाला gate नहीं।
यह एक workflow है जो कुछ मिनट लेता है:
| सेटिंग | सुझाया गया मान | यह क्यों मदद करता है |
|---|---|---|
| Temperature | 0 to 0.2 | एक ही text के लिए एक जैसे verdicts |
| Max Completion Tokens | 512 या कम | Verdict छोटा होता है, इसलिए ज़्यादा लंबाई कुछ नहीं जोड़ती |
| System Prompt | छोटे, साफ़ नियम | संक्षिप्त, साफ़ नियम कम अस्पष्ट जवाब देते हैं |
| Image Input | वैकल्पिक | जब किसी tool dialog का screenshot जाँचना हो तब उपयोगी |
💡 दूसरी राय के साथ जाँचें: वही text Gemini 3.5 Flash में चिपकाएँ और उससे कहें कि हर वह वाक्य सूचीबद्ध करे जो किसी AI assistant को निर्देश देता है। दो अलग मॉडल का असहमत होना एक उपयोगी संकेत है।
Security write-ups, runbooks और internal training decks को ऐसी तस्वीरें चाहिए जो असली ज़िंदगी जैसी लगें, स्टॉक फ़ोटो के घिसे-पिटे क्लिशे जैसी नहीं। Picasso IA टेक्स्ट विवरण को सेकंडों में फ़ोटोरियलिस्टिक इमेज में बदल देता है, इसलिए आप इस लेख की हर flaw के लिए बिना फ़ोटो शूट के एक विज़ुअल बना सकते हैं।
p-image तेज़ और साफ़ दृश्यों के लिए, Seedream 4.5 समृद्ध डिटेल के लिए, या Flux 2 Pro जब कंपोज़िशन पर सख़्त नियंत्रण चाहिए तब आज़माएँ। सब्जेक्ट, रोशनी और लेंस का वर्णन करें, फिर चलाएँ और एक-एक डिटेल बदलकर सुधारें। picassoia.com/en/all-models पर हर विकल्प देखें, कोई मॉडल चुनें, और आज ही अपनी पहली इमेज बनाएँ।
अपनी भाषा चुनें
