Skip to content
KitploitKITPLOIT
أدواتعمليات الاستغلالالمدونة
Log in
إرسال
أدواتعمليات الاستغلالالمدونة
إرسال

أدوات الاختراق واختبار الاختراق والأمن السيبراني لترسانتك الأمنية!

Kitploit هو دليل لأدوات الاختراق والأمن السيبراني واختبار الاختراق. اكتشف آخر تحديثات المشاريع للعثور على الثغرات وتحليل الأنظمة وأتمتة الاختبارات وتعزيز أمنك.

الخلاصاتاتصالالخصوصية© 2026 Kitploit

دليل الأدوات

الفئات

عرض جميع الفئات
Loading categories
cve-2026-77521-lab — إعادة إنتاج حميدة ومكتفية ذاتيًا لـ CVE-2026-77521 (تنفيذ أوامر قابل لحقن المطالبات في MaxKB) | Kitploit
أدوات/GitHubGitHub/inertfluid/cve-2026-77521-lab
تحليل الثغرات الأمنيةالاستغلالاستغلال تطبيقات الويبالتعلم والتعليمأمن الذكاء الاصطناعيمختبرات وتدريب عملي
GitHubinertfluid/cve-2026-77521-lab

cve-2026-77521-lab

إعادة إنتاج حميدة ومكتفية ذاتيًا لـ CVE-2026-77521 (تنفيذ أوامر قابل لحقن المطالبات في MaxKB)

عرض المستودع
منذ 22 أياملم تتم المراجعة بعد

الأكثر شعبية

عرض الكل →

اكتشف الأدوات الأكثر استخدامًا من قبل مجتمعنا.

استكشف جميع الأدوات

تصفح مجموعتنا من الأدوات

عرض جميع الأدوات →
مشاركة

CVE-2026-77521 — مختبر وكيل MaxKB القابل لحقن الأوامر → تنفيذ الأوامر

مختبر مكتفٍ ذاتيًا وغير ضار يعيد إنتاج GHSA-f36j-f34j-h3rx / CVE-2026-77521: في MaxKB (منصة مساعد ذكاء اصطناعي مؤسسي / RAG مفتوحة المصدر)، أي مساعد مزوّد بأداة، أو أداة MCP، أو مهارة، أو تطبيق فرعي يحصل على أداة execute صدفية تُحقن تلقائيًا وهي غير محمية ببوابة موافقة بشرية — لذا يصل حقن الأوامر (من الدردشة أو من مستند مُستوعَب) إلى الصدفة. كان من المفترض أن يحتويه صندوق رمل (sandbox)، لكن سلسلة نصية بـ shell=True سمحت للرموز الخاصة (metacharacters) بالإفلات منه.

