MaxKB أرفقت أداة Shell بكل مساعد ممكّن بالأدوات ولم تقيّد الوصول إليها مطلقًا

MaxKB، منصة مساعد مؤسسي مفتوحة المصدر منشورة تحت منظمة GitHub 1Panel-dev، بنت وكلاء الدردشة لديها على إطار عمل يضيف بصمت أداة shell كلما تم تمرير واجهة خلفية قادرة على shell — ولم تقم MaxKB قط بإزالة الأداة أو تطلب من أي شخص الموافقة على استخدامها. الثغرة هي CVE-2026-77521، نُشرت كتنبيه GitHub الأمني GHSA-f36j-f34j-h3rx في 2 سبتمبر 2026 وحصلت على 10.0 من 10 بموجب CVSS 3.1 في حالة مساعد عام أو مضمّن. Lasso Security، التي اكتشفتها وأبلغت عنها، أثبتت أن رسالة دردشة — أو نصًا يستهلكه المساعد فقط عبر الاسترجاع أو مستند مرفوع — يمكن أن تدفع النموذج إلى تنفيذ أوامر: في نشر bare-metal مباشرة على المضيف، وفي الحاوية الرسمية عبر غلاف يقول الباحثون إنه قابل للتجاوز بفاصلة منقوطة. لا يسجّل أي مصدر مُستشهد به استغلال الثغرة في البرية. يقع تصنيف الخطورة الخاص بالسجل وتقييم الثقة وقائمة المصادر في أرشيف حوادث الذكاء الاصطناعي، إلى جانب إدخالات MaxKB وأدوات الوكلاء المجاورة من دفعة الإفصاح نفسها.

MaxKB منتج ذاتي الاستضافة لبناء مساعدين معززين بالاسترجاع: ينشئ المشغّل مساعدًا، ويربط به قدرات — أدوات، وخوادم Model Context Protocol، ومهارات، وتطبيقات فرعية — ثم يوصِل قاعدة معرفة مبنية من مستندات مرفوعة أو مواقع ويب تم الزحف إليها، وبعد ذلك يعرض المساعد إما عبر واجهة تحكم موثّقة أو كأداة دردشة عامة قابلة للتضمين. هذا التنوع هو موطن التعرض. وشرط التفعيل في التنبيه الأمني ليس إعدادًا غير معتاد بل الإعداد العادي: أي مساعد مرتبط بقدرة واحدة على الأقل يمرر دردشته عبر مسار الوكيل المتأثر، بينما الدردشة التي لا قدرات مرتبطة بها لا تفعل ذلك. ويصف تقرير Lasso المشروع بوصفه واحدًا من أكثر المشاريع اعتمادًا في فئته، ويشير إلى أن MaxKB يُنشر عادةً كخدمة متعددة المستأجرين — ما يضع أمرًا يُنفَّذ بهوية مستخدم التطبيق تحت نموذج تعدد المستأجرين بدلاً من داخل شريحة مستأجر واحد منه.

وصلت أداة الطرفية مع إطار العمل، لا مع المنتج.

يبني MaxKB هؤلاء الوكلاء باستخدام مكتبة deepagents التابعة لـ LangChain، المثبّتة على الإصدار 0.6.11 في pyproject.toml الخاص بالمشروع عند كل من الوسم المعرّض للثغرة والوسم الحالي. في apps/application/flow/tools.py، عند السطر 467 من وسم v2.10.3-lts، يستدعي المشروع create_deep_agent مع ضبط backend على SandboxShellBackend، وهي فئة فرعية من MaxKB تشغّل الأوامر على المضيف. وفقًا للتنبيه الأمني، يحقن deepagents تلقائيًا مجموعة من الأدوات كلما مُرِّر backend من نوع shell بهذه الطريقة: execute وls وread_file وwrite_file وedit_file وglob وgrep. وهي ليست جزءًا من وسيط tools=list، الذي لا يحمل سوى أدوات المشغّل الخاصة وأدوات MCP وأدوات المهارات. لا يمكن إزالتها من الواجهة أو عبر التهيئة.

كما لا يمرّر MaxKB الوسيطة excluded_tools، وهي وسيطة المكتبة التي كانت ستزيلها. ويحرص التنبيه على توضيح سبب أهمية ذلك حتى بوصفه علاجًا: فـ excluded_tools «تزيل الأداة مما يُبلَّغ به النموذج، لا من المنفّذ». إن التمييز بين أداة لا يعيها النموذج وأداة لا يمكن تشغيلها هو جوهر هذا الخلل بأكمله في صورة مصغرة.

بوابة تذكر ثلاث أدوات وتغفل الرابعة

