۹۱.۸٪ از سرورهای عمومی MCP فاقد احراز هویت هستند

اگر امروز از عامل‌های هوش مصنوعی برای مدیریت ابزارهای سازمانی استفاده می‌کنید، احتمالاً کلید دسترسی به داده‌های حساس خود را در اختیار یک درِ باز گذاشته‌اید. طبق یک مطالعه در ژوئیه ۲۰۲۶ توسط پادیا (Padilla)، ۹۱.۸٪ از ۴۱۴ سرور MCP متصل به اینترنت — از میان ۶۴۰ نمونه تأییدشده در محیط عملیاتی — فاقد احراز هویت OAuth هستند و کاملاً در معرض بهره‌برداری قرار دارند.

این آسیب‌پذیری باعث شده است پروتکل زمینه مدل (Model Context Protocol یا MCP)، که استاندارد صنعت برای اتصال عامل‌ها به ابزارها و APIهاست، به هدفمندترین زیرساخت هوش مصنوعی تبدیل شود که در حال حاضر وجود دارد. این پروتکل در حالی به استاندارد تبدیل شد که هم‌زمان دسترسی عامل‌ها به داده‌های حساس را به شکلی خطرناک تسهیل کرد. اسکن‌های انجام‌شده ۶۸۷ مورد از ابزارهایی را شناسایی کردند که اجرای دستورات شل (Shell Execution) را بدون هیچ‌گونه کنترل دسترسی باز گذاشته‌اند. همچنین ۶۸ آسیب‌پذیری گزارش‌شده شامل تزریق SQL (SQL Injection)، پیمایش مسیر (Path Traversal) و حملات SSRF علیه نقاط انتهایی متادیتای ابری شناسایی شده است.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های عامل‌محور اشاره کردیم، مشکل اصلی در اینجا نبودِ باگ‌های «بومیِ هوش مصنوعی» است، بلکه بازگشت آسیب‌پذیری‌های کلاسیک اوایل دهه ۲۰۰۰ است. با متصل کردن مدل‌های زبانی بزرگ (LLM) — که ذاتاً نمی‌توانند تفاوت بین دستور و داده را تشخیص دهند — به اعتبارنامه‌های سطح بالا، MCP به کانالی گسترده برای اکسپلویت‌های قدیمی تبدیل شده است. به نقل از شرکت اکویکسلی (Equixly) در مارس ۲۰۲۵، این پروتکل «بیشتر برای کاربردی بودن طراحی شده بود تا امنیتی بودن».

ابعاد آسیب‌پذیری

بر اساس پژوهش اتحادیه امنیت ابری (CSA) در مه ۲۰۲۶، ریسک زنجیره تأمین بسیار گسترده است. CSA تخمین می‌زند حدود ۲۰۰ هزار نمونه آسیب‌پذیر MCP وجود دارد که با بیش از ۱۵۰ میلیون دانلود بسته در ارتباط هستند. تا مه ۲۰۲۶، دست‌کم هفت مورد CVE با درجه شدت «بالا» یا «بحرانی» برای این نمونه‌ها تأیید شده است.

اسکن‌های زودتر در ژوئیه ۲۰۲۵ پیش از این ۱۸۶۲ سرور با دسترسی عمومی و بدون احراز هویت را شناسایی کرده بودند. گزارش مارس ۲۰۲۵ توسط اکویکسلی روی سرورهای متن‌باز محبوب نشان داد که ۴۳٪ آن‌ها دچار تزریق دستور، ۳۰٪ دچار SSRF و ۲۲٪ دچار پیمایش مسیر هستند. این‌ها باگ‌های هوش مصنوعی نیستند؛ بلکه همان لیست OWASP پانزده سال پیش هستند که در سرورهایی که در یک آخر هفته برای بسته‌بندی APIها نوشته شده‌اند، دوباره ظاهر شده‌اند.

سازوکار عملکرد MCP

برای درک ریسک، باید مکانیزم آن را شناخت. یک کلاینت MCP (مانند یک IDE، یک اپلیکیشن چت یا یک محیط اجرای عامل) به یک یا چند سرور MCP متصل می‌شود. در هنگام اتصال، کلاینت از هر سرور لیست ابزارهای موجود را از طریق tools/list درخواست می‌کند. سرور نام‌ها، توضیحات و طرح‌های ورودی (Input Schemas) را ارسال می‌کند. سپس کلاینت این توضیحات را در پنجره زمینه (Context Window) مدل قرار می‌دهد تا مدل تصمیم بگیرد کدام ابزار را فراخوانی کند.

