آسیب‌پذیری سیستماتیک در سرورهای MCP گوگل و مایکروسافت افشا شد

اگر یک عامل هوش مصنوعی را به زیرساخت‌های داخلی شرکت خود متصل کرده‌اید، احتمالاً کل شبکه شما در برابر یک حمله ساده باز است. این یک خطای کدنویسی ساده نیست، بلکه یک نقص معماری در نحوه برخورد ایجنت‌ها با لینک‌های خارجی است. این باگی است که تنها زمانی قابل شناسایی می‌شود که برای سومین بار دیده شود؛ بار اول یک اشتباه، بار دوم یک تصادف و در نهایت یک فرض مشترک که در چهار کدبیس، زبان‌های برنامه‌نویسی و فرهنگ‌های بازبینی مختلف وجود دارد.

طبق گزارش سید انس محی‌الدین (Syed Anas Mohiuddin)، پژوهشگر امنیتی، یک شکست سیستماتیک در پروتکل زمینهٔ مدل (Model Context Protocol یا MCP) شناسایی شده است که سرورهای گوگل، مایکروسافت، آنتروپیک و ویویت (Weaviate) را در معرض حمله جعل درخواست سمت سرور (Server-Side Request Forgery یا SSRF) قرار داده است. در طول نه ماه اول سال ۲۰۲۶، همین فرض غلط در سرورهای عرضه شده توسط این چهار فروشنده ظاهر شد، علی‌رغم اینکه از فریم‌ورک‌ها و فرهنگ‌های بازبینی متفاوتی استفاده می‌کردند.

این کشف در حالی صورت می‌گیرد که MCP به سرعت در حال تبدیل شدن به استاندارد صنعت برای اتصال عامل‌های هوش مصنوعی به ابزارها، فایل‌ها و APIها است. از آنجا که سرورهای MCP به عنوان پل ارتباطی بین استدلال یک مدل زبانی و اقدامات دنیای واقعی عمل می‌کنند — اقداماتی مانند پرس‌وجو از پایگاه‌های داده، واکشی صفحات وب، هدایت یک مرورگر یا فراخوانی یک API جاسازی (Embedding) — آن‌ها دسترسی‌های سطح بالایی به محیط‌های داخلی دارند. اگر سرور به مدل اعتماد کورکورانه داشته باشد، در واقع به هر پرامپت نامعتبر و غیرقابل اعتمادی که مدل تا به حال پردازش کرده است، اعتماد کرده است. این آسیب‌پذیری‌ها در کنار این واقعیت که بسیاری از سرورهای عمومی MCP فاقد سیستم‌های احراز هویت هستند، ریسک امنیتی این اکوسیستم را دوچندان می‌کند.

مکانیزم «چرخش پروتکل»

محی‌الدین این کلاس از آسیب‌پذیری را «چرخش پروتکل» (Protocol Pivoting) می‌نامد. در این سناریو، مهاجم یک URL مخرب را مستقیماً به سرور نمی‌فرستد. در عوض، آن‌ها یک تزریق پرامپت (Prompt Injection) را در یک صفحه وب، یک سند، یک تیکت پشتیبانی یا یک ردیف از پایگاه داده قرار می‌دهند که LLM آن را می‌خواند. مدل که توسط تزریق هدایت شده است، سپس درخواستی به یک IP داخلی یا پنل مدیریت تولید می‌کند و سرور MCP بدون هیچ اعتبارسنجی، آن را اجرا می‌کند.

