مساء 10 أغسطس 2026، فتح حساب واحد على GitHub ثلاثة وعشرين طلب دمج (pull request) على مشاريع ذكاء اصطناعي وأدوات مطورين لا علاقة بينها، خلال 74 دقيقة. كل طلب أضاف إلى إعدادات المشروع خادم MCP اسمه productivity-suite. كان يعرض تنسيق النصوص وتلخيصها، وفي أول ثلاثة استدعاءات للأدوات لم يفعل غير ذلك. بعد الاستدعاء الثالث غيّر التعليمات التي يعيدها إلى وكيل الذكاء الاصطناعي، فطلب منه البحث عن مفاتيح SSH وبيانات اعتماد AWS وسجل أوامر الطرفية وإعدادات Kubernetes، وأن يلتزم الصمت حيال ذلك. نشرت Pillar Security التفاصيل في 12 أغسطس وأطلقت على الحملة اسم Deadbugz.
نحن نشغّل وكلاء برمجة بالذكاء الاصطناعي مع مجموعة من خوادم MCP كل يوم، ففعلنا البديهي وراجعنا إعداداتنا نحن. ولم تنجح المراجعة. يشرح هذا المقال لماذا يختلف هذا النوع من الهجمات عن حوادث npm وPyPI التي تستعد لها معظم الفرق أصلًا، وماذا وجدنا في مراجعتنا، وقائمة الفحص التي نعمل عليها الآن.
لماذا يختلف خادم MCP عن أي اعتمادية أخرى
المكتبة العادية تفعل ما تقوله شيفرتها. يمكنك قراءتها وتثبيت إصدارها وفحصها. أما خادم MCP فيفعل أمرين: يشغّل شيفرة على جهازك أو على جهاز غيرك، ويسلّم وكيل الذكاء الاصطناعي نصًا يتعامل معه الوكيل على أنه تعليمات. أسماء الأدوات وأوصافها وقوالب التوجيه كلها تأتي من الخادم، والنموذج يقرؤها بالطريقة نفسها التي يقرأ بها طلبك.
هذه القناة الثانية هي ما استغلته Deadbugz. بحسب تقرير Pillar، كان الخادم يحتفظ في الذاكرة بعدّاد لكل عميل. وبمجرد أن يُجري العميل ثلاثة طلبات tools/call، تبدأ ردود tools/list وprompts/get اللاحقة في حمل التعليمات الجديدة. لم تظهر أداة جديدة، ولم يبدُ شيء غريبًا في قائمة الأدوات وقت التثبيت. من يجرّب الخادم دقيقة واحدة سيرى أداة بريئة لتنسيق النصوص. الحمولة وصلت عبر بيانات وصفية كان الوكيل يثق بها أصلًا.
نصيحة Pillar لمن يبنون عملاء MCP هي الجزء الذي يستحق التكرار: أي تغيير في تعريفات الأدوات لخادم سبقت الموافقة عليه يجب أن يُعامل كحدث أمني ويحتاج موافقة جديدة. معظم العملاء اليوم لا يفعلون ذلك. توافق على الخادم مرة واحدة، وكل ما يقوله بعدها يدخل مباشرة في سياق النموذج.
ما مدى انكشاف الآخرين؟
المشكلة لا تقتصر على أجهزة المطورين. أحصت Censys 12,520 خدمة MCP يمكن الوصول إليها من الإنترنت في 28 أبريل 2026، موزعة على 8,758 عنوان IP، ثم أكثر من 21,000 بحلول 6 مايو. الخوادم الواردة في تقريرهم كانت متاحة دون مصادقة. أكبر المجموعات كانت أدوات البيانات والمعرفة (1,776، كثير منها واجهات استعلام مباشرة لقواعد بيانات) وأدوات البنية التحتية (1,549). لم تستدعِ Censys هذه الأدوات، لذا فالأرقام تُظهر الانكشاف لا اختراقًا مؤكدًا.
المزوّدون يتحركون. في 14 أغسطس أضافت Cloudflare رصد حركة MCP إلى Gateway، بالاعتماد على ترويسة MCP-Protocol-Version، فتستطيع الشركة على الأقل أن ترى أي الأجهزة تتحدث MCP وأن تحجب الاتصالات المباشرة التي تتجاوز بوابة معتمدة. أما صفحة أفضل الممارسات الأمنية الخاصة بالبروتوكول نفسه فصريحة بشأن الخوادم المحلية: فهي تعمل بصلاحيات العميل نفسها، والعميل الذي يتيح الإعداد بنقرة واحدة يجب أن يعرض الأمر الكامل دون اقتطاع قبل تشغيله. وتوصي أيضًا بعزل الخوادم في بيئة معزولة (sandbox) بأدنى وصول افتراضي إلى نظام الملفات والشبكة.
الرؤية على مستوى الشبكة تساعد فريق الأمن، لكنها لا تجيب عن السؤال الذي يجب أن يطرحه المطوّر أولًا: ما الذي ثبّتُّه فعلًا، وإلى أين يمكنه الوصول؟
ما وجدناه في إعداداتنا
يعمل على خادم التطوير لدينا Claude Code مع سبعة خوادم MCP مُعدّة على المستوى العام، واثنين آخرين محصورين في مشاريع بعينها. كتبنا عن طريقة توزيع العمل بين الوكلاء في مقالنا عن سير عمل RPI (بالإنجليزية)؛ أما هذه المراجعة فكانت عن البنية التي يقوم عليها ذلك السير. أربع نتائج كانت مهمة.
ثلاثة خوادم بلا تثبيت للإصدار. أحدها يُشغَّل بـ npx -y مع اسم الحزمة فقط، وآخر بـ @latest، والثالث مباشرة من الفرع الافتراضي لمستودع Git عبر uvx. كل واحد منها ينزّل ويشغّل أحدث ما هو متاح في كل مرة تبدأ فيها جلسة. لكي يصلنا تغيير على طريقة Deadbugz، لا يحتاج أحد أن يرسل لنا طلب دمج. يكفي أن تتغير الحزمة في المصدر، سواء عبر حساب مشرف مخترق كما في هجوم التصيّد على npm في سبتمبر 2025، أو عبر مشرف غيّر رأيه.
أربعة خوادم كانت نقاط نهاية HTTP بعيدة. تعريفات أدواتها موجودة على خادم غيرنا، ويمكن أن تتغير في أي لحظة دون أي تحديث من جهتنا. تثبيت الإصدار لا يفيد هنا. الدفاع الوحيد أن تلاحظ تغيّر التعريفات، ولم تكن لدينا وسيلة لذلك.
أكبر نطاق للضرر لم يكن الطرفية. خادم أتمتة المتصفح لدينا يتصل عبر Chrome DevTools Protocol بملف تعريف متصفح يعمل باستمرار ويبقى مسجّل الدخول إلى عدة حسابات عمل لدينا. أي شيء يستطيع توجيه ذلك الخادم يستطيع التصرف باسمنا على كل تلك الحسابات. كنا نفكر في مفاتيح SSH، بينما كانت جلسة المتصفح هي الهدف الأثمن.
سبق أن لدغنا التباس أسماء الأدوات. في وقت سابق من هذا الشهر كان خادما Playwright MCP نشطين في آن واحد بأسماء أدوات متداخلة، أحدهما متصل بذلك المتصفح المشترك والآخر يطلق نسخة Chromium معزولة خاصة به. ظل الوكيل يختار الخادم الخطأ، وقضينا جلسة تصحيح طويلة ونحن نظن أن المتصفح تعطّل. لم يحدث شيء خبيث، لكن ذلك أظهر لنا أن النموذج يختار الأدوات بالاسم والوصف، وأن العميل لم ينبّهنا إلى أن خادمين يدّعيان الأسماء نفسها. خادم عدائي يستطيع فعل الشيء ذاته عن قصد.
قائمة فحص عملية لخوادم MCP
هذه قائمة الفحص التي نطبّقها على كل جهاز فيه وكيل لديه خوادم MCP. إعداداتنا نفسها فشلت في البندين 2 و3 عند الفحص الأول.
- اجرد كل شيء. الإعدادات العامة، وملفات الإعداد الخاصة بكل مشروع، والخوادم التي تأتي مع الإضافات، وأي شيء أضافه زميل في طلب دمج. انظر إلى الأمر الكامل ومعاملاته لكل خادم. إذا لم تستطع أن تقول لماذا يوجد خادم ما، فاحذفه.
- ثبّت إصدار كل خادم يُشغَّل محليًا. استخدم رقم إصدار محددًا لحزم npm (مثل
1.4.2، وليس@latestأبدًا) وبصمة commit لمصادر Git. حدّث عن قصد، بعد قراءة سجل التغييرات. - احفظ لقطة لتعريفات الأدوات. احفظ مخرجات
tools/listوprompts/listلكل خادم وقارنها بشكل دوري، بما في ذلك بعد عدة استدعاءات في الجلسة نفسها، لأن Deadbugz لم يتغير إلا بعد الاستدعاء الثالث. أي اختلاف في وصف ما يجب أن يقرأه إنسان. - عامل الخوادم البعيدة كأطراف ثالثة. لا تتصل إلا بما يديره مزوّد كنت ستعطيه البيانات نفسها مباشرة، وتحقق من الصلاحيات الفعلية للرمز المميز (token) الذي يحصل عليه.
- أبعد الأسرار عن متناوله. شغّل الوكلاء بمستخدم لا يستطيع قراءة
~/.sshولا ملفات بيانات اعتماد السحابة ولا ملفات kubeconfig الخاصة بالإنتاج. إذا احتاج وكيل إلى متصفح مسجّل الدخول، فأعطه ملف تعريف منفصلًا لا يضم إلا الحسابات التي تحتاجها تلك المهمة. - احصر الخوادم في مشاريعها. خادم قاعدة بيانات يحتاجه مشروع واحد لا ينبغي تحميله في كل جلسة على الجهاز.
- قيّد الحركة الصادرة حيثما أمكن. وكيل خروج (egress proxy) بقائمة سماح يحوّل التسريب الصامت إلى طلب محجوب تراه في السجل.
- افحص المؤشرات المنشورة. تذكر Pillar نقطة النهاية البعيدة
productivity-suite-mcp.onrender.comوملفًا محليًا مخفيًا في~/.config/.cache/.sys/.deadbug-mcp.py. أمرgrepسريع على ملفات إعداد MCP وأمرfindلذلك المسار يستغرقان ثواني.
في الجولة الأولى، سطر واحد يكشف عمليات التشغيل غير المثبّتة في إعدادات Claude Code: grep -nE '@latest|"npx"|git\+https' ~/.claude.json .mcp.json. سيظهر بعض المدخلات الآمنة أيضًا، ولا بأس بذلك، فالهدف أن تنظر في كل واحد منها.
القاعدة نفسها تنطبق على ميزات الذكاء الاصطناعي التي تبنيها
Deadbugz قصة سلسلة توريد، لكن الدرس الكامن تحتها أقدم: كل ما يصل إلى سياق النموذج قد يعمل كتعليمات، لذا يجب ألا يملك النموذج صلاحيات أكثر من الشخص الذي يعمل لأجله. لهذا نصمم المساعدات الداخلية لتقرأ وتستشهد بالمصادر بدل أن تتصرف، ولهذا مكان فحوص الوصول هو طبقة الاسترجاع لا نص التوجيه. تناولنا جانب الوصول في حصر المساعد الداخلي بصلاحيات الشخص الذي يسأل، وجانب الموافقات في حوكمة الذكاء الاصطناعي الوكيل في مكتب الدعم.
في FanMind، مساعد المستندات لدينا، يمر كل اتصال صادر عبر نفق واحد بقائمة سماح، والبحث على الويب محصور في نطاقات يعتمدها المسؤول، والمستندات السرية مستبعدة من فهرسة الذكاء الاصطناعي افتراضيًا. لا شيء من ذلك يجعل حقن التوجيهات (prompt injection) مستحيلًا، لكنه يحدّ مما يمكن أن يصل إليه حقن ناجح، وبعد مراجعة كمراجعتنا هذا هو السؤال الأهم.
إذا لم تفعل هذا الأسبوع إلا شيئًا واحدًا، فافتح إعدادات MCP لديك واقرأ كل أمر فيها. إعداداتنا كشفت أربع مشكلات لم نكن قد فكرنا فيها.
تقييد الأدوات هو نصف البرمجة الآمنة بمساعدة الذكاء الاصطناعي؛ أما النصف الآخر فهو التحكم في ما يراه النموذج، وقد تناولناه في هندسة السياق باستخدام إطار RPI.
وكلاء الذكاء الاصطناعي صاروا في صف المهاجمين أيضًا. يقول DIVD إن وكيلًا ربط ثغرتين في Zammad ليصل إلى root عبر مكتب الدعم؛ اطّلع على اختراق DIVD وسبعة فحوص لأي مكتب دعم مستضاف ذاتيًا.