سرورها می‌توانند به‌صورت محلی به عنوان پردازش‌های فرزند (Child Processes) یا از راه دور روی HTTP اجرا شوند، جایی که قرار است OAuth مدیریت هویت را بر عهده بگیرد. این معماری دو پیامد امنیتی بحرانی دارد:

۱. هر آنچه سرور ارسال می‌کند — از جمله توضیحات ابزار — به ورودی مدل تبدیل می‌شود.
۲. هر اعتبارنامه‌ای که سرور در اختیار دارد، به نفع هر کسی یا هر چیزی که بتواند مدل را هدایت کند، اجرا می‌شود.

مکانیزم «نماینده گیج‌شده»

در قلب این شکست‌ها، مفهومی از سال ۱۹۸۸ به نام «نماینده گیج‌شده» (Confused Deputy) قرار دارد که توسط نرم هاردی (Norm Hardy) توصیف شد. هاردی سرویس کامپایلی را توصیف کرد که اجازه داشت در فایل صورت‌حساب بنویسد، زیرا برای کامپایل‌ها هزینه دریافت می‌کرد، اما به کاربران اجازه می‌داد نام فایل خروجی برای لاگ‌های دیباگ را تعیین کنند. وقتی کاربر نام فایل خروجی را همان نام فایل صورت‌حساب می‌گذاشت، کامپایلر از اعتبار خود برای بازنویسی داده‌های صورت‌حساب استفاده می‌کرد. کامپایلر اختیار داشت، اما کاربر نداشت؛ و کامپایلر نمی‌توانست تشخیص دهد که دستور از منبعی غیرمجاز آمده است.

در اکوسیستم MCP، عامل (Agent) نقش این نماینده را ایفا می‌کند. عامل اعتبارنامه‌ها را دارد، اما دستوراتی را دنبال می‌کند که در داده‌های پردازش‌شده جاسازی شده‌اند. اگر مدل یک پرامپت مخرب را در توضیحات ابزار یا یک تیکت پشتیبانی بخواند، ممکن است از توکن‌های سطح سیستم خود برای نشت داده‌های خصوصی یا اجرای کد استفاده کند. نماینده اعتبارنامه را دارد، اما درخواست‌کننده ندارد و نماینده نمی‌تواند دستور را به منبع اصلی نسبت دهد.

گاه‌شمار حوادث اصلی

