Aleister1102

قد يؤدي التحقق غير السليم في Auth0.js SDK إلى إرجاع بيانات ملف تعريف المستخدم عند استخدام رمز تعريف (ID token) غير صالح مصمم خصيصًا بالاقتران مع رمز وصول (access token) صالح. تحدث هذه المشكلة في التطبيقات التي يعتمد فيها التحكم في الوصول على القواعد المحددة في Auth0 Actions، مما قد يؤدي إلى الكشف غير المصرح به عن المعلومات.

اسم البرنامج المعرض للخطر والإصدارات المتأثرة إصدارات Nest السابقة للإصدار 11.1.18 الوصف تقوم الدالة `SseStream. transform()` بإدراج `message.type` و`message.id` مباشرةً في مخرجات بروتوكول Server-Sent Events النصي دون تنقية أحرف نهاية السطر (r، ). ونظرًا لأن بروتوكول SSE يستخدم كل من r و كمحددات للحقول و كحدود للأحداث، فإن المهاجم القادر على التأثير على هذه الحقول يمكنه حقن أحداث SSE تعسفية، وتزوير أنواع الأحداث، وإتلاف حالة إعادة الاتصال. يمكن للمهاجم تزوير أحداث SSE بأنواع `event:` تعسفية، مما يتسبب في تشغيل استدعاءات `EventSource.addEventListener()` من جانب العميل لأنواع أحداث غير صحيحة. كما يمكنهم حقن حمولات `data:` تعسفية، مما قد يؤدي إلى هجوم XSS إذا قام العميل بعرض بيانات SSE كـ HTML دون تنقية. بالإضافة إلى ذلك، يمكن للمهاجمين حقن حقول `id:`، مما يؤدي إلى إتلاف رأس `Last-Event-ID` عند إعادة الاتصال، مما يتسبب في فقدان العميل للأحداث أو إعادة تشغيلها. يتطلب الهجوم من المطور ربط البيانات التي يتحكم فيها المستخدم بحقول `type` أو `id` في رسائل SSE. التوصيات قم بالتحديث إلى الإصدار 11.1.18 أو أحدث.

كان بروتوكول النقل Streamable HTTP في Go MCP SDK عرضة لقبول طلبات `POST` عبر المواقع التي يُنشئها المتصفح دون التحقق من صحة رأس `Origin` أو اشتراط وجود `Content-Type: application/json`. في عمليات النشر التي تفتقر إلى ميزة «التفويض» (Authorization)، لا سيما في الإعدادات التي لا تعتمد على الحالة أو الجلسات، سمح ذلك لموقع ويب عشوائي بإرسال طلبات MCP إلى خادم محلي، مما قد يؤدي إلى تشغيل الأداة. يمكن لموقع ويب ضار إرسال طلبات POST عبر المواقع باستخدام `Content-Type: text/plain`، متجاوزًا حواجز الفحص المسبق لـ CORS بسبب خصائص قائمة الأمان لـ CORS. المكون المعرض للخطر هو بروتوكول نقل Streamable HTTP. تقبل نقطة نهاية واجهة برمجة التطبيقات (API) طلبات `POST`. المعلمة المعرضة للخطر هي رأس `Origin`.

يحتوي WeKnora، وهو إطار عمل مدعوم بنموذج اللغة الكبير (LLM) للفهم العميق للوثائق والاسترجاع الدلالي، على ثغرة أمنية تسمح بتنفيذ التعليمات البرمجية عن بُعد (RCE) دون مصادقة في عملية التحقق من صحة إعدادات stdio الخاصة بـ MCP. يسمح التطبيق بتسجيل المستخدمين دون قيود، مما يتيح للمهاجمين إنشاء حسابات واستغلال ثغرة حقن الأوامر. على الرغم من تطبيق قوائم الأوامر المسموح بها (`npx`، `uvx`) وقوائم الحظر للمعلمات/متغيرات البيئة، يمكن التحايل على عملية التحقق باستخدام العلامة `-p` مع `npx node`. وهذا يسمح للمهاجمين بتنفيذ أوامر عشوائية بامتيازات التطبيق، مما قد يؤدي إلى اختراق النظام بالكامل. يتضمن مسار الكود المعرض للخطر الدالتين `ValidateStdioConfig()` و`ValidateStdioArgs()`، حيث لا يتم حظر العلامة `-p` في قائمة التعبيرات النمطية `DangerousArgPatterns`، مما يسمح بتنفيذ أحمال JavaScript عبر `npx node -p <payload>`. تم إصلاح المشكلة بشكل غير معلن في الإصدار 0.2.10، دون إصدار رقم CVE عام أو تنبيه أمني، مما قد يترك العملاء عرضة للخطر.