این نشان‌دهنده یک تغییر بنیادین در مرز اعتماد است. در یک اپلیکیشن وب کلاسیک، مهاجم URL را در یک فرم تایپ می‌کند. در یک سرور MCP، مهاجم متنی را در جایی قرار می‌دهد که مدل آن را بخواند و سپس مدل URL را تایپ می‌کند. سرور درخواستی را از مدل قابل اعتماد خود می‌بیند و به این فکر نمی‌کند که این ایده از کجا آمده است. در نتیجه، هر پارامتری که یک سرور MCP می‌پذیرد، طبق تعریف تحت کنترل مهاجم قرار می‌گیرد. مدل یک فراخواننده قابل اعتماد نیست؛ بلکه پروکسی برای هر ورودی نامعتبر است که تا به حال دیده است. این عدم کنترل بر ورودی‌ها را می‌توان در چالش‌های عملیاتی سرورهای MCP در محیط‌های تجاری که منجر به توهمات و رفتارهای پیش‌بینی‌نشده می‌شوند، نیز مشاهده کرد.

گوگل: حفرهٔ بازگشت (Redirect)

در MCP Toolbox گوگل برای پایگاه‌های داده، این آسیب‌پذیری در نوع منبع HTTP وجود داشت. سیستم به اپراتورها اجازه می‌داد تا Toolbox را به یک URL پایه (Base URL) متصل کنند و ابزارهای ساخته شده بر روی آن منبع، درخواست‌هایی را به مسیرهای زیرمجموعه آن ارسال می‌کردند. این نقص در فایل internal/sources/http/http.go قرار داشت.

• نقص فنی: کد یک http.Client استاندارد در زبان Go ایجاد می‌کرد اما فاقد قلاب CheckRedirect بود و در پیاده‌سازی اعتبارسنجی IP مقصد شکست خورده بود.
• اثر ترکیبی: به دلیل اینکه کلاینت پیش‌فرض Go بازگشت‌ها (Redirects) را به‌طور خودکار دنبال می‌کند، Toolbox هیچ راهی برای بازرسی هر گام (Hop) نداشت. بدون اعتبارسنجی مقصد، حتی درخواست اولیه نیز می‌توانست به مقاصد ممنوعه هدایت شود.
• پیامد: گوگل این نقص را با شناسه CVE-2026-14540 ثبت کرد که در تاریخ ۲۰۲۶-۰۷-۳۱ از طریق CNA گوگل منتشر شد. این مورد با امتیاز ۸.۰ (بالا) در مقیاس CVSS v4.0 رتبه‌بندی و در دسته CWE-918 (SSRF) طبقه‌بندی شد.
• راهکار: نسخه‌های آسیب‌پذیر ۰.۳.۰ تا ۱.۴.۰ در PR شماره ۳۴۴۸ در googleapis/mcp-toolbox اصلاح شدند که در تاریخ ۲۰۲۶-۰۶-۱۸ به عنوان نسخه v1.5.0 ادغام و منتشر شد.

فرض اصلی در اینجا این بود که URL پایه که توسط اپراتور پیکربندی شده است، تصمیم اعتماد را نهایی می‌کند و هر چیزی که پس از آن می‌آید به طور ارثی ایمن است. بازگشت‌ها (Redirects) این ارث‌بری را شکستند. محی‌الدین مقاله‌ای کامل در مورد جزئیات این مورد خاص نوشته است.

آنتروپیک و مایکروسافت: دور زدن حفاظ‌ها

هر دو سرور mcp-server-fetch آنتروپیک (که محتوای URL را بازیابی می‌کند) و playwright-mcp مایکروسافت (که یک مرورگر واقعی را هدایت می‌کند)، در پیاده‌سازی مرزهای شبکه شکست خوردند. هیچ‌کدام از این سرورها از لیست مجاز (Allowlist) استفاده نمی‌کردند و محدوده‌های IP داخلی، آدرس‌های Link-local، آدرس‌های Loopback یا فضای خصوصی (Private Space) را مسدود نکرده بودند.

این امر اجازه می‌داد تا یک مدل هدایت‌شده، پنل‌های مدیریت داخلی یا نقاط انتهایی متاداده (Metadata Endpoints) را درخواست کند. مورد آنتروپیک یک شکست معماری خاص را برجسته کرد:

• حفاظ: سرور شامل تابعی به نام check_may_autonomously_fetch_url() بود که برای کنترل بازیابی‌ها طراحی شده بود.
• دور زدن: در حالی که مسیر اصلی فراخوانی ابزار ممکن بود محافظت شده باشد، هندلر get_prompt مستقیماً تابع fetch_url() را فراخوانی می‌کرد و عملاً بررسی امنیتی را کاملاً دور می‌زد.

این الگو — که در آن کنترل‌های امنیتی به مسیرهای اصلی اضافه می‌شوند اما در مسیرهای ثانویه مانند پرامپت‌ها، منابع یا تکمیل‌ها (Completions) نادیده گرفته می‌شوند — یک شکل تکرار شونده در توسعه سرورهای MCP است. این مسائل در ۲۵ مه ۲۰۲۶ در لیست پستی Full Disclosure منتشر شدند و امتیاز CVSS 3.1 آن‌ها ۷.۵ بود. در زمان افشا، هر دو مورد در رشته‌های عمومی گیت‌هاب (از جمله modelcontextprotocol/servers شماره‌های ۴۱۱۶، ۴۱۴۳، ۴۲۰۵ و microsoft/playwright-mcp شماره ۱۶۲۶) قابل مشاهده بودند. افشای رسمی این موارد را یکپارچه کرد و شدت آن‌ها را تعیین نمود. تا زمان افشا، وضعیت اصلاح برای هر دو فروشنده تایید نشده بود. این نوع دسترسی‌های غیرمنتظره یادآور قابلیت Sampling در پروتکل MCP است که به سرورها اجازه می‌دهد با ارسال پرامپت‌های بازگشتی، مدل کاربر را هدایت کنند.

ویویت: تداخل در نام‌گذاری

ویویت (Weaviate)، که یک پایگاه‌داده برداری است، ماژول‌های قابل جایگزینی (مانند text2vec-google ،multi2vec-google و generative-google) ارائه می‌دهد که APIهای جاسازی و تولید را فراخوانی می‌کنند. این ماژول‌ها یا از کلید API گوگل اپراتور به عنوان اعتبارنامه Bearer استفاده می‌کنند یا در صورت فعال بودن USE_GOOGLE_AUTH=true از یک توکن OAuth زنده GCP با دامنه cloud-platform استفاده می‌کنند.

ویویت در واقع دو بار تلاش کرده بود این باگ را از طریق دو مرحله سخت‌سازی برطرف کند:

• مرحله اول: PR شماره ۱۰۸۷۸ که در ۲۰۲۶-۰۳-۲۷ ادغام شد و اعتبارسنجی اختیاری baseURL را پیاده‌سازی کرد.
• مرحله دوم: PR شماره ۱۱۶۸۳ که در ۲۰۲۶-۰۶-۱۸ ادغام شد و ۲۱ سازنده URL را از طریق اعتبارسنجی هدر X-*-BaseURL پوشش داد.

هر دو مرحله از نظر ساختاری روی فیلدی به نام baseURL متمرکز بودند. با این حال، ماژول‌های گوگل از فیلدی با نام متفاوت یعنی apiEndpoint استفاده می‌کردند. به دلیل این تفاوت در نام‌گذاری، apiEndpoint بدون تغییر از هر دو مرحله سخت‌سازی عبور کرد.

این نقص به کاربر اجازه می‌داد تا ماژول را به میزبانی که تحت کنترل خودش است هدایت کند تا کلید API گوگل یا توکن OAuth GCP اپراتور را سرقت کند. این مورد از دو مسیر قابل دسترسی بود:

• پیکربندی طرح کلاس (Class Schema Config): این مسیر نیاز به دسترسی نوشتن طرح (Schema-write) دارد.
• پارامتر زمان پرس‌وجوی GraphQL: این مسیر با دسترسی معمولی خواندن قابل دسترسی است، به این معنی که مهاجم نیازی به مدیر بودن نداشت؛ او فقط باید قادر به اجرای یک پرس‌وجو می‌بود.

گزارش از طریق HackerOne ارسال و توسط تیم امنیتی Weaviate تایید شد. اصلاحیه در PR شماره ۱۲۹۶۱ در weaviate/weaviate در تاریخ ۷ سپتامبر ۲۰۲۶ در نسخه stable/v1.37 ادغام شد.

