Deadbugz: خادم MCP يتحوّل إلى عدائي عند استدعاء الأداة الثالث، وتم دفعه إلى 23 مستودعًا خلال 74 دقيقة
- OrcaجديدOrcaCyber: MiniMax M3.1 Flash Abliterated2026-10-29orca/orcacyber-minimax-m3.1-flash
- OrcaجديدOrcaCyber: GLM 5.3 Flash Abliterated2026-10-2793 tok/s
- OrcaجديدOrcaCyber: Qwen3.8 Flash Next Abliterated2026-10-26$0.80 / $1.60 لكل مليون رمز · 260 tok/s
- OrcaجديدOrcaCyber: MiMo V2.6 Flash Abliterated2026-10-26$0.80 / $1.60 لكل مليون رمز · 92 tok/s
- MoonshotجديدMoonshotAI: Kimi K3.1 Pro2026-10-2446الذكاء
- OrcaجديدOrcaCyber: DeepSeek V4.1 Flash Abliterated2026-10-23$0.80 / $1.60 لكل مليون رمز · 104 tok/s
- minimaxجديدMiniMax: M3.1 Flash2026-10-1929الذكاء
- OrcaجديدOrca: OrcaCyber Ultra 1.02026-10-17$5.00 / $10.00 لكل مليون رمز · 65 tok/s
- deepseekجديدDeepSeek: DeepSeek V4.1 Flash 10172026-10-1733الذكاء
- DeepSeekجديدDeepSeek: DeepSeek V4.1 Flash2026-10-1740الذكاء
- OrcaOrca: OrcaCyber Zero 1.52026-10-10$3.00 / $7.50 لكل مليون رمز · 101 tok/s
- openaiOpenAI: GPT-6.1 Sol2026-09-2955الذكاء
- anthropicAnthropic: Claude Sonnet 5.52026-09-2854الذكاء
- typesafeTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 لكل مليون رمز · 180 tok/s
- OpenAIOpenAI: GPT-6 Luna2026-09-2228الذكاء
- OpenAIOpenAI: GPT-6 Sol2026-09-2248الذكاء
- AnthropicAnthropic: Claude Opus 5.52026-09-2258الذكاء
- xiaomiXiaomi: MiMo-V2.6-Flash2026-09-2127الذكاء
- xiaomiXiaomi: MiMo-V2.6-Pro2026-09-2130الذكاء
- xAIGrok 4.72026-09-2134الذكاء
في 10 أغسطس 2026، فتح حساب GitHub واحد، zellkernel، 23 طلب سحب خلال 74 دقيقة ضد مستودعات غير ذات صلة للذكاء الاصطناعي وMCP وأدوات المطورين، كل منها يضيف خادم MCP باسم productivity-suite كان يعلن عن أداتين عاديتين، format_text وsummarize. وفقًا لـ Pillar Security، التي أطلقت على الحملة اسم Deadbugz ونشرت تقريرها في 12 أغسطس، أعاد الخادم نتائج صادقة في أول ثلاث استدعاءات ثم أعاد كتابة البيانات الوصفية التي سلّمها للوكيل: بدأت أوصاف الأدوات ومحتوى التوجيهات توجّه النموذج نحو مفاتيح SSH، بيانات اعتماد AWS، وسجل أوامر shell وإعدادات Kubernetes، وتطلب منه إخفاء ذلك النشاط عن المستخدم. أُغلقت تسعة عشر من طلبات السحب الـ23، وبقي أربعة مفتوحة ولم يُدمج أي منها عندما راجعتها Pillar. لم يتم تأكيد وجود أي ضحية. هذا سجل واحد، أبلغ عنه آخرون ويُستشهد به هنا بالرجوع إليهم. أما حوادث الوكلاء الموثقة الأخرى، ولكل منها مصادرها ودرجة خطورتها ودرجة ثقتها وعلامة النزاع، فتقع في أرشيف حوادث الذكاء الاصطناعي — لذا يمكن قراءة حملة سلسلة توريد تستهدف أدوات الوكلاء إلى جانب بقية ما حدث فعلًا.
يصنّف الأرشيف هذا السجل بدرجة خطورة عالية وثقة A — موثّق جيدًا، مع مصادر أولية متوافقة — بينما يسجّل بشكل منفصل عدم وجود ضرر حقيقي مؤكد. كلا الأمرين صحيحان في الوقت نفسه، والفجوة بينهما هي موضوع السجل: حملة وُثّق تصميمها بتفصيل غير معتاد قبل أن تُسفر عن ضحية يمكن لأي شخص تسميتها. التاريخان المهمان يفصل بينهما يومان. صدرت طلبات السحب في 10 أغسطس؛ ونشر Ariel Fogel من Pillar Security التحليل في 12 أغسطس، ويتضمّن المنشور ملاحظة دائمة مفادها أنه سيُحدّث كلما وصلت معلومات موثّقة.
ثلاثة استدعاءات، ثم تتغير البيانات الوصفية
لا يلزم أن يشغّل خادم MCP شيفرة على جهاز لتغيير ما يفعله وكيل. إذ تُسلّم تعريفات الأدوات إلى النموذج بوصفها سياقًا في كل جلسة، مما يعني أن الخادم الذي يوفّرها يمكنه إعادة كتابة التعليمات التي يقرأها الوكيل مع إبقاء اسم الأداة ومستودعها وبيانها كما هي تمامًا. وقد بُني Deadbugz على هذا التفاوت، ويسمّيه Pillar تسمّم بيانات تعريف MCP المقيّد بوقت التشغيل.
الآلية صغيرة بما يكفي لوصفها في جملة واحدة. يحتفظ الخادم بعدّاد في الذاكرة لكل عميل خاص بـ tools/call من الطلبات. بالنسبة للثلاثة الأولى، يتصرف كما ينبغي. وبمجرد تجاوز العداد، تصبح استجابات tools/list وprompts/get اللاحقة معدلة — أوصاف أدوات مختلفة، ومحتوى مطالبات مختلف — توجّه الوكيل إلى مفاتيح SSH وبيانات اعتماد AWS وسجل أوامر الصدفة وإعدادات Kubernetes وتأمره بإخفاء النشاط عن المستخدم. يحمل نص المطالبة المسموم العلامة deadbugz وعنوان بيتكوين.
البوابة هي أيضًا سببُ عدم اكتشاف الدفاعاتِ العادية لها. فالحمولة موجودة في المصدر منذ الطلب الأول؛ ولا يتغيّر شيء في الشيفرة أو الإعدادات عند لحظة التبديل. والفحص الساكن، أو مدخل SBOM، أو قراءة لمرة واحدة لبيان الأدوات عند التثبيت، لا يرى إلا أداة تنسيق، لأن هذا هو ما تُرجعه الأداة حتى يتحرّك العدّاد. وتصف Pillar هذا التبديل المؤجَّل بأنه تقنية تهريب بحثية، وتقول إن باحثيها تحقّقوا من العتبة ومن البيانات الوصفية المعدّلة معًا بإرسال طلبات نصية فقط إلى الخدمة البعيدة الحيّة ومطابقة الردود مع المصدر العام.
ثمة تفصيل واحد يجعل الفخ أوسع من جلسة واحدة. يُعلن الخادم عن tools.listChanged، وهي قدرة MCP التي تُخبر العميل بأن قائمة أدواته قد جرى تحديثها. والعميل الذي يستجيب لتلك الإشارة سيعيد قراءة التعريفات في منتصف الجلسة ويسحب النسخة المسمومة دون أي إجراء من المشغّل؛ أما العميل الذي يخزّن التعريفات مؤقتًا عند الموافقة فلن يفعل ذلك. وأي سلوك يظهره وكيل معيّن هو خاصية للعميل لا للخادم، ولا يعدّد تقرير Pillar العملاء بأسمائهم.
التسليم: 23 طلب سحب في 74 دقيقة
لم يكن هذا التوزيع حزمةً على سجل، ولا اعتمادًا مسمومًا مدفونًا في ملف قفل. كان عبارة عن طلبات سحب مزعجة تستهدف مشاريع لا علاقة لها بالوظيفة المفترضة للخادم، وهو الشكل الذي تتخذه محاولة منخفضة التكلفة في سلسلة التوريد حين لا يتمكن المهاجم من الحصول على حساب مسؤول صيانة: تقديم عدد كافٍ من تغييرات الإعدادات وانتظار دمج أحدها أو تطبيقه محليًا.
تفصيل Pillar للـ23 ثلاثي الأوجه. سبعة عشر منها تضيف نقطة نهاية MCP بعيدة، productivity-suite-mcp[.]onrender[.]com/mcp، مستضافة على Render؛ وأربعة تستدعي ملف Python محليًا مخفيًا في ~/.config/.cache/.sys/.deadbug-mcp.py؛ واثنان منها مُدخَلان إلى دليل أو قائمة، ويتعامل معهما التقرير باعتبارهما استطلاعًا أو حشوًا لا تسليمًا. تُعطى النافذة الزمنية على أنها من 9:52 مساءً إلى 11:07 مساءً بتوقيت UTC يوم 10 أغسطس 2026 — 74 دقيقة في صياغة الإفصاح، رغم أن الطابعين الزمنيين نفسيهما يمتدان 75، ولا شيء في السجل يتوقف على تلك الدقيقة. لا يُذكر بالاسم سوى مستودع هدف واحد: getsentry/sentry-mcp، طلب السحب #1239، مُستشهَدًا به كمثال على تسليم الأثر المحلي.
كان الحساب الذي يقف خلفه ذا ثقل كبير نسبيًا لعمره. عند جمع Pillar، كان لدى zellkernel 50 مستودعًا عامًا، 20 منها كانت نسخًا متفرعة، و21 من تلك الخمسين قد أُنشئت في 10 أغسطس، وهو اليوم نفسه الذي شُنت فيه الحملة. وكان الملف الشخصي مرتبطًا تبادليًا بحساب X @llmgod، الذي ارتبط بدوره بحساب GitHub، وهو نوع الربط التبادلي الذي يدل على هوية مبنية لغرض محدد بدلًا من هوية مخترقة.
تسعة عشر مغلقًا، وأربعة مفتوحة، وصفر مدمج هو الرقم الأكثر تكرارًا في السجل، وهو أيضًا الرقم الذي يُقرأ غالبًا على أنه إشارة أمان تامة، وهو ليس كذلك تمامًا. زر الدمج في GitHub ليس سجل تنفيذ للمضيف: إذ يمكن للمشرف سحب فرع وتشغيله، أو تطبيق إعداد يدويًا، أو يمكن لمهمة CI جلب رأس طلب سحب (PR) قبل أن يعلّق أي شخص. طلبات السحب الأربعة التي تكتب إعدادًا يستدعي مسار سكربت محلي هي التي تكون فيها هذه الفجوة أكثر أهمية، لأن السكربت يُجلب ويُشغّل خارج محاسبة الدمج في GitHub بالكامل. وقد قالت Cloud Security Alliance Labs النقطة نفسها في ملاحظتها بتاريخ 2 سبتمبر: لا يُثبت عدّا المغلق وغير المدمج أن شيئًا لم يُشغَّل.
ما هو ثابت، وما هو غير ثابت
أُثبت ذلك بموجب الإفصاح، بمعنى أن Pillar يورده استنادًا إلى آثار قرأها، وفي حالة واحدة استنادًا إلى خدمة استعلمها: الخادم ومستودع مصدره، والأداتان المعلنتان، والعدّاد وعتبة الاستدعاءات الثلاثة، وأهداف بيانات الاعتماد الأربعة، وأعداد طلبات السحب (PR) وحالة دمجها وقت المراجعة، والصلة بين حساب GitHub ومعرّف X. ويُعدّ اختبار Pillar الخاص على نقطة النهاية الحيّة أقوى عنصر في القائمة، لأنه إعادة إنتاج لا مجرد قراءة للشيفرة المصدرية.
غير مُثبَت، والسجل يتحرّى الحذر في هذه المسألة: ضحية. فحقل real_harm في الأرشيف قيمته false، وهو تصريح عن الأدلة لا عن النية — إذ لم يُقدّم أحدٌ خادمًا ولا سجلًا ولا بيانات اعتماد مسروقة مرتبطة بهذه الحملة. كما أن الشخص أو الجماعة الواقفة خلف zellkernel و@llmgod لم تُحدَّد هويتها؛ وPillar ينسب العملية إلى الحسابات ويتوقف عند ذلك. والدافع المالي يستند إلى عنوان Bitcoin مُضمَّن في الحمولة، وهو استنتاج من مؤشر، لا نتيجة مؤكدة عن الفاعل. أما السؤال الذي يتوق المدافع إلى إجابة عنه — هل الحملة ما زالت جارية؟ — فلا جواب له في السجل: فقد وُسم المنشور بأنه سيُحدَّث، ولم يظهر أي تنقيح لاحق أو إشعار إزالة من GitHub أو Render.
التأييد أضعف مما قد يوحي به تصنيف الثقة، ويجدر قول ذلك صراحةً. هناك ملاحظتان بحثيتان من Cloud Security Alliance Labs، مؤرخان 30 أغسطس و2 سبتمبر 2026، يعيدان ذكر الحملة؛ واللاحقة منهما صريحة في أنها تنسب إلى Pillar الاكتشاف وتفاصيل العلاقات العامة وسلوك الخادم وإسناد الحساب، ولا تصف أي تحقق مستقل خاص بها. منشور مدونة Armorبتاريخ 22 سبتمبر 2026 يقدم إرشادات دفاعية ويقول إن Pillar فكك الخادم؛ ولا يقدم أي دليل جنائي خاص به. لم يُسند أي CVE، وتقول CSA إن هذه ليست ثغرة في مواصفات MCP. وحتى 29 أكتوبر 2026، لا تُظهر عمليات البحث أي تحذير من GitHub أو Render، ولا أي تغطية في الصحافة الأمنية المتخصصة السائدة — لا خبر من BleepingComputer أو The Register أو SecurityWeek أو Hackread — وهو أمر غير معتاد لحملة سلسلة توريد بهذا الشكل، وهو في حد ذاته جزء مما يظهره السجل. "المصادر الأولية تتفق" تعني هنا مصدرًا أوليًا منشئًا واحدًا ومجموعة من الوثائق الثانوية المستمدة منه.
هناك غموضان أصغر جديران بالإشارة إليهما بدلًا من التغاضي عنهما. تختلف الملخصات الثانوية حول ما إذا كان الاتصال الثالث أم الرابع هو أول اتصال يتلقى بيانات وصفية مسمومة، وهذا ناتج عن وصف العدّاد بأنه ينطلق عند الطلب الثالث؛ ويستخدم كلٌّ من السجل والإفصاح الرقم ثلاثة. كما تُوصَف نافذة التسليم بأنها 74 دقيقة لطوابع زمنية تمتد على 75.
فحص واحد تعذّر تكراره: في 29 أكتوبر 2026، حساب GitHub zellkernel والمستودع zellkernel/productivity-suite-mcp ويعيدان كليهما 404، وطلب السحب الوحيد المذكور بالاسم تحديدًا، getsentry/sentry-mcp #1239، لم يعد يُحلّ أيضًا — المستودع نفسه الآن يعيد التوجيه إلى getsentry/toolkit. لذلك لا يمكن اليوم إعادة التحقق من أعداد طلبات السحب وحالة الدمج ومحتويات المستودع من طرف أول؛ وهي تبقى بمنزلة لقطة Pillar، المأخوذة في منتصف أغسطس.
ما الذي يطلب الإفصاح من المدافعين فعله
تتمحور الاستجابة التي توصي بها Pillar في الغالب حول التعامل مع البيانات الوصفية كسطح أمني لا كوصف له. وبالنسبة للمضيفين، فإن المطالب المحددة هي حظر أو تعقّب productivity-suite-mcp[.]onrender[.]com/mcp، وإبقاء نقطة النهاية trycloudflare.com الأسبق للحملة في قوائم الحظر والتعقّب رغم أن Pillar تقول إنها ليست نشطة حالياً، وعدم تشغيل deadbug-mcp.py — مسار الملف المخفي ~/.config/.cache/.sys/.deadbug-mcp.py هو الأثر الذي يجب البحث عنه عبر الدلائل الرئيسية والمستودعات وتكوينات عملاء MCP.
ترتيب التحقيق أهم من قائمة الحظر. إذا كان من المحتمل أن يكون أحد المضيفين قد اتصل، يقول Pillar إنه يجب الحفاظ على سجلات عميل MCP قبل تنظيف أي شيء، ثم مراجعة تحديثات تعريف الأدوات وما فعله الوكيل بعد الاستدعاء الثالث؛ ولا ينبغي تدوير بيانات الاعتماد إلا حيث تدعم الأدلة المحلية وجود تعرض، وهو عكس رد الفعل التلقائي بتدوير كل شيء عند الشك. كما سمح إعداد الخادم بإرسال بيانات تليمتري اختيارية إلى WEBHOOK_URL، وإرسال إشارات عند الاتصال والاستدعاء الأول وحدث التشغيل — وهو تفصيل يمنح التحقيق مكانًا ثالثًا للنظر فيه إلى ما هو أبعد من سجلات العميل وحركة مرور نقاط النهاية.
بالنسبة لمن يبنون عملاء MCP، فإن التوصية هيكلية، وهي الجزء الأطول عمرًا من السجل:
• سجّل بصمة تعريفات الأدوات وقت الموافقة وقارنها عند كل تحديث، بدلًا من الوثوق باسم الخادم ومستودعه.
تعامل مع أي تغيير في التعريف على خادم سبق اعتماده بوصفه حدثًا أمنيًا يراه المشغّل ويعيد الموافقة عليه، لا بوصفه تغييرًا روتينيًا في البيانات الوصفية يُبتلع بصمت.
• نفّذ العمليات الحساسة — الوصول إلى بيانات الاعتماد، وتنفيذ التعليمات البرمجية، والبريد الإلكتروني الصادر، والكتابة في المستودع — عبر السياسة لا عبر الأوصاف التي يوفّرها الخادم.
هذا البند الثالث هو ما يجعل Deadbugz سجلًا لا مجرد فضول. تفترض كل ضوابط التحكم أعلاه أن الوكيل يمكن إقناعه بأمور عبر النص الذي يربطه الخادم بأداة، وأن النص يمكن أن يتغير بعد اتخاذ قرار الثقة. يضع Pillar الحملة في سياق خط يشمل هجوم MCP sleeper attack لعام 2025 من Invariant Labs، وحزمة postmark-mcp المزيفة، وحزمة MCP موثّقة من Koi جرى تسليحها عبر تحديث — وكلها سوابق لهذه التقنية، يستشهد بها Pillar لهذا الغرض وليس كدليل بشأن هذا التسليم.
لماذا تهمّ البوابة أكثر من عدد الضحايا
حملة لها 23 محاولة تسليم، ولا دمج ولا ضحية مؤكدة، من السهل تصنيفها ضمن المحاولات وتجاوزها. السبب في أنها تستحق أن تُؤرشف بدرجة خطورة عالية هو أن تهربها لا يعتمد على نجاح التسليم على نطاق واسع. بل يعتمد على خاصية تتشاركها معظم عمليات نشر MCP اليوم: الموافقة تحدث مرة واحدة عند التثبيت، ويُفترض أن التعريف الذي تمت الموافقة عليه هو التعريف الذي سيُقدَّم. يحافظ Deadbugz على هذا الافتراض سليمًا خلال ثلاث استدعاءات ثم يكسره.
الإصلاح ليس تصحيحًا لخادم محدّد، ولا توجد ثغرة CVE لتتبّعها. المسألة أن تصبح «approved» حالة مستمرة تقف خلفها مقارنة — وهذا تغيير في كيفية تصرّف العملاء ومشغّليهم، لا تغيير في ما يبحث عنه الماسح الضوئي. ما زال غير معروف ما إذا كان أي شخص قد شغّل الخادم فعليًا في أغسطس؛ وبحسب ما هو مسجّل حتى الآن، فإن الآلية هي الاكتشاف.