WeKnora هو إطار عمل مخصص للفهم العميق للوثائق والاسترجاع الدلالي. توجد ثغرة تسمح بتجاوز التفويض بين المستأجرين في نقطة النهاية الخاصة بنسخ قاعدة المعرفة. يمكن للمستخدم المصادق عليه نسخ قاعدة المعرفة الخاصة بمستأجر آخر إلى مستأجره الخاص إذا كان يعرف أو خمن معرّف قاعدة المعرفة المصدر، مما يؤدي إلى تسرب البيانات على نطاق واسع. تحدث المشكلة بسبب عدم كفاية عمليات التحقق من التحكم في الوصول عند معالجة المعلمة `source id` في نقطة النهاية `POST /api/v1/knowledge-bases/copy`. وعلى وجه التحديد، لا تفرض الدالة `GetKnowledgeBaseByID` في طبقة المستودع عزل المستأجرين، مما يسمح بالوصول إلى قواعد المعرفة الخاصة بمستأجرين آخرين. يقوم الكود المعرض للثغرة بنسخ إعدادات ومحتوى قاعدة المعرفة الأصلية إلى قاعدة معرفة جديدة في مستأجر المهاجم. ويتم استخدام المعلمة `source id`، التي يقدمها المهاجم، دون التحقق من صحتها بشكل مناسب.

يحتوي WeKnora، وهو إطار عمل قائم على نماذج اللغة الكبيرة (LLM) مخصص للفهم العميق للوثائق والاسترجاع الدلالي، على ثغرة أمنية تتعلق بإعادة ربط DNS في الأداة `web fetch`. يمكن لمهاجم غير مصدق تجاوزه عملية التحقق من صحة عناوين URL والوصول إلى موارد داخلية للخادم، بما في ذلك عناوين IP خاصة مثل 127.0.0.1 و192.168.x.x. ويتم ذلك عن طريق إنشاء نطاق ضار يتم تحويله مبدئيًا إلى عنوان IP عام أثناء عملية التحقق من الصحة، ثم يتم تحويله إلى عنوان IP خاص أثناء التنفيذ. لا تتمتع أداة `web fetch` بتثبيت DNS كامل، حيث تقوم بالتحقق من صحة عنوان URL مرة واحدة فقط من خلال الدالة `validateParams()`. ثم يتم تمرير عنوان URL الأصلي دون تغيير إلى الدالة `fetchHTMLContent()`، التي تستدعي في النهاية الدالة `fetchWithChromedp()`. يقوم المتصفح بدون واجهة (Chromedp) بحل اسم المضيف بشكل مستقل، دون تثبيت DNS، مما يخلق حالة «وقت الفحص - وقت الاستخدام» (TOCTOU). تسمح هذه الثغرة الأمنية بالوصول إلى الخدمات المحلية الحساسة واحتمال تسرب البيانات.

