أصبح لدى Fetch حاجز. لكنه ليس جداراً نارياً.
إصدار MCP في 11 أكتوبر يرفض الوجهات غير العامة افتراضياً. إعادة ربط DNS والأسماء التي يحلها الوكيل وحده تبقى خارج الضمان.
حقائق جرى التحقق منها في 12 أكتوبر 2026
إصدار MCP في 11 أكتوبر يرفض الوجهات غير العامة افتراضياً. إعادة ربط DNS والأسماء التي يحلها الوكيل وحده تبقى خارج الضمان. PR #5033
الطلب ينطلق من مكان آخر
يصل عنوان URL إلى محادثة مع الذكاء الاصطناعي. يبدو أنه طلب لقراءة صفحة عامة. لكن الاتصال ينطلق من الجهاز الذي يشغل خادم Fetch، لا من الشخص الذي يكتب العنوان. هذه هي المشكلة: الأداة تستعير نطاق الوصول الشبكي للمضيف. قراءتي لإصدار خوادم MCP المرجعية الجديد هي أن سلوكاً افتراضياً مفيداً قد تغير، لكن الجهاز ما زال يحتاج إلى حد مستقل.
ما صدر وما لم يصبح وعداً
يسرد سجل الإصدار الرسمي المنشور في 11 أكتوبر الساعة 02:40 UTC الحزمة mcp-server-fetch 2026.10.10 ضمن سبع حزم مرجعية منشورة. وتتضمن التغييرات طلب الدمج #5033 لرفض العناوين الخاصة والمحلية وعناوين البيانات الوصفية افتراضياً. دُمج الطلب في 5 أكتوبر. هذا إصدار حزمة، وليس إعلاناً بأن كل نشر لـ MCP أصبح يملك هذا الحاجز. العملية القديمة لا تكتسب سياسة جديدة بمجرد وجود صفحة إصدار.
موضع التحقق
يصف المشرفون خطافاً لطلبات HTTP يحل اسم المضيف قبل كل طلب. إذا كان أي عنوان ناتج غير عام، يُرفض الطلب. يشمل التحقق robots.txt وطلب الصفحة وكل خطوة إعادة توجيه، في مساري الأداة وprompt. لذلك لا يمنح العنوان العام الأول إذناً لإعادة توجيه لاحقة إلى عنوان داخلي. خيار التشغيل الموثق --allow-private-ips يعطل الحاجز. إنه إعداد للمضيف، وليس وسيطة يستطيع النموذج إضافتها إلى استدعاء Fetch واحد.
حدان خلف جملة بسيطة
يسمي المصدر حدين. يحل الخطاف اسم المضيف ثم يحله اتصال HTTP مرة أخرى. قد تقدم إعادة ربط DNS إجابتين مختلفتين: فحص عنوان عام لا يعني الاتصال بذلك العنوان نفسه. كذلك يُمرر الاسم الذي لا يستطيع الخادم حله إلى طبقة النقل. وقد يحله وكيل في مكان آخر. لا يستطيع فحص الخادم ضمان وجهة لم يحلها. هذه حدود موثقة وليست أعطالاً أعدت إنتاجها. لم أثبت الحزمة ولم أشغلها.
تحليل: ضع الضمان عند الاتصال
استنتاجي أضيق من «تصفح آمن للوكلاء»: يغلق الحاجز مسارات افتراضية مهمة إلى عناوين غير عامة، بينما يجب أن تقيد سياسة خروج مستقلة الاتصال الفعلي. في مراجعة نشر، سأسأل أي محلل أسماء ووكيل وقاعدة شبكة يحدد الوجهة النهائية. قائمة URL مسموحة وحدها لا تجيب عن ذلك. ولا وصف read-only: القراءة قد ترسل طلباً يحتوي استعلاماً حساساً، وقد تتضمن الاستجابة تعليمات عدائية. تعامل مع النص المسترجع كدليل، لا كإذن لتغيير المهمة.
خطة قبول قابلة للتكرار، لا تقرير اختبار
قبل النشر استخدم جهازاً مؤقتاً بلا أسرار ونقطة عامة تتحكم بها. جرّب صفحة عامة عادية وعنوان loopback مباشراً وإعادة توجيه عامة إلى loopback واسماً يحله الوكيل المضبوط وحده. سجل نسخة الحزمة الدقيقة والخيارات والوكيل والوجهة المطلوبة. توقع الرفض الموثق عندما يستطيع الحاجز حل العنوان؛ لا تصف حالة proxy-only بأنها محمية. افحص أو اختبر حد موصل الاتصال منفصلاً لإعادة ربط DNS. لا تفحص خدمة داخلية تخص غيرك أو نقطة بيانات وصفية حقيقية.
ما الذي أبقيه في تذكرة الإصدار
الأثر المفيد سجل صغير: نسخة الخادم المرصودة، غياب خيار التجاوز، دليل رفض كل إعادة توجيه، سياسة الشبكة عند الاتصال، والحدان المتبقيان. افصل «المشرفون يذكرون» عن «نحن رصدنا». يذكر طلب الدمج اختبارات بروتوكول وتجربة Inspector، لكنه يقول إنه لم يختبر عميل LLM هناك. هذا دليل مفيد بحد معلن. رقم النسخة يسمي إصداراً؛ لا يعوض أدلة النشر.
سجل قرار توضيحي، وليس شيفرة أمنية قابلة للتشغيل
طلب ← حل اسم المضيف ← رفض العنوان غير العام
↓
اتصال HTTP يحل الاسم مرة ثانية
↓
الوجهة الفعلية تحتاج سياسة خروج