التحكم القائم على وجود الإنسان في الحلقة في ذلك الاستدعاء نفسه يتكوّن من سطر واحد، وهو يعدّد ثلاث عمليات: interrupt_on={"write_file": False, "read_file": False, "edit_file": False}. فكتابة ملف وقراءة ملف وتحرير ملف مذكورة بالاسم. أما تنفيذ الأوامر فليس مفتاحًا في القاموس على الإطلاق. وفي قراءة التنبيه، يعني ذلك أنه لا تُطلب أي موافقة على التنفيذ — فعمليات نظام الملفات الثلاث مذكورة بالاسم ومضبوطة صراحةً على عدم الاعتراض، وأداة الصدفة غير مذكورة على الإطلاق.

عند جمعها معًا، يصبح المسار كالتالي: نص غير موثوق يصل إلى النموذج، فيستدعي النموذج execute، فتُنفَّذ الأوامر. ويسمّي التنبيه طريقتين لوصول النص غير الموثوق. الطريقة المباشرة هي الدردشة — سواء عبر ودجت عام أو مضمّن، أو عبر محادثة مستأجر آخر. أما الطريقة غير المباشرة فهي المحتوى الذي يستوعبه المساعد: مستند RAG، أو ملف مرفوع، أو صفحة ويب يزحف إليها النظام الأساسي ضمن قاعدة معرفة. ويجسّد منشور Lasso المسار الثاني بشكل ملموس، إذ يلاحظ أن "مجموعة الأشخاص القادرين على وضع نص أمام النموذج أكبر من مجموعة الأشخاص القادرين على الدردشة معه".

في التثبيت على عتاد فعلي، يكون الأمر مجرد أمر.

أيًا كان ما يفعله MaxKB بشأن الاحتواء، فإنه يحدث في apps/application/flow/backend/sandbox_shell.py، وفي v2.10.3-lts يبدأ بإعداد افتراضي. يقرأ السطر 9 العبارة _enable_sandbox = bool(int(CONFIG.get("SANDBOX", 0)))، ولا يظهر SANDBOX في Config.defaults ضمن apps/maxkb/conf.py. وفي غياب إعداد MAXKB_SANDBOX صريح، تكون القيمة صفرًا، ويُتخطّى فرع الغلاف عند السطر 65، ويصل execute إلى subprocess.run مع shell=True مباشرةً على المضيف، بصلاحيات المستخدم الذي يشغّل الخدمة — root، وفق صياغة التنبيه الأمني، إذا كانت الخدمة تعمل بصلاحيات root.

هذا هو التكوين الذي استخدمه الباحثون لإثبات المفهوم الخاص بالمضيف. شغّلوا شيفرة MaxKB الحقيقية من المصدر دون تعيين MAXKB_SANDBOX، وأنشأوا مساعدًا مرتبطًا به أداة واحدة، وطلبوا منه في رسالة دردشة واحدة تشغيل أوامر معلومات النظام. انطلقت أداة التنفيذ وكتبت ملفًا كانت محتوياته مخرجات uname وid وsw_vers الخاصة بالمضيف نفسه — وهي مخرجات تشير الملاحظة الأمنية إلى التأكد من غيابها داخل أي حاوية. كما يسجّل Lasso حدود ما أوقفه: فقد رفض النموذج ملف إثبات واضح التسمية، بينما لم يرفض الصياغة التشغيلية الحميدة. وتصفان محاذاة النموذج بأنها "مطب جزئي، وليس ضابطًا".

على الصورة الرسمية، عملت البيئة المعزولة ومع ذلك حدث تسرّب.

تضبط الحاوية الرسمية MAXKB_SANDBOX=1 في الصورة الأساسية، في السطر 48 من installer/Dockerfile-base، لذا يكون الغلاف نشطًا هناك — والغلاف هو العيب الثاني. بنى سلسلة واحدة: env -i LD_PRELOAD=/opt/maxkb-app/sandbox/lib/sandbox.so متبوعًا بـ gosu sandbox ثم الأمر المقدَّم من النموذج، وتُسلَّم إلى صدفة تعمل بصلاحيات الجذر. ولأن الأمر كان يُدرَج كنص، لم يكن يقع تحت gosu سوى أول رمز منه. أي فاصلة منقوطة أو أنبوب أو إعادة توجيه أو استبدال أوامر في مخرجات النموذج كان يُقيَّم بواسطة صدفة الجذر الخارجية قبل أن تراه بيئة العزل أصلًا.