شناسایی خودکار با mcp-safeguard

محی‌الدین این الگوها را نه از طریق حسابرسی دستی، بلکه با استفاده از mcp-safeguard شناسایی کرد؛ یک اسکنر تحلیل استاتیک متن‌باز که تحت لایسنس MIT در PyPI در دسترس است. این ابزار تقریباً ۱۵۰ قانون را در هفت دسته اجرا می‌کند:

• تزریق پرامپت (Prompt Injection)
• نشت اعتبارنامه‌ها (Credential Leaks)
• افشای نقاط انتهایی (Endpoint Exposure)
• مسموم کردن ابزار (Tool Poisoning)
• SSRF
• دامنه OAuth (OAuth Scope)
• حسابرسی منبع (Source Audit)

با اعمال قوانین یکسان روی کد Go گوگل، پایتون آنتروپیک و لایه ماژول ویویت، پژوهشگر ثابت کرد که این باگ یک شکست مفهومی بود و نه مجموعه‌ای از خطاهای اتفاقی. این کار در قالب یک پیش‌نویس IETF (draft-mohiuddin-mcp-security-considerations-00) تعمیم یافته است که شش کلاس آسیب‌پذیری را توصیف کرده و مفهوم «چرخش پروتکل» را رسمیت می‌بخشد.

خلاصه یافته‌ها و جدول زمانی

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

• ۲۰۲۶-۰۳-۲۷: ویویت PR شماره ۱۰۸۷۸ (اعتبارسنجی اولیه baseURL) را ادغام می‌کند.
• ۲۰۲۶-۰۵-۲۵: SSRF در mcp-server-fetch آنتروپیک و playwright-mcp مایکروسافت در Full Disclosure افشا می‌شود.
• ژوئن ۲۰۲۶: پیش‌نویس IETF با عنوان draft-mohiuddin-mcp-security-considerations-00 منتشر می‌شود.
• ۲۰۲۶-۰۶-۱۸: گوگل PR شماره ۳۴۴۸ را ادغام کرده و v1.5.0 را منتشر می‌کند؛ ویویت PR شماره ۱۱۶۸۳ را ادغام می‌کند.
• ۲۰۲۶-۰۷-۳۱: CNA گوگل شناسه CVE-2026-14540 را منتشر می‌کند.
• ۲۰۲۶-۰۹-۰۷: ویویت PR شماره ۱۲۹۶۱ را برای اصلاح apiEndpoint در stable/v1.37 ادغام می‌کند.

برای توسعه‌دهندگان، درس روشن است: تکیه بر LLM برای «فیلتر کردن» نیت‌های مخرب، یک استراتژی امنیتی قابل اتکا نیست. برای ایمن کردن این پیاده‌سازی‌ها، اپراتورها باید اعتبارسنجی سخت‌گیرانه IP مقصد را اجرا کنند، بازگشت‌های خودکار را غیرفعال کنند و اطمینان حاصل کنند که حفاظ‌های امنیتی در هر مسیر کد ممکن متصل شده‌اند. منتظر نهایی شدن پیش‌نویس ملاحظات امنیتی IETF باشید که احتمالاً نحوه استقرار عامل‌های هوش مصنوعی سازمانی در محیط‌های شبکه حساس را بازتعریف خواهد کرد.

گام بعدی شما

• اگر از سرورهای MCP استفاده می‌کنید، فوراً نسخه‌های نصب‌شده را با آخرین ریلیزهای گوگل و ویویت تطبیق دهید.
• در پیاده‌سازی‌های شخصی، هرگز به خروجی مدل برای تولید URL اعتماد نکنید و یک لیست سفید (Allowlist) سخت‌گیرانه برای IPهای مقصد تعریف کنید.
• قابلیت Redirect خودکار را در کلاینت‌های HTTP سرورهای خود غیرفعال کنید.

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