MaxKB: يسمح مسار إرسال الوكيل للمستخدم الذي مُنِع من استخدام أداة بأن يستدعيها رغم ذلك ويقرأ بيانات اعتمادها.

يوفر MaxKB، مساعد الذكاء الاصطناعي المؤسسي مفتوح المصدر الذي تديره 1Panel-dev، قائمة أذونات لكل مستخدم ولكل أداة، تتيح لمسؤول منح عضو في مساحة عمل أداة واحدة ومنعه من أخرى. وفقًا للاستشارة الأمنية المنشورة في 2 سبتمبر 2026، ظل هذا المنع ساريًا على مسارات الأداة نفسها، لكن ليس على المسار الذي يستخدمه وكيل أو سير عمل لاستدعاء الأداة نفسها. كان بإمكان عضو في مساحة عمل يشغل أدنى دور أن يحدد معرّف أداة محظورة عند إنشاء سير عمل، ثم يشغّل سير العمل، فيحصل ليس فقط على مخرجات الأداة بل أيضًا على بيانات الاعتماد التي يفك MaxKB تشفيرها على جانب الخادم لتشغيلها. تتأثر الإصدارات من 2.0.0 إلى 2.9.2، ولم تذكر الاستشارة أي إصدار مصحّح. هذا السجل — ثغرة تجاوز التفويض في إرسال الأدوات في MaxKB — هو أحد المدخلات في OrcaRouter AI Incident Archive، الذي يضم مجموعة السجلات الكاملة والمدخلات المجاورة لهذا الحادث.

ما يجعل هذه القضية جديرة بالقراءة عن كثب ليس درجة التقييم، بل أن المنتج كان يملك بالفعل الفحص الصحيح، وطبّقه على الباب البديهي، وترك بابًا ثانيًا يؤدي إلى القدرة نفسها دون مراقبة. كُتب التنبيه الأمني، GHSA-383v-fx78-pphm، على يد الباحث الذي اكتشفه ونُشر عبر نظام التنبيهات الأمنية في GitHub عند الساعة 07:43 UTC من يوم 2 سبتمبر 2026، مع الإشارة إلى Matteo Panzeri (@matte1782). تبِع ذلك سجلّ CVE، CVE-2026-77516، في 21 سبتمبر 2026.

ما الذي يقرره التحذير

نموذج MaxKB لكل أداة هو WorkspaceUserResourcePermission، كما هو موصوف في التنبيه الأمني باعتباره قائمة سماح بمنع افتراضي تُحل وقت الطلب. تفرضه مسارات الأدوات المخصصة. يسرد التنبيه الأمني موضع الإنفاذ في apps/tools/views/tool.py، حيث يحمل كل من Operate.put وOperate.get وDebug.post وExport.get وDelete فحص إذن عرض مقابل إذن أداة مساحة العمل الخاصة بالمتصل. Debug.post هو المسار الأقرب إلى مجرد تشغيل أداة، وهو مقيّد.

لا يعيد مسار إرسال الوكيل وسير العمل تطبيق ذلك الفحص. ويتتبّع التنبيه ثلاثة مواضع منفصلة يغيب فيها. في apps/application/serializers/application.py، يربط مُسلسِل التطبيق tool_ids، skill_tool_ids وmcp_tool_ids مباشرةً من مدخلات الطلب دون تفويض لكل أداة — ويشير التنبيه إلى أن عدم التماثل ظاهر في الملف نفسه، لأن knowledge_id_list يجري التحقق منه مقابل قواعد المعرفة المتاحة للمستخدم على بُعد أسطر قليلة، بينما لا يحدث ذلك للأدوات. في apps/common/utils/shared_resource_auth.py، تمرّر filter_authorized_ids كل أداة في مساحة عمل المستدعي نفسه دون شرط؛ وبوابة العمل عبر مساحات العمل التي تعتمد عليها هي خطاف خاص بنسخة المؤسسات فقط وغائب عن الإصدار المجتمعي، ولا تستشير أبدًا WorkspaceUserResourcePermission. وعند نقطة التنفيذ النهائية، يشغّل apps/application/flow/step_node/tool_lib_node/impl/base_tool_lib_node.py الشيفرة المخزنة للأداة مع init_params بواسطة rsa_long_decrypt بعد فك تشفيرها تحت هوية التطبيق، دون فحص منح لكل أداة.

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

العرض التوضيحي، بأرقام الباحث نفسه

