۲۵٪ از استقرارهای پروتکل MCP دارای حفره‌های امنیتی شدید هستند

اگر امروز در حال توسعه عامل‌های هوش مصنوعی هستید که با داده‌های واقعی کار می‌کنند، احتمالاً در حال باز کردن یک درِ پشتی برای مهاجمان هستید. طبق گزارش امنیتی Correctover، یک چهارم (۲۵٪) از استقرارهای فعال پروتکل زمینه مدل (Model Context Protocol یا MCP) حداقل یک آسیب‌پذیری شدید در لایه‌ی ابزارها دارند. این یافته نشان می‌دهد که هرچه عامل‌های هوش مصنوعی agency یا عاملیت بیشتری پیدا می‌کنند، زیرساختی که آن‌ها را به داده‌های دنیای واقعی متصل می‌کند، به هدف اصلی برای بهره‌برداری تبدیل می‌شود. این وضعیت در ادامه روندی است که پیش‌تر در تحلیل تنظیمات پیکربندی عامل‌های هوش مصنوعی مشاهده شده بود و نشان می‌داد که بسیاری از استقرارها از ابتدا با ریسک‌های بحرانی آغاز می‌شوند. زمانی که یک عامل (Agent) — شبیه به کارمندی که اجازه دارد به جای شما از پرونده‌ها و نرم‌افزارهای شرکت استفاده کند — با یک پایگاه داده، یک API ابری، یک سیستم فایل یا یک خط لوله CI/CD تعامل می‌کند، این کار را از طریق یک سرور MCP انجام می‌دهد. اگر این سرور آسیب‌پذیر باشد، عامل دقیقاً به یک وسیله‌ی انتقال برای حملات سایبری تبدیل می‌شود.

ابزارهای امنیتی سنتی مانند WAFها، SAST (تست استاتیک) و DAST (تست دینامیک) برای ماهیت پویا و متغیر MCP ساخته نشده‌اند. برخلاف REST APIها که در آن‌ها نقاط انتهایی (Endpoints) مستند شده و دارای کنترل نسخه هستند، سرورهای MCP یک سطح ابزاری پویا را به نمایش می‌گذارند. ابزارها در زمان اجرا (Runtime) ثبت می‌شوند، توسط پرامپت‌های زبان طبیعی فراخوانی می‌گردند و اغلب نتایج را در چندین بک‌اند مختلف زنجیره‌سازی می‌کنند. با تکیه بر پوشش قبلی ما در مورد اینکه چگونه Halo از Gemma 4 برای خودکارسازی تست‌های نفوذ محلی استفاده می‌کند، صنعت اکنون شاهد تغییری به سمت حسابرسی‌های تخصصی برای زیرساخت‌های عامل‌محور است.

زمینه: دسته‌بندی جدیدی از ریسک‌ها

این سطح جدید از حمله، سه ریسک منحصر‌به‌فرد ایجاد می‌کند که با تست‌های متداول اپلیکیشن‌های وب متفاوت است:

• تزریق ابزار (Tool Injection): ورودی کنترل‌شده توسط مهاجم به یک ابزار MCP می‌رسد و با سطح دسترسی و امتیازات عامل اجرا می‌شود.
• نشت داده‌های متقاطع (Cross-Tool Data Leakage): اطلاعات حاصل از پاسخ یک ابزار به‌طور ناخواسته به ابزار دیگری که دسترسی گسترده‌تری دارد منتقل می‌شود.
• ارتقای پرامپت به ابزار (Prompt-to-Tool Escalation): یک پرامپت مهندسی‌شده و دقیق، عامل را مجبور می‌کند تا ترکیبی خطرناک از ابزارها را فراخوانی کند.

برای مقابله با این تهدیدات، درک تفاوت میان راهکارهای مسدودسازی خروج داده‌ها و پیشگیری از تزریق در چهارچوب MCP برای معماران امنیت ضروری است. تیم عملیاتی حسابرسی امنیت AI ما بیش از ۸۰,۰۰۰ اثرگذاری (Trace) در محیط عملیاتی را تحلیل کرده است. این مجموعه شامل ۲۰,۰۰۰ مورد عمومی و ۶۰,۰۰۰ مورد داخلی در ۱۳ ارائه‌دهنده و ۳۳ معماری مدل مختلف است. داده‌ها نشان‌دهنده یک شکاف بحرانی بین قابلیت‌های عامل (Agent Capability) و امنیت سرور (Server Security) هستند.

۶ بُعد ریسک در MCP

طبق گزارشی که Correctover در ۲۵ ژوئیه ۲۰۲۶ منتشر کرد، تیم‌های امنیتی باید ۶ حالت شکست مشخص را ارزیابی کنند:

• آرگومان‌های تأییدنشده (Unvalidated Tool Arguments): سرورها اغلب به پارامترهای ارائه شده توسط عامل اعتماد می‌کنند. برای مثال، یک ابزار مانند read_file(path: string) اگر اعتبارسنجی مسیر کانونی (Canonical Path Validation) نداشته باشد، ممکن است اجازه پیمایش مسیر (مثلاً ../../etc/passwd) را بدهد.
  • یافته واقعی: یک مورد پیمایش مسیر در یک بسته محبوب سرور فایل MCP کشف شد که اجازه می‌داد فایل‌های دلخواه خارج از دایرکتوری فضای کاری خوانده شوند.
• فقدان مرزهای احرازهویت (Missing Authorization Boundaries): بسیاری از استقرارها اجازه می‌دهند چندین کاربر یا عامل از یک سرور واحد استفاده کنند. این موضوع باعث می‌شود «عامل الف» بتواند ابزارهایی را فراخوانی کند که فقط برای «عامل ب» در نظر گرفته شده‌اند.
  • یافته واقعی: در یک پلتفرم هوش مصنوعی مالی، ابزارهای execute_trade (اجرای معامله) و read_portfolio (خواندن سبد دارایی) روی یک سرور بدون هیچ کنترل دسترسی ثبت شده بودند و نیاز به ایزولاسیون عامل‌ها داشتند.
• زنجیره‌سازی ضمنی ابزارها (Implicit Tool Chaining): مهاجمان ورودی‌هایی می‌سازند که در آن خروجی یک ابزار، اثر جانبی در ابزار بعدی ایجاد کند.
  • یافته واقعی: یک زنجیره اجرای کد از راه دور (RCE) در یک استقرار CrewAI رخ داد؛ زمانی که خروجی read_file حاوی کاراکترهای متاتک (Metacharacters) شل بود و به ابزار run_command پاس داده شد.
• تخلیه منابع (Resource Exhaustion): عملیات‌های هزینه‌بر مانند کوئری‌های عمیق در پایگاه داده، عملیات I/O فایل یا فراخوانی‌های API می‌توانند توسط یک عامل به‌صورت تکراری تحریک شوند و منجر به حمله منع سرویس (DoS) گردند.
• پیش‌فرض‌های ناامن (Insecure Defaults): این حسابرسی نشان داد که بسیاری از سرورها با حالت Debug فعال، تنظیمات CORS بیش از حد باز یا اعتبارنامه‌های پیش‌فرضی عرضه می‌شوند که به ندرت پیش از استقرار سخت‌سازی (Harden) می‌شوند.
• تزریق پرامپت غیرمستقیم (Indirect Prompt Injection): وقتی یک ابزار MCP داده‌ای را برمی‌گرداند که حاوی دستورالعمل است، یک عامل آسیب‌پذیر ممکن است آن نتایج را به عنوان دستورات جدید برای اجرا تفسیر کند. این مورد، گونه‌ی خاص MCP از تزریق پرامپت غیرمستقیم است.

بنچمارک چارچوب‌ها و یافته‌ها

بین ژوئن و ژوئیه ۲۰۲۶، تیم پژوهشی ۵۳ اثبات مفهوم (PoC) را در ۸ چارچوب محبوب بازسازی کردند. تمام یافته‌ها در یک محیط ایزوله (Sandbox) تایید شدند. نتایج نشان‌دهنده روند خطرناکی از آسیب‌پذیری‌های اجرای کد از راه دور (RCE) است:

• AutoGen Studio: یک مورد RCE با امتیاز CVSS ۹.۸ از طریق تزریق آرگومان ابزار.
• CrewAI MCP: یک مورد RCE از طریق زنجیره‌های تزریق ابزار.
• LlamaIndex: یک مورد RCE شامل دسریالیزه کردن Pickle.
• Haystack: دو مورد RCE از طریق تزریق خط لوله (Pipeline).
• AG2: یک مورد RCE با استفاده از اکسپلویت متد str.
• Docker MCP: دو آسیب‌پذیری شامل خروج از کانتینر (Container Escape) و نشت اعتبارنامه‌ها.
• LiteLLM: یک مورد SSRF از طریق دور زدن (Bypass) پروکسی.
• LangChain: سطوح متعددی برای تزریق پرامپت.