يقدّم تقرير Lasso الشكل العملي لذلك: حمولة من النوع `env -i LD_PRELOAD=... PATH="$PATH" gosu sandbox ls; whoami; id`، حيث يكون `ls` محصورًا، و`whoami` ليس كذلك، وكل ما يأتي بعده يعمل بحرية. أثناء الاختبار، كتب الباحثون ملفًا مملوكًا لـ root عبر إعادة توجيه، بينما كان الأمر الداخلي المحصور داخل البيئة العازلة محظورًا. ومما يزيد الأمر سوءًا أن كلاً من installer/Dockerfile و installer/Dockerfile-base لا يحتوي على توجيه USER، لذا تعمل صورة التطبيق بمعرّف UID 0 — ويشير التقرير الاستشاري إلى تأكيد صلاحيات root وقت التشغيل. وبالتالي نفّذت الحاوية الأوامر بغض النظر عن ذلك، ولم تكن البيئة العازلة تقرر سوى أي الأوامر تُنسب شكليًا إلى المستخدم منخفض الصلاحيات.

إن تدفق الهجوم الكامل الذي يصفه Lasso لا يحتاج إلى أي وصول إلى الهدف على الإطلاق. يضع المهاجم أوامر على صفحة ويب، وينتظر أن يزحف وكيل الضحية بها إلى قاعدة معرفة، ثم يطرح الضحية سؤالاً عادياً. تعود الإجابة صحيحة ومشروعة؛ وقد انطلق أمر curl المحقون بالفعل نحو خادم المهاجم. تشير الاستشارة إلى أن الباحثين اختبروا عمليات النشر الخاصة بهم فقط، وليس أي نسخة MaxKB تابعة لطرف ثالث أو مستضافة.

ما تثبته المصادر، وما لا يُقاس ببساطة

تتفق أربع وثائق على الآلية ووضعي النشر والفضل والإصدار المُصلَح: النشرة الاستشارية من GitHub، وسجل NVD المنشور في 21 سبتمبر 2026، والمقال التقني الخاص بـ Lasso بتاريخ 10 سبتمبر 2026، وتقرير GBHackers المؤرخ 22 سبتمبر 2026، وهو التغطية الوحيدة من وسيلة إعلامية مستقلة وُجدت لهذه الثغرة CVE. ولا يعارض أي مصدر أي جزء من النتيجة، ويسجّل الأرشيف هذا المُدخل بوصفه غير متنازع عليه وبأعلى درجة ثقة.

ما لا تحتويه المصادر هو أي مقياس للتعرّض. فلا يوجد عدد لحالات نشر MaxKB، ولا عدد للمساعدات المتاحة عبر الإنترنت أو المضمّنة، ولا نتيجة فحص، ولا بيانات تليمترية، ولا ضحية محددة بالاسم. ولا يُظهر أي شيء في السجل استخدام هذه الثغرة ضد أي شخص، ويتفق تقييم الاستغلال الخاص بـ CISA نفسه على ذلك: فكتلة SSVC المرفقة بسجل NVD في 22 سبتمبر 2026 تصنّف الاستغلال بأنه "poc"، وإمكانية الأتمتة بأنها "yes"، والأثر التقني بأنه "total". وقد قدّر نموذج EPSS التابع لـ FIRST احتمال الاستغلال خلال الـ30 يومًا القادمة بنسبة 1.05 بالمئة، وهو المئين 64، في 27 أكتوبر 2026، ولا تظهر الثغرة CVE في كتالوج CISA Known Exploited Vulnerabilities المؤرخ 27 أكتوبر 2026. وتعكس درجة الأرشيف نفسه الدليل ذاته: الخطورة عالية، والضرر الفعلي: لا.

تستحق 10.0 أن يُوضَّح نطاقها، لأنها الرقم الأكثر عرضة للاقتباس خارج سياقه. فهي الدرجة الخاصة بحالة المساعد العام أو المضمَّن، حيث يكون متجه CVSS كما يلي: AV:N/AC:L/PR:N/UI:N/S:C — قابل للوصول عبر الشبكة، دون صلاحيات، ودون تفاعل من المستخدم، مع تغيّر في النطاق لأن أمرًا داخل المساعد يعبر إلى نظام التشغيل المضيف. والدرجة تخصّ CNA، وCNA هنا هو برنامج الاستشارات الأمنية لدى GitHub، وهو أيضًا ما يشير إليه معرّف مصدر سجل CVE. وتحمل NVD المتجه نفسه كمقياس ثانوي، وهي اعتبارًا من 28 أكتوبر 2026 تُدرج الإدخال في حالة "Deferred"، ما يعني أن NVD نشرت تحليل الجهة المُسنِدة بدلًا من تحليلها الخاص.

