Livio-A

تعاني واجهة مستخدم Login V2 من ثغرة حقن ترويسة المضيف (host header injection). يمكن للمهاجمين غير المصرح لهم تسميم روابط إعادة تعيين كلمة المرور، والدعوات، وروابط التحقق من البريد الإلكتروني عن طريق تقديم قيم غير موثوقة في ترويسات `x-zitadel-public-host` أو `x-zitadel-forward-host` أو `x-forwarded-host`. إذا عرف المهاجم اسم تسجيل دخول الضحية، فيمكنه توجيه الروابط في رسائل البريد الإلكتروني الأصلية إلى مضيف تابع له، وجمع الرموز ذات الاستخدام الواحد عند فتح الروابط، والاستيلاء على الحسابات بما في ذلك حسابات مسؤولي المثيل.

يحتوي Login V2 على مشكلة نقص في التفويض تسمح للمهاجمين بالموافقة على تفويضات أجهزة OAuth 2.0 باستخدام جلسة قائمة للضحية دون موافقتها. من خلال إرسال رابط لمستخدم مسجل الدخول يحتوي على رمز مستخدم المهاجم، يمكن للمهاجم الحصول على رموز الضحية وتجاوز إعدادات الوصول إلى المشروع عبر واجهة برمجة تطبيقات تفويض جهاز OIDC.

يوجد خلل في تجاوز المصادقة في واجهة مستخدم Login V2 يسمح للمهاجمين غير المصرح لهم بالسيطرة على حسابات المستخدمين الذين لم يقوموا بإعداد أي وسيلة مصادقة بعد. من خلال حساب ملف تعريف ارتباط `verificationCheck` صالح باستخدام معرف المستخدم وبصمة المتصفح، يمكن للمهاجم تعيين كلمة مرور، أو تسجيل مفتاح مرور (passkey)، أو ربط مزود هوية بالحساب المستهدف.

توجد مشكلة في تصعيد الامتيازات في عملية تبادل رموز OIDC. تسمح هذه الثغرة للمستخدمين الذين لديهم أدوار `IAM END USER IMPERSONATOR` أو `ORG END USER IMPERSONATOR` بتجاوز فحص `admin.impersonation`. وبناءً على ذلك، يمكن لهؤلاء المستخدمين انتحال صفة المسؤولين، بما في ذلك أولئك الذين لديهم دور `IAM OWNER` وتسجيل الدخول إلى التطبيقات المعتمدة بأدوار ومطالبات إدارية.

يوجد تجاوز للمصادقة في استدعاء (callback) نية مزود هوية SAML. يقوم النظام بالتحقق من توقيع التأكيد باستخدام المزود المحدد في عنوان URL للطلب، ولكنه يحدد المستخدم من نية تسجيل الدخول دون التحقق من تطابقهما. يتيح ذلك للمهاجمين الذين لديهم صلاحيات مسؤول المؤسسة تسجيل مزود SAML باستخدام مفتاح التوقيع الخاص بهم للحصول على جلسات مصادقة لأي مستخدم مرتبط بمزود SAML آخر على المثيل، بما في ذلك المستخدمين في مؤسسات أخرى.

يوجد خلل في تجاوز المصادقة في واجهة مستخدم Login V2. يمكن للمهاجمين غير المصرح لهم الحصول على رموز جلسات مستخدمين آخرين عن طريق تزوير ملفات تعريف ارتباط جلسة غير موقعة. من خلال تخمين معرفات الجلسات المرتبة زمنياً المرتبطة بتسجيل دخول الضحية وتقديم رموز فارغة، يمكن للمهاجمين تلقي رموز مدورة. يسمح هذا بالسيطرة الكاملة على الحسابات، بما في ذلك جلسات المسؤولين الذين أكملوا بالفعل المصادقة متعددة العوامل (MFA)، وهي عملية أمنية تتطلب عاملين أو أكثر من عوامل التحقق.

Authenticated users can tamper with their own IdP intent tokens due to the use of unauthenticated, malleable encryption. This allows a user to modify a token so it is accepted for another user's external login intent. An attacker who predicts a victim's in-flight intent identifier and wins a timing race can use the '/v2/idp intents' or '/v2/sessions' endpoints to steal IdP tokens or hijack a session.

A missing authentication flaw exists in the hosted Login V1 UI. The second-factor enrollment and initialization handlers process identify-only sessions before the primary factor is verified. An attacker with knowledge of a victim's login name can enroll attacker-controlled TOTP, OTP-SMS, OTP-Email, or U2F factors, overwrite the verified phone number, and enumerate users by analyzing discrepant error messages.

