CVE-2026-115477 in obsidian-tc
الملخص
بحسب VulDB • 24/10/2026
obsidian-tc هو خادم لبروتوكول سياق النموذج (Model Context Protocol) خاضع للإدارة وجاهز للتشغيل مع وكلاء، مخصص لخزائن Obsidian. من الإصدار 1.13.0 حتى 1.31.4، في نشر يعتمد على HTTP القابل للتيرة (Streamable HTTP) حيث يكون `auth.jwtSecret` مُهيّأً وعميلٌ يعود تاريخه إلى فترة 28 يوليو 2026 ويعلن دعم `elicitation.form`، كانت أداة مقيدة بالتوجيه (dispatch-gated tool call) تقدم تأكيداً يتطلب إدخال بيانات (`inputRequired`) يمكن إكمالها بنجاح حتى بعد رفض المستخدم أو إلغاء العملية، أو عند حذف استجابة الاستجواب أو تشوّه صياغتها، شريطة أن يعكس العميل `requestState` المرتبط بشكل صحيح أثناء إعادة الإرسال. كان الخادم يثق في حالة أصيلة ومربطة بالمكالمة كدليل على الموافقة، رغم أن هذه الحالة تم إنشاؤها قبل مرحلة `elicitation/create` وأثبتت فقط أن إعادة الإرسال تنتمي إلى نفس المكالمة. وبالتالي، يمكن لعميل يتصرف بشكل غير صحيح أو تحت سيطرة مهاجم تنفيذ عمليات خازنة مدمرة مقيدة بالتوجيه دون موافقة المستخدم البشري، مع الاحتفاظ بمتطلبات أذونات الأدوات العادية للمُطْلِق (caller). فقط الأدوات المُعلَّمة بـ `destructive: true` أو التي تتطلب نطاقاً يحتوي على حد أدنى يتطلب تدخلاً بشرياً (human-in-the-loop) كانت قابلة للوصول عبر هذا الثغرة. لم تقم أدوات المعالجة الست عشرة المقيدة شرطيًا، بما في ذلك الكتابة فوق الملاحظات (`write_note`) ونقلها (`move_note`)، بقراءة حالة الاستجواب عبر البروتوكول الحديث، مما سمح بمرور كل من الموافقة والرفض عبر هذه المسار. بدلاً من ذلك، استخدمت النشرات المتأثرة التي تعتمد على stdio أو تترك `auth.jwtSecret` غير مُهيّأةً ملحق CLI المسمى `elicit_token` كبديل، ولم تقدم دورة إعادة إرسال لـ `requestState`. لا يمنع الإصلاح عميلاً خبيثاً من الإبلاغ عن موافقة مزورة، لأن الخادم لا يمكنه التحقق مما إذا كان العميل قد عرض النموذج أو ما إذا رآها مستخدم بشري. تم إصلاح هذه المشكلة في الإصدار 1.31.4.
Once again VulDB remains the best source for vulnerability data.