• آوریل ۲۰۲۵: شرکت تریل آف بیتس (Trail of Bits) تکنیک «پرش خط» (Line Jumping) یا مسموم‌سازی ابزار را نمایش داد. آن‌ها نشان دادند سرور مخرب می‌تواند یک محموله تزریق پرامپت (Prompt Injection) را در توضیحات ابزار یا دستورالعمل‌های سرور قرار دهد. برای مقابله با این نوع حملات، استفاده از پراکسی‌های قطعی به عنوان تنها راهکار عملی در محیط‌های عملیاتی پیشنهاد شده است. چون این موارد در زمان اتصال وارد زمینه می‌شوند، رفتار مدل پیش از فراخوانی هر ابزاری دستکاری می‌شود و تایید انسانی (Human-in-the-loop) که کلاینت‌ها معمولاً برای فراخوانی ابزارها قرار می‌دهند، دور زده می‌شود.
• مه ۲۰۲۵: آزمایشگاه این‌ورینت (Invariant Labs) یک «جریان عامل سمی» را در سرور رسمی MCP شرکت گیت‌هاب (GitHub) افشا کرد. یک توسعه‌دهنده از عامل خواست تا Issueهای باز در یک مخزن عمومی را بررسی کند. یکی از این Issueها که توسط یک غریبه نوشته شده بود، به عامل دستور داد تا مخازن خصوصی توسعه‌دهنده را بخواند و یافته‌ها را در یک Pull Request عمومی منتشر کند. عامل این کار را انجام داد زیرا توکنی با دسترسی به مخازن خصوصی داشت و متنی را دنبال کرد که متعلق به شخصی بدون دسترسی بود.
• مه تا ژوئن ۲۰۲۵: شرکت آسانا (Asana) سرور MCP خود را در ۱ مه راه‌اندازی کرد. یک باگ منطقی باعث شد داده‌های یک سازمان برای کاربران MCP در سازمان‌های دیگر در محدوده دسترسی خودشان نمایش داده شود. حدود ۱۰۰۰ مشتری تحت تأثیر قرار گرفتند. سرور در ۴ ژوئن آفلاین شد و در ۱۷ ژوئن بازگردانده شد. این یک شکست در جداسازی معمولی چندمستاجری (Multi-tenant Isolation) در یک مسیر کد جدید بود.
• ژوئیه ۲۰۲۵: تحلیل‌های عمومی الگویی را نشان داد که در آن مهاجم تیکتی حاوی دستورات برای دستیار ارسال می‌کرد. توسعه‌دهنده‌ای که از کِرسور (Cursor) و سرور MCP شرکت سوپابیس (Supabase) استفاده می‌کرد (که با کلید service_role و با دور زدن امنیت سطح ردیف یا RLS اجرا می‌شد)، باعث شد دستیار متن تیکت را به عنوان یک وظیفه تلقی کند، جدول integration_tokens را کوئری کند و اسرار OAuth را به تیکت مهاجم بازگرداند. سایمون ویلیسون (Simon Willison) این را «سه‌گانه مرگبار» نامید: داده‌های خصوصی، محتوای غیرقابل‌اعتماد و یک کانال خروجی در یک عامل.
• ژوئیه ۲۰۲۵: شرکت جی‌فراگ (JFrog) آسیب‌پذیری CVE-2025-6514 (با امتیاز CVSS 9.6) را در mcp-remote افشا کرد که یک پل npm برای سرورهای راه دور است. در طول اکتشاف OAuth، یک سرور مخرب می‌توانست یک authorization_endpoint دستکاری‌شده برگرداند. در ویندوز، زیر-عبارت $() در پاورشل این رشته را به اجرای دستورات دلخواه تبدیل می‌کرد. نسخه‌های 0.0.5 تا 0.1.15 تحت تأثیر بودند که بیش از ۴۳۷ هزار دانلود را شامل می‌شد.

رسمی‌سازی ریسک‌ها

صنعت با تدوین استانداردهایی به این شکست‌ها پاسخ داده است. لیست ۱۰ ریسک برتر MCP در OWASP (نسخه بتا، به رهبری واندانا ورما سهگال) ریسک‌های بحرانی را فهرست کرده است، از جمله:

• MCP01: مدیریت نادرست توکن‌ها و افشای اسرار
• MCP03: مسموم‌سازی ابزار
• MCP05: تزریق و اجرای دستورات
• MCP07: احراز هویت و مجوزدهی ناکافی
• MCP09: سرورهای MCP سایه (Shadow MCP)
• MCP10: تزریق زمینه و اشتراک‌گذاری بیش از حد

علاوه بر این، در ۹ دسامبر ۲۰۲۵، لیست «۱۰ ریسک برتر OWASP برای برنامه‌های عامل‌محور ۲۰۲۶» با مشارکت بیش از صد نفر منتشر شد. این لیست دیدگاه سطح عامل را اضافه می‌کند و مواردی چون ربودن هدف (Goal Hijack)، سوءاستفاده از ابزار، سوءاستفاده از هویت و امتیازات، مسموم‌سازی حافظه و عامل‌های سرکش (Rogue Agents) را به عنوان بردارهای اصلی معرفی کرد. اکثر این موارد مستقیماً به شماره‌های CWE دهه ۲۰۰۰ متصل می‌شوند.

مهندسی راهکارها

کارشناسان امنیتی معتقدند راهکارها پیچیده نیستند اما باید دقیق باشند. دفاع اصلی، مجوزدهی (Authorization) در مرز ابزار است که به یک هویت تأییدشده متصل باشد. بررسی باید بر این اساس باشد که «آیا این کاربر خاص اجازه انجام این عمل روی این شیء را دارد؟» و این کاربر باید از توکن تأییدشده استخراج شود، نه از آرگومانی که مدل پر کرده است. این راهکار دقیق برای باگ بین-سازمانی آسانا و ربودن هندل‌های وضعیت (State-handle Hijacking) است.

سایر اقدامات حیاتی عبارتند از:

• شکستن سه‌گانه: اطمینان از اینکه یک نشست به‌طور هم‌زمان به محتوای غیرقابل‌اعتماد، داده‌های خصوصی گسترده و کانال خروجی دسترسی ندارد. راهکار این‌ورینت برای گیت‌هاب، محدود کردن هر نشست به یک مخزن بود؛ راهکار سوپابیس، تنظیم read_only=true و محدود کردن دامنه پروژه بود.
• حفاظت از زمینه: استفاده از پوشش‌هایی مانند mcp-context-protector شرکت تریل آف بیتس برای تثبیت توضیحات ابزار و علامت‌گذاری تغییرات. هر متنی که سرور می‌فرستد باید به عنوان «شاهد» برای مدل باشد، نه «سیاست» حاکم بر آن.
• پایبندی سخت‌گیرانه به OAuth: پیروی از سند «بهترین شیوه‌های امنیتی MCP». این شامل پیاده‌سازی رضایت به ازای هر کلاینت (برای جلوگیری از سرورهای پروکسی با IDهای استاتیک که صفحات رضایت را دور می‌زنند)، اعتبارسنجی Audience و ممنوعیت پاس‌دهی توکن‌ها (Token Passthrough) است. سرورها نباید توکن‌هایی را بپذیرند که صراحتاً برای آن‌ها صادر نشده‌اند.
• امنیت اکتشاف: مسدود کردن URLهای اکتشاف در محدوده خصوصی (مانند 169.254.169.254) و اجبار به استفاده از HTTPS. آسیب‌پذیری mcp-remote کاملاً در مرحله اکتشاف رخ داد.
• تأیید انسانی: الزام به تأیید دستی برای هرگونه اثر جانبی (Side Effect). دستیاری که می‌تواند پیش‌نویس یک پیام را بنویسد، نباید همان مؤلفه‌ای باشد که تصمیم به ارسال آن می‌گیرد.
• اعتبارسنجی هندل وضعیت: پیروی از این قانون که سرورها نباید داشتن یک هندل وضعیت (State Handle) را به عنوان احراز هویت تلقی کنند، که این امر از ارجاعات مستقیم ناامن به اشیاء (IDOR) جلوگیری می‌کند.

مسیر پیش‌رو

اکثر سازمان‌ها در حال حاضر از «MCP سایه» رنج می‌برند، جایی که توسعه‌دهندگان بدون نظارت مرکزی به سرورها متصل می‌شوند. CSA توصیه می‌کند اولین قدم برای هر سازمان، نه وصله کردن (Patching)، بلکه ایجاد یک فهرست جامع از تمام سرورهای MCP متصل است (برای رفع MCP09).

در نهایت، MCP آسیب‌پذیری‌های جدیدی را اختراع نکرد؛ بلکه صرفاً به باگ‌های ۳۰ ساله راهی جدید داد تا به قلب سازمان‌ها برسند. راه حل، به کارگیری درس‌های وب دهه ۲۰۰۰ — یعنی کمترین امتیاز (Least Privilege) و اعتبارسنجی سخت‌گیرانه ورودی‌ها — در مرز ابزار است. همان‌طور که مقاله چهار صفحه‌ای نرم هاردی پیشنهاد می‌کند، هدف این است که اطمینان حاصل شود عامل نمی‌تواند در «فایل صورت‌حساب» بنویسد.

برای مشاهده این الگوها در عمل، توسعه‌دهندگان می‌توانند تمرینات مرورگر Breachloom را بررسی کنند که این زنجیره‌ها را روی اپلیکیشن‌های فرضی شبیه‌سازی می‌کند:

• مسموم‌سازی ابزار: https://breachloom.com/ctf/mcp-poison/
• تزریق پرامپت غیرمستقیم: https://breachloom.com/ctf/llm-pi-indirect/
• نمایندگی و مجوزها: https://breachloom.com/ctf/llm-agency-email/
• زنجیره کامل تصاحب حساب: https://breachloom.com/chains/ai-agent-pwn/

گام بعدی شما

• اگر از سرورهای MCP استفاده می‌کنید، فوراً لیست تمام سرورهای متصل را استخراج و دسترسی‌های آن‌ها را به حالت «فقط خواندنی» (Read-only) تغییر دهید.
• برای هر ابزار حساس، لایه‌ای از تأیید انسانی (Human-in-the-loop) را قبل از اجرای دستورات سیستمی پیاده‌سازی کنید.
• مستندات امنیتی MCP را برای پیاده‌سازی صحیح OAuth و اعتبارسنجی Audience بررسی کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.