An authentication bypass exists in Login V2 that allows unauthenticated attackers to take over accounts. Attackers who know the login name of a victim enrolled in OTP-Email and OTP-SMS can obtain One-Time Password (OTP) codes through the `returnCode` delivery type by reading them from server-action responses. This allows the attacker to establish MFA-authenticated sessions, which may include the takeover of administrator accounts.

An authentication bypass exists in the hosted Login V1 and Login V2 UIs. The system allows the enrollment of a passkey or other authenticator during identify-only login sessions before a primary factor is verified. An unauthenticated attacker who knows a victim's login name can register an attacker-controlled authenticator to gain unauthorized access to the account, bypassing passwords and multi-factor authentication (MFA).

Login V2 authentication fails to verify the inactive state of an organization, checking only the status of the individual user. This allows users belonging to a deactivated organization to sign in, create sessions, and obtain or refresh tokens if they possess valid credentials, an existing session, or a refresh token.

An issue exists where the server can be coerced into making requests to internal resources during organization domain HTTP verification. This occurs because the challenge fetch process utilizes the default `http.Get` function in Go instead of a protected client. Attackers can register domains that redirect to loopback, internal, or cloud metadata addresses, enabling them to scan ports and map internal networks. This is a server-side request forgery (SSRF), which is a flaw that allows an attacker to induce the server-side application to make requests to an unintended location.

An authentication bypass exists in the hosted Login V1 UI. The issue occurs because the registration endpoint for external accounts not found trusts external identity fields provided by the client without requiring a completed Identity Provider (IdP) callback. An unauthenticated attacker can submit forged `IDPConfigID` and `ExternalUserID` values to pre-create an account linked to a victim's external IdP identity. When the victim subsequently performs a legitimate external login, they are signed into the pre-created account.

An incorrect authorization flaw exists in the User Service API. The system verifies the `user.read` permission against the caller's organization instead of the organization that owns the target user. An authenticated member with org-scoped `user.read` permissions can use the 'GET /v2/users/{userId}/authentication methods' endpoint to identify the authentication method types registered by users in other organizations.

An issue exists where links are created between user accounts and external identity providers without verifying a primary factor or the caller's permission. This occurs during identify-only Login V2 sessions and via the User Service V2 'AddIDPLink' endpoint. An unauthenticated attacker who knows a victim's login name can bind their own external identity provider identity to the victim's account to hijack it and sign in as the victim.

اسم البرنامج المعرض للخطر والإصدارات المتأثرة ZITADEL الإصدارات الأقدم من 3.4.7 ZITADEL الإصدارات الأقدم من 4.11.1 الوصف كان برنامج ZITADEL، وهو منصة مفتوحة المصدر لإدارة الهوية، يعاني من ثغرة في ميزة الإدارة الذاتية. وكان ذلك يسمح للمستخدمين بوضع علامة «تم التحقق» زوراً على عناوين بريدهم الإلكتروني وأرقام هواتفهم دون إتمام عملية التحقق. تم حل المشكلة من خلال تطبيق إجراءات التحقق المناسبة من الأذونات عند تعيين علامة التحقق، وتقييد ميزة الإدارة الذاتية على عنوان البريد الإلكتروني و/أو رقم الهاتف نفسه. التوصيات قم بالتحديث إلى الإصدار 3.4.7 من ZITADEL أو أحدث. قم بالتحديث إلى الإصدار 4.11.1 من ZITADEL أو أحدث. إذا تعذر التحديث، فاستخدم إجراءً (v2) لمنع تعيين علامة التحقق في حسابات المستخدمين.

تحتوي واجهة برمجة تطبيقات (API) إدارة الجلسات في ZITADEL على ثغرة أمنية تسمح للمستخدم المصادق عليه بتحديث جلسة العمل بمجرد معرفة معرّف الجلسة (ID)، وذلك بسبب عدم وجود تحقق من الأذونات. وهذا يتيح اختطاف الجلسة، مما يسمح للمهاجم بالانتحال صفة مستخدم آخر والوصول إلى الموارد الحساسة.

Zitadel's user account deactivation mechanism did not work correctly with service accounts. Deactivated service accounts retained the ability to request tokens, which could lead to unauthorized access to applications and resources.

Zitadel is an open source identity management platform. The user grants deactivation mechanism did not work correctly, allowing deactivated user grants to be provided in tokens. This could lead to unauthorized access to applications and resources. The management and auth API always returned the state as active or did not provide any information about the state.

Zitadel is an open source identity management system. The system has a setting called "Ignoring unknown usernames" which helps mitigate attacks that try to guess or enumerate usernames. If enabled, Zitadel will show the password prompt even if the user doesn't exist and report "Username or Password invalid". However, due to an implementation change to prevent deadlocks calling the database, the flag would not be correctly respected in all cases, and an attacker would gain information if an account exists within Zitadel, since the error message shows "object not found" instead of the generic error message.