يحتوي WeKnora، وهو إطار عمل مدعوم بنموذج لغوي كبير (LLM) مخصص للفهم العميق للوثائق والاسترجاع الدلالي، على ثغرة أمنية تسمح بتنفيذ التعليمات البرمجية عن بُعد (RCE) في وظيفة الاستعلام عن قاعدة البيانات. لا يقوم نظام التحقق من صحة التطبيق بفحص العناصر الفرعية داخل تعبيرات المصفوفات وتعبيرات الأسطر في PostgreSQL بدقة، مما يسمح للمهاجمين بالتحايل على إجراءات الحماية ضد حقن SQL. من خلال تضمين وظائف PostgreSQL الخبيثة داخل هذه التعبيرات ودمجها مع عمليات الكائنات الكبيرة وقدرات تحميل المكتبات، يمكن للمهاجم غير المصادق عليه تنفيذ تعليمات برمجية عشوائية على خادم قاعدة البيانات بامتيازات مستخدم قاعدة البيانات. تنبع المشكلة من عملية تحقق غير كاملة داخل الدالة `validateNode()`، وتحديدًا عدم وجود معالجات لأنواع العقد `ArrayExpr` و`RowExpr`. وهذا يسمح للمهاجمين بإدخال دالات خطيرة خلسةً، مثل `pg read file` و`lo from bytea` و`lo put` و`lo export` و`pg reload conf`، في الاستعلامات. يُظهر نموذج إثبات المفهوم القدرة على قراءة ملفات عشوائية، وتحميل مكتبة مشتركة ضارة، وأخيرًا تنفيذ التعليمات البرمجية. قد يؤدي الاستغلال الناجح إلى اختراق النظام بالكامل، بما في ذلك استخراج البيانات، والتعديل، وتعطيل الخدمة، وفقدان

WeKnora هو إطار عمل مخصص للفهم العميق للوثائق والاسترجاع الدلالي. يسمح خلل في التحكم في الوصول في أداة استعلام قاعدة البيانات لأي مستأجر تمت مصادقته بقراءة البيانات الحساسة الخاصة بمستأجرين آخرين. ويشمل ذلك مفاتيح واجهة برمجة التطبيقات (API) وإعدادات النماذج والرسائل الخاصة. لا يفرض التطبيق عزل المستأجرين في الجداول الحساسة (`models`، `messages`، `embeddings`)، مما يسمح بالوصول غير المصرح به إلى البيانات بين المستأجرين الذين يتمتعون بامتيازات مصادقة على مستوى المستخدم. السبب الجذري هو عدم التوافق بين الجداول القابلة للاستعلام والجداول المحمية بالعزل بين المستأجرين. على وجه التحديد، الجداول `messages` و`embeddings` و`models` قابلة للاستعلام، لكنها غير محمية بالعزل بين المستأجرين، مما يعني أن الاستعلامات في هذه الجداول لا يخضع لها مرشح `WHERE tenant id = X` التلقائي. يمكن للمهاجم استغلال هذه الثغرة عن طريق إنشاء استعلامات SQL باستخدام أداة `database query` للوصول إلى البيانات الحساسة الخاصة بالمستأجرين الآخرين. يقع الكود المعرض للخطر في `internal/utils/inject.go` و`database query.go`.

PinchTab هو خادم HTTP مستقل مصمم لمنح وكلاء الذكاء الاصطناعي تحكمًا مباشرًا في متصفح Chrome. توجد ثغرة من نوع تزوير الطلبات من جانب الخادم (SSRF) في نقطة النهاية `/download`. وهذا يسمح للمستخدم الذي لديه وصول إلى واجهة برمجة التطبيقات (API) بإجبار خادم PinchTab على إرسال طلبات إلى عناوين URL عشوائية، بما في ذلك الخدمات الداخلية للشبكة والملفات المحلية للنظام، ومن ثم استرداد محتوى الاستجابة بالكامل. تقع الثغرة الأمنية في معالج `GET /download?url=<url>` داخل الملف `download.go`، وتحديدًا في السطر 78، حيث يتم تمرير المعلمة `url` التي يتحكم فيها المستخدم إلى `chromedp.Navigate(dlURL)` دون التحقق من صحتها بشكل كافٍ. وهذا يتيح الوصول إلى الملفات المحلية باستخدام مخطط `file://`، والخدمات الداخلية، ونقاط نهاية بيانات التعريف السحابية. ثم يقوم الخادم بإرجاع نص الاستجابة الذي تم التقاطه إلى المهاجم، مما يسمح بتسريب البيانات الحساسة.