این ۱,۷۳۰+ یافته تایید شده از مجموعه‌ی ۸۰,۰۰۰ اثرگذاری تولیدی استخراج شده که توسط موتور سیستم طبقه‌بندی Correctover (CCS) پردازش شده‌اند. تیم تحقیق پروتکل افشای مسئولانه را دنبال کرد و یافته‌ها را با یک پنجره زمانی ۹۰ روزه برای افشا، به تیم‌های PSIRT سازندگان یا برنامه‌های Bug Bounty ارسال نمود.

حسابرسی خودکار و رفع نقص

موتور CCS از ۲۴ قانون تشخیص برای خودکارسازی کشف و فازینگ (Fuzzing) ابزارهای MCP استفاده می‌کند. این فرآیند در چهار مرحله عمل می‌کند:

۱. کشف (Discover): فهرست کردن تمام ابزارهای ثبت شده روی سرور MCP.
۲. فازینگ (Fuzz): تزریق مقادیر مرزی، کاراکترهای خاص و الگوهای شناخته‌شده اکسپلویت در هر پارامتر ابزار.
۳. زنجیره‌سازی (Chain): تست ترکیبات ابزاری برای یافتن مسیرهای ارتقای دسترسی.
۴. گزارش (Report): طبقه‌بندی یافته‌ها بر اساس شناسه قانون CCS همراه با امتیازدهی CVSS.

این سیستم می‌تواند یک سرور معمولی را در کمتر از ۳۰ ثانیه پردازش کند و نرخ مثبت کاذب (False Positive) آن در پیکربندی‌های تست شده در محیط عملیاتی زیر ۳٪ است. این سرعت به تیم‌های امنیتی اجازه می‌دهد تا حسابرسی MCP را مستقیماً در خط لوله‌های CI/CD ادغام کنند.

چک‌لیست ۵ مرحله‌ای تست نفوذ MCP

برای کسانی که حسابرسی‌های دستی انجام می‌دهند، گردش کار پیشنهادی شامل این ۵ گام است. برای تکمیل این فرآیند، توصیه می‌شود چک‌لیست ۶ مرحله‌ای ایمن‌سازی سرورها را به عنوان مرجعی برای سخت‌سازی زیرساخت پیش از استقرار به کار ببرید:

• گام ۱: نقشه‌برداری (Map) تمام ابزارهای ثبت شده و شمای پارامترهای آن‌ها را با استفاده از MCP inspector یا اسکریپت‌های سفارشی شناسایی کنید.
• گام ۲: تست (Test) هر پارامتر را برای تزریق (مسیر، دستور، SQL، SSRF) با استفاده از اسکنر CCS یا فازینگ دستی بررسی کنید.
• گام ۳: تست زنجیره‌ها ترکیبات ابزاری را برای یافتن زنجیره‌های ارتقای دسترسی با استفاده از یک محیط تست سفارشی بررسی کنید.
• گام ۴: تایید (Verify) مرزهای احرازهویت بین عامل‌ها را از طریق بررسی پیکربندی تایید کنید.
• گام ۵: حسابرسی (Audit) امنیت انتقال (TLS، توکن‌های احراز هویت، ذخیره‌سازی اعتبارنامه‌ها) را از طریق اسکن‌های شبکه و بررسی کد ارزیابی کنید.

این تغییر در سطح حمله به این معنی است که توسعه‌دهندگان دیگر نمی‌توانند با ابزارهای MCP به عنوان توابع داخلی برخورد کنند. هر ابزار باید مانند یک نقطه انتهایی (Endpoint) عمومی API در نظر گرفته شود. به طور متوسط، هر استقرار در چارچوب‌های تحلیل شده حاوی ۲ تا ۳ آسیب‌پذیری شدید بود، که ثابت می‌کند خودمختاری عامل‌ها در حال حاضر سریع‌تر از امنیت آن‌ها پیش می‌رود.

مهندسان امنیت اکنون باید ایزولاسیون سرورهای MCP را در اولویت قرار دهند و اعتبارسنجی سخت‌گیرانه ورودی‌ها را برای هر ابزاری که با عامل در تماس است پیاده‌سازی کنند. همان‌طور که عامل‌ها از نقش‌های «فقط خواندنی» به نقش‌های «دسترسی نوشتن» منتقل می‌شوند، هزینه یک شکست در تزریق ابزار از نشت داده به بهسازی کامل سیستم (Full System Compromise) تغییر می‌کند.

برای ایمن‌تر کردن پشته (Stack) خود، توصیه می‌شود سندباکس عامل خود را برای دور زدن محدودیت‌های شبکه و نشت داده‌ها تست کنید، زیرا ایزولاسیون‌های پایه اغلب زمانی که مدیران بسته (Package Managers) تنظیمات پروکسی را به ارث می‌برند، شکست می‌خورند.

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