التنبيه الأمنيGHSA-f36j-f34j-h3rx
CVECVE-2026-77521
المشروع1Panel-dev/MaxKB
المتأثر< 2.10.5-lts
المُصلَّح2.10.5-lts (commit 594f50f) — جزئي، انظر أدناه
CVSS10.0 حرج (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
الضعفCWE-78 (حقن أوامر نظام التشغيل) · CWE-250 (امتيازات غير ضرورية) · CWE-749 (طريقة خطرة مكشوفة)

⚠️ الاستخدام الأخلاقي

يعيد هذا إنتاج ثغرة مُصلَّحة ومُفصح عنها علنًا لأغراض تعليمية ودفاعية. يعمل محليًا بالكامل وبشكل غير ضار:

  • تعمل إثباتات المفهوم (PoCs) الحتمية على أوامر غير ضارة فقط (id، وكتابة ملف علامة يحذفه إثبات المفهوم). لا يوجد gosu/صندوق رمل/جذر حقيقي — إذ يُستبدل غلاف إسقاط الامتيازات بعلامة env خاملة حتى يعمل العرض التوضيحي في أي مكان.
  • يستدعي إثبات المفهوم 3 نموذجًا حقيقيًا لكنه يلاحظ فقط استدعاء الأداة الذي يصدره؛ ولا ينفذه. الأمر المحقون غير ضار. لا توجّه هذا إلا إلى بنية تحتية تملكها.

الثغرة، في فقرة واحدة

يُبنى مساعد MaxKB المزوّد بأي قدرة على deepagents مع SandboxShellBackend. يحقن deepagents تلقائيًا أداة execute صدفية (إضافةً إلى read_file/write_file/…)، ولا يستخدم MaxKB أي excluded_tools، لذا تكون execute حاضرة دائمًا. إعداد interrupt_on — الذي يحدد ما يحتاج إلى موافقة بشرية — هو {"write_file": False, "read_file": False, "edit_file": False}: execute ليست فيه، لذا تعمل دون أي موافقة. أي نص يمكنه توجيه النموذج (رسالة دردشة، أو مستند مسموم تستوعبه خط أنابيب RAG) يمكنه بالتالي جعل الوكيل ينفذ أوامر صدفية. في عمليات التثبيت من المصدر يكون SANDBOX معطّلًا افتراضيًا، لذا تعمل الأوامر باسم مستخدم التطبيق؛ وفي الحاوية الرسمية (الجذر) كان غلاف صندوق الرمل سلسلة نصية بـ shell=True، لذا نُفِّذت ;/>/$() خارج gosu، بصلاحيات الجذر.

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

  1. غياب بوابة الحلقة البشرية (جوهر CVSS-10). مع interrupt_on الحقيقية في MaxKB، يعمل استدعاء execute المحقون دون موافقة؛ وإضافة "execute": True تُقيّده ببوابة. → poc/01_missing_hitl_gate.py
  2. الإفلات من صندوق الرمل عبر رموز الصدفة الخاصة. يفلت ;+إعادة توجيه من بادئة gosu ذات السلسلة الواحدة؛ بينما تعادل إعادة الاقتباس في _build_sandbox_command() في 2.10.5-lts ذلك. → poc/02_sandbox_escape.py
  3. نموذج حقيقي يفعلها. بمجرد إعطائه مستندًا مستوعَبًا مسمومًا فقط، يستدعي نموذج حقيقي execute بأمر المهاجم (ولا يفعل ذلك مع مستند نظيف). → poc/03_real_llm.py

الإصلاح يسد نصف الثغرة فقط

تُقوّي رقعة 2.10.5-lts المُصدَرة (commit 594f50f) الهروب من الـ sandbox فقط — فهي تضيف _build_sandbox_command()، التي تُقسّم على معاملات الـ shell، وتُعيد اقتباس كل token باستخدام shlex.quote، وتُغلّف كل أمر بسيط ببادئة gosu. وبالتحقق مقابل مصدر v2.10.5-lts، فإن جوهر الوكالة دون تغيير: لا يزال interrupt_on يُغفل execute، ولا يزال الـ backend هو SandboxShellBackend، ولا يزال SANDBOX افتراضيًا 0. لذا بعد الإصلاح، لا يزال execute المُحقَن عبر prompt يعمل دون موافقة بشرية — فقد تم تعزيز الجدار الداخلي بينما بقي البوابة مفتوحة. يُوضّح PoC 1 التخفيف المُوصى به (تقييد execute)، الذي لم يُصدِره المورّد.

تشغيله

لا توجد تبعيات لـ PoC 1/2 (Python 3.9+):

./run.sh                               # all three (PoC 3 skips without an endpoint)
python3 poc/01_missing_hitl_gate.py    # missing approval gate
python3 poc/02_sandbox_escape.py       # metacharacter sandbox escape

هل تعرض هذا؟ يُعدّ DEMO.md دليل تشغيل، ويقوده demo.sh ضغطة مفتاح واحدة في كل مرة.

اختياري: PoC 3 مقابل نموذج لغوي كبير حقيقي

أي نقطة نهاية متوافقة مع OpenAI (مستضافة ذاتيًا أو نموذج مفتوح مستضاف). مثال (Groq):

export OPENAI_BASE_URL=https://api.groq.com/openai/v1
export OPENAI_API_KEY=$GROQ_API_KEY     # read from env only; never logged
MODEL="openai/gpt-oss-20b" python3 poc/03_real_llm.py

خلف وكيل فحص TLS يعيد المحاولة دون التحقق مع تحذير (INSECURE_SSL=1 لإجباره على ذلك). يتخطى بسلاسة إذا لم يتم تعيين نقطة نهاية.

الملفات

المسارما هو
sandbox_shell.pyنموذج غير ضار لبناء أمر execute() في MaxKB — السلسلة القابلة للاستغلال مقابل _build_sandbox_command() المُصحّحة
agent_sim.pyنموذج مصغّر لبوابة الموافقة البشرية interrupt_on في deepagents
payloads/poisoned-document.mdمستند قاعدة معرفة مسموم من المهاجم (حقن غير مباشر)
poc/01_missing_hitl_gate.pyتنفيذ execute المحقون يعمل دون موافقة؛ والبوابة تمنعه
poc/02_sandbox_escape.pyالأحرف الخاصة تتجاوز بادئة gosu؛ ومحلل الإصدار 2.10.5 يحتويها
poc/03_real_llm.pyنموذج حقيقي يستدعي execute من المستند المسموم (نظيف مقابل مسموم)
DEMO.md / demo.shدليل تشغيل العارض ومشغّل العرض المتدرّج
assets/attack-flow.{svg,png}مخطط تدفق الهجوم (صورة المدونة الرئيسية)
assets/poc3-groq-sample.txtمخرجات PoC 3 المسجّلة (بديل العرض)
تنزيل الأداة