WeKnora هو إطار عمل مخصص للفهم العميق للوثائق والاسترجاع الدلالي. يوجد عيب في نقاط نهاية إدارة المستأجرين (tenants) يتيح للمستخدمين المصادق عليهم قراءة أي مستأجر أو تعديله أو حذفه باستخدام معرّف (ID). ونظرًا لأن تسجيل الحسابات مفتوح للجمهور، يمكن لمهاجم غير مصادق عليه تسجيل حساب واستغلال هذه الثغرة. وقد يؤدي ذلك إلى الاستيلاء على الحساب بين المستأجرين وتدميره. نقاط نهاية واجهة برمجة التطبيقات (API) المتأثرة هي: - `/api/v1/tenants` - `/api/v1/tenants/{id}` تحدث هذه الثغرة الأمنية لأن معالجات إدارة المستأجرين لا تتحقق من الملكية أو الامتيازات بين المستأجرين قبل تنفيذ الإجراءات. تستخدم المعالجات معرّف المستأجر مباشرةً من المسار دون إجراء أي تحقق من التفويض. وتعتبر المتغير `id` في نقطة نهاية واجهة برمجة التطبيقات `/api/v1/tenants/{id}` معرضة للخطر بشكل خاص.

WeKnora، وهو إطار عمل قائم على نماذج اللغة الكبيرة (LLM) مخصص للفهم العميق للوثائق والاسترجاع الدلالي، معرض لثغرة أمنية تتعلق بتضارب أسماء الأدوات والحقن غير المباشر للموجهات. يمكن لخادم MCP عن بُعد ضار أن يختطف تنفيذ الأدوات باستغلال قاعدة تسمية غامضة في عميل MCP (`mcp {service} {tool}`). يمكن للمهاجم تسجيل أداة خبيثة تحل محل أداة شرعية، مثل `tavily extract`. وهذا يسمح بإعادة توجيه مسار تنفيذ نموذج اللغة الكبير (LLM)، وتسريب أوامر النظام والسياق، وإمكانية تنفيذ أدوات أخرى بامتيازات المستخدم. ينشأ هذا الضعف عن تضارب أسماء الأدوات في العميل، وعن إخراج الأدوات/البيانات الوصفية دون تعقيم. يقوم العميل بإنشاء معرّفات داخلية للأدوات عن طريق تعقيم اسم الخدمة واسم الأداة وربطهما بخطوط سفلية. ويقوم التسجيل بالكتابة فوق الإدخالات الموجودة، مما يسمح لخدمة خبيثة باستبدال التنفيذات الشرعية. يقوم العميل بإعادة تغذية أوصاف أدوات MCP ونتائج التنفيذ مباشرةً إلى سياق نموذج اللغة الكبير (LLM) دون تنقية، مما يسمح لأداة خبيثة بإرجاع تعليمات (حقن المطالبة) يفسرها نموذج اللغة الكبير (LLM) على أنها أوامر موثوقة.

تعد ميزة «استيراد مستند عبر عنوان URL» في التطبيق عرضة لهجوم تزوير الطلب من جانب الخادم (SSRF) عبر عمليات إعادة التوجيه عبر بروتوكول HTTP. على الرغم من أن الخلفية (backend) تنفذ عملية تحقق شاملة من صحة عناوين URL، إلا أنها تفشل في التحقق من صحة وجهات إعادة التوجيه. يمكن للمهاجم التحايل على إجراءات الحماية باستخدام سلسلة من عمليات إعادة التوجيه، مما يجبر الخادم على الوصول إلى خدمات داخلية. لا يتم حظر عناوين داخلية محددة لـ Docker، مثل `host.docker.internal`. تقوم نقطة النهاية `/api/v1/knowledge-bases/{id}/knowledge/url` بالتحقق من صحة عنوان URL الأولي، لكنها تتبع عمليات إعادة التوجيه عبر HTTP دون إعادة التحقق من صحة الوجهة. وهذا يسمح للمهاجمين بإرسال عنوان URL إلى نطاق يسيطر عليه المهاجم، والذي يستجيب بإعادة توجيه 307 إلى خدمة داخلية، مما يتيح الوصول إلى الخدمات الداخلية واحتمال تعرض البيانات للخطر. تقوم الدالة `IsSSRFSafeURL()` بالتحقق من صحة عنوان URL الأولي، لكنها لا تتحقق من صحة وجهات إعادة التوجيه عبر HTTP.