Komyunghan

توجد حالة سباق (race condition) في عملية تدوير توكن التحديث (refresh-token). يحدث هذا لأن الملف `UserRefreshToken.ts` لا يتحقق من عدد الصفوف المتأثرة أثناء التدوير. وبناءً على ذلك، يمكن للمهاجم الذي استولى على توكن تحديث تقديمه بالتزامن مع المستخدم الشرعي للحصول على جلسة مصادقة صالحة، دون تسجيل حدث إعادة استخدام.

يوجد خلل في التصريح ضمن عملية إنشاء التكامل في ملف `integrations.service.ts`. وتحديداً، تقوم آلية النسخ بفك تشفير بيانات اعتماد الاتصال لتكامل مصدر دون التحقق من المالك أو علامة الحالة الخاصة. يمكن للمستخدمين المصرح لهم والذين يمتلكون دور Creator استغلال ذلك عن طريق تقديم معرفات تكامل مُخمنة أو مُعددة لنسخ مضيف قاعدة البيانات واسم المستخدم وكلمة المرور الخاصة بمستخدمين آخرين إلى تكامل يمتلكونه.

يوجد خلل في إدارة الامتيازات في `org-users.service.ts` حيث يؤدي تحديث دور المنظمة القديم للمستخدم إلى إعادة كتابة دور `default-workspace` الخاص به. يتيح ذلك للمستخدمين الذين تم سحب صلاحياتهم استعادة وصول مستوى المنشئ (Creator) للقراءة والكتابة وتعديل المخطط عبر جميع قواعد `default-workspace` باستخدام رمز الجلسة الحالي الخاص بهم.

توجد مشكلة في التصريح غير الصحيح حيث تعمل رموز API المحددة بنطاق القاعدة كبيانات اعتماد على مستوى الحساب بالكامل. يحدث هذا لأن `base id` المرتبط بالرمز لا يتم تخزينه أو التحقق منه. وبناءً على ذلك، يمكن للمهاجم الذي يحوز على رمز مسرب قراءة وكتابة وحذف السجلات في كل قاعدة ينتمي إليها مالك الرمز، بما في ذلك القواعد التي تم الانضمام إليها لاحقاً.

Insufficient route-level permission checks and a lack of workspace or ownership validation in the backing service allow authenticated low-privilege users or those with a valid API key to access or delete document-store upsert history from other users and workspaces. This occurs when the target `chatflowId` (publicly exposed in share links) or row IDs are known. The issue involves the endpoints "GET /api/v1/upsert-history/:id" and "PATCH /api/v1/upsert-history", specifically within the `getAllUpsertHistory()` and `patchDeleteUpsertHistory()` functions. The `getAllUpsertHistory()` function returns rows based on an attacker-supplied `chatflowid`, while `patchDeleteUpsertHistory()` deletes rows using an attacker-supplied array of record UUIDs. Exposed data in the `flowData` and `result` fields may include embedding, record-manager, and vector-store node configurations, including per-node `paramValues`.

Insufficient validation of `organizationId` ownership in database write and destroy routes allows users with the builder role to perform unauthorized actions on databases belonging to other organizations. Due to missing organization-resolving guards, an attacker can create, modify, or permanently delete tables and schemas across tenant boundaries on shared instances.

An issue exists where organization membership is not validated in database read routes. This allows any authenticated user to access table schemas and row data belonging to other organizations. An attacker can provide arbitrary organization IDs in URL parameters to list tables, retrieve column definitions, and execute join queries to read stored data from victim organizations.

يحتوي Budibase على خطأ في تكوين التفويض على مستوى المسار، حيث تم تعيين نقطة النهاية ”PUT /api/datasources/:datasourceId“ بشكل غير صحيح إلى مجموعة `authorizedRoutes` مع أذونات `TABLE/READ` بدلاً من مجموعة `builderRoutes`. وهذا يسمح لأي مستخدم تمت مصادقته ولديه الدور المدمج `BASIC` أو أعلى بإرسال طلبات لإعادة كتابة كائن `config` لمصدر البيانات، بما في ذلك `host` و`port` وبيانات اعتماد قاعدة البيانات أو عنوان `url` الأساسي لمصدر بيانات REST. نظرًا لأن اتصالات برامج تشغيل SQL تفتقر إلى الحماية على مستوى الشبكة من تزوير الطلبات من جانب الخادم (SSRF) — وهي تقنية يُجبر فيها المهاجم الخادم على إرسال طلبات إلى موقع غير مقصود — فإن إعادة توجيه مصدر بيانات PostgreSQL أو MySQL أو MongoDB إلى عنوان IP داخلي يسمح للمهاجم باستكشاف الخدمات الداخلية أو التفاعل معها على منافذ عشوائية. بالإضافة إلى ذلك، يمكن استخدام هذا لتعطيل الخدمة عن طريق إدخال تكوينات غير صالحة، مما يتسبب في حدوث هجوم «رفض الخدمة» (DoS) لجميع استعلامات التطبيق التي تعتمد على مصدر البيانات هذا.