Bl4Cksku11

**Name of the Vulnerable Software and Affected Versions** Plane versions prior to 1.4.0 **Description** An issue exists in the `ProjectBulkAssetEndpoint.post` endpoint within `apps/api/plane/app/views/asset/v2.py` where assets are retrieved using `id in=asset ids` and `workspace slug=slug` without constraining the query by the `project id` provided in the URL. This allows a workspace Guest to provide asset UUIDs from a different project within the same workspace and reassign the `issue id`, `comment id`, `page id`, `draft issue id`, or `project id` to an entity controlled by the attacker. Consequently, the system recognizes the attacker's project as the new owner and generates a presigned download URL for the hijacked file. **Recommendations** Update to version 1.4.0.

**Name of the Vulnerable Software and Affected Versions** Plane versions prior to 1.4.0 **Description** Plane trusts email addresses returned by Gitea OAuth and self-managed GitLab OAuth deployments where email confirmation is disabled, without verifying that the provider authenticated ownership of the address. An attacker can set an OAuth identity's unverified provider email to a victim's address, which the system matches directly to the victim's existing local account. This allows an attacker to log in to the victim's account without knowing the password. **Recommendations** Update to version 1.4.0.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات Gitea السابقة للإصدار 1.26.2 **الوصف** توجد مشكلة تتمثل في أن نقطة نهاية فحص رمز OAuth تسمح لأي عميل OAuth تمت مصادقته باسترداد البيانات الوصفية الخاصة بالرموز الصادرة لعملاء آخرين، مما يشكل انتهاكًا للمادة 4 من RFC 7662. يفشل الخادم في التحقق مما إذا كان العميل الطالب هو المستهدف المقصود للرمز، مما يؤدي إلى إرجاع معلومات حساسة بغض النظر عن ملكيتها. **نقاط نهاية واجهة برمجة التطبيقات (API):** ’/login/oauth/introspect‘ **المعلمات أو المتغيرات المعرضة للخطر:** `token` **أسماء الوظائف:** `IntrospectOAuth()` يمكن للمهاجم الذي يمتلك عميل OAuth صالحًا استخدام نقطة النهاية هذه كمرجع للتحقق من صلاحية الرموز (token-validity oracle) للتأكد مما إذا كانت الرموز المسروقة نشطة دون تشغيل سجلات التدقيق الخاصة بالاستخدام الفعلي للرموز. بالإضافة إلى ذلك، فإنها تسمح بتعداد البيانات الوصفية عبر المستأجرين (cross-tenant metadata enumeration)، مما يمكّن المهاجم من تحديد `username` و`scope` المرتبطين بالرموز التي تنتمي إلى عملاء آخرين. **التوصيات** قم بتحديث Gitea إلى إصدار تم فيه تصحيح الدالة `IntrospectOAuth()` للتحقق من أن `grant.ApplicationID` يتطابق مع `app.ID` للعميل الطالب قبل إرجاع بيانات تعريف الرمز المميز. كحل مؤقت، قم بتقييد الوصول إلى نقطة النهاية ’/login/oauth/introspect‘ على العملاء الموثوق بهم فقط.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** Gitea الإصدار 1.26.1 **الوصف** يمكن للمستخدم الذي يمتلك أذونات الكتابة في المستودع تجاوز قائمة الامتدادات المسموح بها عند إعادة تسمية مرفقات الإصدار عبر واجهة الويب. في حين أن نقاط نهاية واجهة برمجة التطبيقات (API) تفرض تقييد `Repository.Release.AllowedTypes`، فإن معالج الويب `EditReleasePost` الموجود في `routers/web/repo/release.go` يفشل في استدعاء دالة `upload. Verify()` قبل تحديث اسم المرفق في قاعدة البيانات عبر `repo model.UpdateAttachmentByUUID()`. وهذا يسمح للمهاجم بإعادة تسمية ملف متوافق تم تحميله مسبقًا بامتداد محظور، مثل `.exe` أو `.html` أو `.svg`. ويمكن استغلال ذلك لتوزيع برامج ضارة أو استضافة هجمات البرمجة النصية عبر المواقع (XSS) المخزنة إذا كان الخادم يعرض أنواعًا معينة من الملفات بشكل مضمن. **التوصيات** قم بتحديث Gitea إلى إصدار يتم فيه تحديث دالة `UpdateRelease` الموجودة في `services/release/release.go` بحيث تتحقق من أسماء المرفقات الجديدة مقابل قائمة السماح `Repository.Release.AllowedTypes` باستخدام `upload.Verify()` قبل حفظ التغييرات. كإجراء تخفيفي مؤقت، قم بتقييد أذونات الكتابة على المستودعات التي تستخدم قائمة السماح الخاصة بالإصدارات. كإجراء تخفيفي مؤقت، قم بإزالة قائمة السماح `Repository.Release.AllowedTypes` للقضاء على إمكانية التحايل، على الرغم من أن هذا يزيل القيود الأمنية المقصودة.

**اسم البرنامج المعرض للخطر والإصدارات المتأثرة** إصدارات Daytona الأقدم من 0.184.0 **الوصف** يمكن للمستخدمين قبول أو رفض دعوات الانضمام إلى المنظمة باستخدام عنوان بريد إلكتروني مطابق للدعوة لم يتم التحقق منه. على الرغم من أن النظام يستخدم OIDC (OpenID Connect، وهي طبقة هوية فوق بروتوكول OAuth 2.0) لمطابقة البريد الإلكتروني المستهدف للدعوة مع الرمز المميز للمتصل، إلا أن مسارات قبول الدعوات ورفضها لم تفرض التحقق من البريد الإلكتروني. وهذا يسمح لمهاجم يستخدم مزود هوية يسمح بالتسجيل الذاتي ويصدر جلسات قبل التحقق، بتسجيل عنوان بريد إلكتروني مطابق لدعوة معلقة والانضمام إلى المؤسسة المستهدفة بالدور المخصص، والذي قد يصل إلى مستوى «المالك». **التوصيات** التحديث إلى الإصدار 0.184.0.