صدر التصحيح قبل التنبيه الأمني بشهر

يسير التسلسل الزمني عكسيًا من النشر، وهو الجزء الأقل بديهية في السجل. أبلغ Lasso عن العيب بشكل خاص عبر قناة الاستشارات في GitHub في 8 يوليو 2026. ردّت MaxKB في اليوم التالي، فحصَرت التقرير على الصورة الرسمية وطلبت إثبات مفهوم داخل حاوية؛ وقد قدّم الباحثون ذلك وتجاوز الساندبوكس في 10 يوليو. وصل إيداع إصلاح، 594f50f2، في 9 يوليو — بعد التقرير بيوم واحد — وأعاد كتابة sandbox_shell.py بحيث تُحلَّل سلسلة أوامر النموذج أولاً وتُطبَّق بادئة gosu على كل أمر بسيط لا على الأول فقط، مع إعادة اقتباس كل قائمة وسائط بحيث لا يستطيع الاستبدال الإفلات إلى الصدفة الأم. يصف تقرير Lasso التغيير بأنه يطبّق بادئة gosu «على كل أمر بسيط، وليس على الأول فقط».

الإصدار الذي يتضمنه، v2.10.5-lts، نُشر في 6 أغسطس 2026. ونُشرت استشارة GitHub في 2 سبتمبر، ونشرت NVD ثغرة CVE في 21 سبتمبر، وأُضيفت كتلة SSVC الخاصة بـ CISA وأفاد GBHackers في 22 سبتمبر، وظهرت مقالة Lasso الخاصة في 10 سبتمبر — في منتصف ذلك التسلسل، لا في بدايته. وكان لدى مشغّل يتابع وسوم الإصدارات بدلاً من خلاصات الاستشارات الترقيع قبل التحذير بنحو أربعة أسابيع.

تستحق حدود الإصدارات اهتمامًا أكبر مما يمنحه إياها التنبيه، لأن المصدرين الأساسيين يختلفان والمستودع يحسم المسألة. يسجّل حقل النموذج في التنبيه الإصدارات المتأثرة بصيغة "<= 2.10.3-lts"، مع ملاحظة بأن ذلك تم التحقق منه على 2.10.3-lts وأن المسار القابل للاستغلال "من المحتمل" أن يؤثر في جميع الإصدارات التي تبني الوكلاء بهذه الطريقة. ويذكر تقرير Lasso نفسه أن النطاق المتأثر هو "<= 2.10.4-lts". وتؤكد الوسوم النطاق الأوسع: فالوسم v2.10.4-lts، الصادر في 16 يوليو 2026، يحمل الملف sandbox_shell.py نفسه المكوّن من 75 سطرًا كما في v2.10.3-lts، بينما يظهر الملف المعاد كتابته المكوّن من 311 سطرًا أول مرة في v2.10.5-lts. كان المشغّل على 2.10.4-lts الذي يقرأ فقط نطاق التنبيه سيستنتج أنه خارج ذلك النطاق. لكنه لم يكن كذلك.

ما الذي لم يفعله الإصلاح

ما يصلحه 2.10.5-lts هو الغلاف: فهو لم يعد يبني سلسلة shell واحدة تحت الجذر. وما لا يفعله هو أي شيء بشأن الأداة. إن القراءة المباشرة للمستودع عند الوسم v2.10.8-lts، المنشور في 22 أكتوبر 2026، تُظهر أن الوكيل لا يزال مُنشأً بـ backend=SandboxShellBackend وأن interrupt_on لا يزال يحمل ثلاثة مفاتيح بالضبط — write_file وread_file وedit_file — دون execute. إن أول اقتراحين من اقتراحات المعالجة في التنبيه الاستشاري، وهما الاعتماد افتراضيًا على خلفية غير تنفيذية وإضافة "execute": True إلى خريطة الموافقات، غير موجودين في ذلك الإصدار.

وصلت توصية الإغلاق عند الفشل (fail-closed) لاحقًا، في v2.10.7-lts، وهي مهمة لوضع النشر الذي كان الأسوأ حالًا. نُشرت في 15 أكتوبر 2026، وتغيّر السطر في sandbox_shell.py من CONFIG.get("SANDBOX", 0) إلى CONFIG.get("SANDBOX", 1). أي تثبيت من المصدر أو على العتاد المباشر لم يضبط المتغير أصبح الغلاف مُفعّلًا افتراضيًا بدلًا من أن يكون معطّلًا، وهو ما يمثل توصية "الإغلاق عند الفشل في عمليات النشر غير المعتمدة على الحاويات" بالمعنى الضيق. طالب التنبيه بأكثر من ذلك تحت العنوان نفسه — بأن يرفض المسار القادر على التنفيذ بدء التشغيل عندما يكون وقت تشغيل البيئة المعزولة غير متاح — وطالب بشكل منفصل بألا يبني الغلاف أبدًا سلسلة أوامر لصدفة الجذر. وفي جانب الحاويات، هذه حقيقة وليست توصية: لا يحمل أي من installer/Dockerfile أو installer/Dockerfile-base توجيه USER عند وسم v2.10.8-lts، لذا فإن صورة التطبيق ما زالت تبدأ بصلاحيات الجذر.

