Pillar Security تصف Deadbugz، خادم MCP ينتظر ثلاثة استدعاءات للأدوات قبل البحث عن مفاتيح SSH

وصفت Pillar Security حملة Deadbugz، التي قدّم فيها حساب واحد على GitHub ‏23 طلب سحب (pull request) خلال 74 دقيقة في 10 أغسطس 2026، يضيف كل منها خادم MCP يتصرف بشكل طبيعي في البداية ثم يوجّه وكيل الذكاء الاصطناعي المتصل به إلى البحث عن بيانات الاعتماد ^[1]. وMCP، أي Model Context Protocol، هو المعيار الذي تستخدمه وكلاء ذكاء اصطناعي كثيرة لاستدعاء أدوات خارجية.

الخلفية

يخبر خادم MCP الوكيلَ بالأدوات التي يقدّمها وبما تفعله، ويقرأ الوكيل هذه الأوصاف بوصفها تعليمات. ولذلك يستطيع خادم يغيّر أوصافه بعد التثبيت أن يغيّر سلوك الوكيل دون تغيير الشيفرة التي اطّلع عليها المراجع ^[1].

ما يصفه التقرير

جاءت طلبات السحب من حساب عام باسم zellkernel، ووُجّهت إلى مشاريع غير مترابطة في مجال الذكاء الاصطناعي وأدوات المطوّرين بين الساعة 9:52 مساءً و11:07 مساءً بتوقيت UTC. أعدّ سبعة عشر منها نقطة نهاية MCP بعيدة، وأشارت أربعة إلى سكربت Python محلي مخفي، وكان اثنان طلبَي إدراج في أدلة. وأُغلق تسعة عشر منها وبقيت أربعة مفتوحة حين راجعتها Pillar، ولم يُدمج أي منها عبر آلية الدمج في GitHub ‏^[1].

يقدّم الخادم، المسمّى productivity-suite، خدمات تنسيق النصوص وتلخيصها. وبعد أن يجري العميل المتصل ثلاثة استدعاءات للأدوات، يعيد كتابة أوصاف أدواته بحيث يُطلب من الوكيل البحث عن مفاتيح SSH وبيانات اعتماد AWS وسجل الصدفة وإعدادات Kubernetes مع إخفاء هذا النشاط عن المستخدم. وتقول Pillar إن نقطة النهاية البعيدة كانت لا تزال نشطة وقت تحليلها ^[1].

دلالات ذلك على مستخدمي Mac

الفئة المعرّضة هي المطوّرون الذين يضيفون خوادم MCP إلى إعدادات الوكيل، أو يقبلون طلبات سحب تفعل ذلك. ولا تورد Pillar أي دمج، فالحملة كما وُصفت لم تنجح عبر GitHub وقت المراجعة. أما المطوّر الذي نسخ أحد الإعدادات يدويًا فيقع خارج هذا الإحصاء ^[1].

التوصيات

1. راجعوا أي طلب سحب يضيف مُدخلًا لخادم MCP أو يغيّره بالعناية نفسها التي تراجعون بها طلبًا يضيف شيفرة.
2. ابحثوا في الأجهزة والمستودعات عن نقطة النهاية ومسار السكربت اللذين تذكرهما Pillar، وتراجعوا عن التغييرات التي تُدخلهما.
3. فضّلوا عملاء MCP الذين ينبّهون حين يغيّر الخادم تعريفات أدواته بعد الموافقة عليه، كما توصي Pillar.
4. أبعدوا مفاتيح SSH وبيانات اعتماد الخدمات السحابية وسجل الصدفة عن متناول عمليات الوكلاء قدر الإمكان.

صلة ذلك بـ FireAI

لا يقرأ FireAI إعدادات MCP ولا التعليمات التي يتلقاها الوكيل، ولا يستطيع أن يطلب من الوكيل تجاهلها. أما في حالة خادم بعيد كالموصوف، فكل اتصال حدث شبكي: فأول اتصال من تطبيق بوجهة جديدة يطلق طلب إذن في وضع «تنبيه»، ويمكن لـقاعدة لكل تطبيق حظر ذلك المضيف. والخادم الذي يعمل محليًا ويكتفي بقراءة الملفات لا يولّد حركة شبكية يراها FireAI.

القيود

لا يُظهر نص التقرير الذي جرى الاطلاع عليه تاريخ نشر. ويستند الإسناد إلى الحساب العام، والجهة المشغّلة خلفه غير معروفة. ولا يذكر التقرير ما إذا كان أي وكيل قد نفّذ التعليمات المعادية فعلًا، ولا ما إذا سُرقت أي بيانات اعتماد ^[1].

جرّب FireAI من HisnLabs مجانًا لمدة 17 يومًا.