25 مدير حزم أمام مستودع مخترَق: لماذا لا يكفيك ملف القفل وحده؟

في 15 أكتوبر 2026 نُشرت ثغرة بتقييم حرج في أحد أطر عمل وكلاء البرمجة المفتوحة المصدر، هو Archon، وحملت المعرّف CVE-2026-111322 وتقييم CVSS 3.1 بقيمة 9.8. الخلل ليس معقداً ولا يحتاج إلى استغلال ذكي: واجهة التحكم في الوكيل تعمل افتراضياً دون أي تسجيل دخول، وتستمع على كل واجهات الشبكة. وهذا النمط، أي أدوات وكلاء تُشحن بإعدادات مريحة للمطوّر وخطرة على الشبكة، يستحق وقفة، لأنه قد يكون موجوداً عند أدوات أخرى تشغّلها على جهازك الآن.

ما الذي حدث بالضبط؟

تؤثر الثغرة في إصدارات Archon من 0.2.13 حتى 0.11.1. الواجهة البرمجية /api/* تعمل بشكل افتراضي على العنوان 0.0.0.0 أي أنها تقبل اتصالات من أي جهاز يصل إلى المنفذ. والإعداد الافتراضي يستخدم قاعدة SQLite دون ضبط أي سر، وفي هذه الحالة تسمح طبقة المصادقة في الكود بمرور الطلبات كما هي.

النتيجة بحسب التقارير المنشورة أن أي جهاز على الشبكة نفسها يستطيع:

• بدء تشغيلات سير العمل وإنشاء محادثات جديدة.
• حقن رسائل يعاملها الوكيل كأنها تعليمات من المشغّل.
• الموافقة على إجراءات الوكيل المتوقفة أو رفضها.

ولأن الوكيل يعمل بمستوى صلاحيات bypassPermissions، تربط نشرة VulnCheck بين هذا وبين تنفيذ أوامر على المضيف بصلاحيات مستخدم Archon. ويشير بعض الكتّاب إلى أن نطاق التأثير الدقيق ما زال محل نقاش، فبعضهم يصف إجراءات على مستوى الواجهة فقط. لكن حتى هذا الوصف الأخفّ يعني أن شخصاً غريباً يوجّه وكيلاً يملك صلاحية الكتابة على مشروعك.

لماذا تقييم 9.8 منطقي هنا؟

المتجه المعلن هو AV:N/AC:L/PR:N/UI:N، أي هجوم عبر الشبكة، بتعقيد منخفض، دون صلاحيات ودون تفاعل من المستخدم، مع أثر عالٍ على السرية والسلامة والتوفر. أما CVSS 4.0 فيعطيها 9.3، والضعف مصنّف CWE-306 أي غياب المصادقة لوظيفة حرجة.

المشكلة هنا ليست ثغرة برمجية غامضة، بل قرار تصميمي: الأداة افترضت أن الشبكة آمنة، وأن من يصل إلى المنفذ هو المطوّر نفسه.

حالة الإصلاح

عند كتابة هذا المقال لا تتفق المصادر. أحد الأدلة يذكر أنه لا يوجد إصدار مصحَّح حتى 16 أكتوبر، ومصدر آخر يلمّح إلى إصلاحات سريعة لكن بصياغة أقل تحديداً وتعارض الباقي. لذلك الأسلم ألا تنتظر الترقيع، وأن تتحقق من صفحة الإصدارات الرسمية للمشروع، وأن تطبّق التخفيف اليدوي الآن. كما أن تحليل NVD ما زال قيد الانتظار، وسجل CVE نفسه لا يحمل الرقم 9.8 مباشرة بل السجلات المنسوخة عنه.

كيف تتحقق من تعرّضك خلال دقيقتين؟

الفحص لا يخص Archon وحده، بل كل أداة وكيل أو خادم MCP محلي تشغّله:

1. شغّل ss -tlnp وابحث عن أي عملية تستمع على 0.0.0.0 أو * بدل 127.0.0.1.
2. من جهاز آخر على الشبكة، جرّب الوصول إلى المنفذ نفسه (في Archon هو 3090). إن أجاب دون بيانات اعتماد فأنت مكشوف.
3. تحقق من جدار الحماية على جهازك، خاصة على شبكات المقاهي والمكاتب المشتركة.
4. راجع إن كانت الأداة تعمل داخل حاوية تنشر المنفذ على كل الواجهات (-p 3090:3090 بدل 127.0.0.1:3090:3090).

خطوات التخفيف

دروس لمن يبني أدوات الوكلاء

الحادثة تذكير بقواعد قديمة تُنسى عندما تتسارع الأدوات: الإعداد الافتراضي يجب أن يكون الأكثر أماناً لا الأسهل. اربط الخدمات المحلية بـ loopback، واجعل المصادقة إلزامية حتى في وضع التطوير، وأخرج أي أداة تملك صلاحية تنفيذ أوامر من نطاق الثقة الضمني. وإن كنت تعتمد أطراً مفتوحة المصدر في فريقك، فأضف فحص المنافذ المفتوحة إلى قائمة مراجعة الإعداد الأولي.

أسئلة شائعة

هل أنا معرّض إن كنت أشغّل Archon على لابتوبي فقط؟

نعم إن كان الخادم يستمع على كل الواجهات واللابتوب موصول بشبكة يصل إليها آخرون. الربط بـ 127.0.0.1 يغلق هذا المسار.

هل تكفي المصادقة وحدها؟

هي خطوة أساسية، لكن الأفضل جمعها مع الربط المحلي وعزل الوكيل، لأن الدفاع المتعدد الطبقات يحدّ الضرر إن فشلت إحداها.

هل المشكلة خاصة بـ Archon وحده؟

لا. أي أداة وكيل أو خادم MCP يعمل بصلاحيات واسعة ويستمع على الشبكة دون مصادقة يحمل المخاطر نفسها، لذلك يفيد فحص المنافذ لكل ما تشغّله.

الخلاصة

ثغرة Archon ليست استثنائية تقنياً، وهذا ما يجعلها مهمة: وكيل برمجي بصلاحيات واسعة، وواجهة بلا مصادقة، وعنوان استماع مفتوح. افحص منافذك اليوم، واربط الخدمات المحلية بالحلقة المحلية، وفعّل المصادقة، وتابع الإصدارات الرسمية للمشروع بدل الاعتماد على الشائعات حول الترقيعات.

المصادر: DEV Community، Strix، The Hacker Wire، Stackademic