يُفيد التنبيه بتأكيد ديناميكي على v2.9.2، شُغّل من الصورة الرسمية all-in-one، 1panel/maxkb:v2.9.2. كان الإعداد مساحة عمل واحدة، ومديرًا، وعضوًا ثانيًا يحمل دور USER. أنشأ المدير الأداة A والأداة B، ووضع سرًّا عشوائيًا جديدًا في init_params الخاصة بالأداة B، وكتب جسم الأداة B ليعيد ذلك السر عند تنفيذه. ثم مُنح العضو إذنًا لكل أداة على حدة للأداة A فقط، ويقول التنبيه إن حالة عدم المنح للأداة B أُعيد التحقق منها في قاعدة البيانات بعد التشغيل.

أعاد النصف المرفوض من الاختبار ما يعد به المنتج. بصفتي العضو، أعاد مسار التصحيح الخاص بـ Tool B الاستجابة 403، وأعاد مسار التحديث الاستجابة 403، وأعاد مسار التصدير الاستجابة 403، وأعاد Tool A الممنوح الاستجابة 200 كفحص سلامة. ثم قام نصف التجاوز بربط Tool B في تطبيق سير عمل عبر عقدة مكتبة أدوات — قُبل الربط باستجابة HTTP 200 ودون أي فحص لكل أداة — وأعاد تشغيل سير العمل استجابة HTTP 200 مع جسم يحتوي على اسم الأداة، والسرّ الحارس، وقائمة المفاتيح ["api_key"].

يذكر التنبيه أن السرّ ظهر على ثلاث طبقات: في استجابة واجهة برمجة تطبيقات سير العمل، وفي سجل تنفيذ أداة حالته SUCCESS، وفي صف قاعدة البيانات حيث توجد خاصية Tool B المسماة init_params كشفرة RSA بطول 344 بايت — وهو ما يجادل به الباحث بأن القيمة فُكّت شفرتها من جانب الخادم تحت هوية التطبيق بدلاً من أن يقدمها المستدعي. وقد حصل العضو نفسه الذي رُفض على مسار تشغيل الأداة على السرّ المفكوك الشفرة الخاص بالأداة عبر ربطه في سير عمل.

نُشرت نتيجة واحدة، وطُورحت نتيجة أعلى.

الدرجة المرفقة بـ CVE-2026-77516 هي CVSS 3.1 5.4، متوسطة، مع المتجه AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N. ويُظهر سجل NVD أن هذه الدرجة مصدرها خلاصة الاستشارات الخاصة بـ GitHub وليس من تحليل NVD نفسه، كما يحمل الإدخال حالة Deferred، ما يعني أن NVD لم يُثرِه. ويتبع تصنيف الأرشيف الخاص تلك الدرجة المنشورة: خطورة متوسطة، دون تسجيل أي ضرر واقعي.

قسم التأثير في التنبيه نفسه يطالب بتقدير أعلى. فهو يذكر درجة خطورة تبلغ 7.1، أي «عالية»، وفق متجه يرفع تأثير السرية إلى «عالٍ»، ويقول إن الرقم يرتفع إلى 8.1 عندما تنفّذ الأداة المُرسَلة عمليات كتابة ذات امتيازات تحت هوية التطبيق. وهذا خلاف حول كيفية احتساب تعرّض بيانات الاعتماد، لا حول ما إذا كان التجاوز موجودًا — فالوثيقة نفسها تثبت العيب وتحتجّ في الوقت ذاته بأنه يُقدَّر بأقل من قيمته. ولا شيء في السجل العام يحسم أي الرقمين صحيح، كما أن تصنيف «متوسط» في الأرشيف يتبع درجة CVE المنشورة لا حجة التنبيه.

ثمة تقييمان إضافيان مسجّلان. إن نقاط قرار SSVC الخاصة بـ CISA، المضافة إلى مدخل NVD في 28 سبتمبر 2026، تسجّل الاستغلال بوصفه "poc"، والقابلية للأتمتة بوصفها "no"، والأثر التقني بوصفه "partial" — وتعكس قيمة "poc" وجود إثبات مفهوم، وهو موجود فعلًا في الاستشارة نفسها؛ وليست نتيجةً للاستغلال في البرية. وقد وضع نموذج EPSS الخاص بـ FIRST احتمال الاستغلال خلال الـ 30 يومًا القادمة عند 0.242%، وعند المئين 15.2، في التقدير المؤرخ 27 أكتوبر 2026.

إصلاح يسبق التنبيه الأمني، ولا يوجد أي إصلاح ضمن النطاق المتأثر

يقول جدول الإصدارات في التنبيه الأمني إن الإصدارات المتأثرة هي من 2.0.0 إلى 2.9.2، وإنه لا توجد إصدارات مصححة، ويذكر نص التنبيه أنه لا يتوفر إصدار مُصلح حتى وقت المراجعة، مضيفًا أن إصلاحًا في إصدار موسوم سيسمح لـ CVE بالاستناد إليه. أما مستودع المورّد فيروي قصة مختلفة قليلًا، والفرق يهم أي شخص يقرر ما الذي يشغّله.