وبقراءة ذلك معًا، فإن حالة السجل حتى 28 أكتوبر 2026 هي هذه. النصف الثاني من الثغرة — الـ sandbox التي خرجت منها فاصلة منقوطة — أُغلق، والإعداد الافتراضي fail-open في عمليات نشر المضيف أُغلق. أما النصف الأول، وهو أداة execute التي تأتي مع كائن backend ولا تكون مفتاحًا في خريطة الموافقة، فلا يزال هو الكيفية التي يبني بها MaxKB مساعدًا مُفعّلًا بالأدوات. وكانت نصيحة المعالجة التي قدّمها الباحثون أنفسهم هي الأضيق نطاقًا: الترقية إلى 2.10.5-lts أو أحدث، وتشغيل نسخة Docker مع تمكين الـ sandbox. ونقل GBHackers التعليمات ذاتها بالإضافة إلى قائمة أوسع للمسؤولين — تعطيل واجهات backend الخلفية للوكلاء القادرة على shell ما لم يكن تنفيذ الشيفرة مطلوبًا صراحةً، واشتراط موافقة بشرية قبل أي إجراء execute، وتشغيل الحاويات بصلاحيات غير الجذر، والتعامل مع الصفحات المزحوفة ومستندات RAG والملفات المرفوعة كمدخلات غير موثوقة.

سجل MaxKB الآخر من نفس دفعة سبتمبر

ثاني مدخل لـ MaxKB في الأرشيف من هذه الدفعة هو خلل مختلف بنهاية أسوأ. CVE-2026-77516، المنشور أيضًا على NVD في 21 سبتمبر 2026، هو تجاوز للصلاحيات وليس حقن أوامر: من الإصدار 2.0.0 إلى 2.9.2، كان عضو مساحة عمل بأدنى دور، ممنوعًا صراحةً من الوصول إلى أداة عبر WorkspaceUserResourcePermission، لا يزال بإمكانه ربط معرّف تلك الأداة عبر tool_ids أو skill_tool_ids أو mcp_tool_ids وتنفيذها عبر مسار إرسال الوكيل أو سير العمل. لا يعيد مسار الإرسال تطبيق منح الصلاحية لكل أداة الذي تفرضه مسارات الأدوات المخصصة، كما أن تنفيذ الأداة يفك تشفير init_params على جانب الخادم، لذا يتلقى المستدعي بيانات الاعتماد التي تحملها الأداة التي مُنع منها. درجته 5.4، ويُختتم وصف NVD بجملة لا يضطر CVE-2026-77521 إلى حملها: "لا يتوفر إصدار مُصلح اعتبارًا من وقت هذه المراجعة."

التناقض هو الجزء المفيد لأي شخص يفرز الثغرتين. الثغرة التي حصلت على 10.0 كان لها إصلاح تم إيداعه خلال يوم واحد وأُصدر قبل شهر من نشرها. الثغرة التي حصلت على 5.4 لم تكن لها نسخة مُصلحة منشورة في وقت CVE الخاص بها.

ما يظل مفتوحًا حقًا أصغر مما توحي به الدرجة وأكبر مما تلمّح إليه ملاحظات الترقيع. الاكتشاف ليس محل خلاف، وقد تحقّق الفريق الذي وجده من الآلية من البداية إلى النهاية في وضعي النشر كليهما. أما التعرّض فهو غير مقيس بالكامل — فلم ينشر أحد عدد مساعدي MaxKB الذين يحملون أداة، أو عدد هؤلاء الذين يمكن لطرف غير موثوق الوصول إليهم، أو عدد الذين يعملون على مضيف بلا بيئة عزل — لذا فإن الأثر الواقعي للخلل دالة على عادات النشر التي لا يحصيها أي مصدر مُستشهد به. ولا يزال الجزء من التصميم الذي دفع الدرجة إلى الحد الأقصى موجودًا في الإصدار الحالي: قدرة تنفّذ الأوامر، مرفقة افتراضيًا، وغائبة عن الخريطة التي تسأل الإنسان أولًا.