في مستودع MaxKB، تكون الدوال التي تُغلق مسار الإرسال — validate_bound_tool_permissions وget_authorized_tool_ids في apps/application/serializers/application.py — غائبة عن وسم v2.9.2 وعن v2.10.2-lts وv2.10.3-lts وv2.10.4-lts، وحاضرة ابتداءً من v2.10.5-lts فصاعدًا. نُشر ذلك الإصدار في 6 أغسطس 2026، أي قبل أربعة أسابيع من التنبيه الأمني. ويضيف الوسم نفسه فحصًا للأدوات خاصًا بكل مستخدم إلى base_tool_lib_node.py، بالاستناد إلى WorkspaceUserResourcePermission، ويضيف مرشِّحًا يراعي المستخدم إلى shared_resource_auth.py — أي أنه ينفّذ، على نحو موجز، خطوات المعالجة الثلاث التي يوصي بها التنبيه الأمني لاحقًا.

لم يصرّح أحد علنًا بذلك الارتباط. لا تذكر ملاحظات إصدار v2.10.5-lts أي إصلاح متعلق بأذونات الأدوات؛ بل تسرد أربعة بنود أمنية غير مترابطة ومجموعة من الأعمال على الميزات وإصلاح الأخطاء. ولا تسمّي الاستشارة الأمنية الإصدار 2.10.5، بل إن نطاق الإصدارات المتأثرة فيها يتوقف ببساطة عند 2.9.2، آخر إصدار في سلسلة 2.9. ولا يُظهر سجل الإصدارات أي تصحيح في 2.9.x بعد الاستشارة، لذا لا يتوفر لنشر قائم على 2.9.2 أي بناء مُصحّح داخل سلسلته نفسها. الإصدار الحالي هو v2.10.8-lts، المنشور في 22 أكتوبر 2026، وتصف ملاحظاته إصلاحات في X-Pack تتعلق بتخويل الأدوات المشتركة بدلًا من أي شيء في مسار الإرسال الخاص بالنسخة المجتمعية.

ما الذي لم يتم إثباته؟

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

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

ما الذي يمكن للمشغّل القيام به

توجَّه المعالجة الإصلاحية الخاصة بالتوصية الأمنية إلى القائمين على الصيانة لا إلى المشغّلين، وتنطبق خطواتها الثلاث على الشيفرة التي ظهرت في v2.10.5-lts: طبّق التفويض الخاص بكل أداة قبل تنفيذ أداة في تنفيذات مكتبة الأدوات وعقدة الأدوات، وتحقق من صحة كلٍّ من tool_ids، skill_tool_ids وmcp_tool_ids عند وقت الربط بالطريقة نفسها التي تُتحقق بها knowledge_id_list بالفعل، واجعل filter_authorized_ids تستشير التفويض الخاص بكل أداة بدلاً من عضوية مساحة العمل وحدها.

بالنسبة إلى فريق يشغّل إصدارًا متأثرًا، فإن الخطوات العملية التي تنبثق من وصف الإشعار نفسه هي ما يلي.

• تعامل مع كل سرّ مخزَّن في init_params الخاص بأداة على نشر متأثر باعتباره متاحًا لأي عضو في مساحة العمل، بما في ذلك أدنى دور، ودوِّر بيانات الاعتماد تلك بدلًا من افتراض أن الرفض المفروض على مستوى كل أداة قد حمّاها.

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

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

• إذا كنت تقوم بالترقية، فلاحظ أن الفحص الخاص بكل مستخدم يظهر في المستودع ابتداءً من v2.10.5-lts فصاعدًا، وأن الاستشاري لا يحدد أي إصدار بوصفه الإصلاح — فالمشغّل الذي يعتمد على الترقية يعتمد على المصدر الموسوم، وليس على بيان تصحيح من المورّد.

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

الدرس المستفاد من هذا السجل بنيوي لا رقمي. فما صلاحيةٌ لكل مورد إلا بقوة أقل نقاط الدخول حمايةً، ومنصة الوكلاء تتراكم فيها نقاط الدخول بسرعة: مسار تصحيح، ومسار تصدير، وعقدة سير عمل، ومُشغّل دردشة. كان لدى MaxKB قائمة المنح والفحص؛ وما افتقرت إليه، في خط الإصدارات من 2.0 إلى 2.9، هو عادة طرح السؤال نفسه عند كل باب.