Tags: zitadel/zitadel
Tags
fix(login v1): update password verification handling (#11202) # Which Problems Are Solved Failed password attempts in login V1 potentially created new session entries. # How the Problems Are Solved Correct handling to only update existing sessions. # Additional Changes None # Additional Context - reported through support - requires backport to v4.x (cherry picked from commit d79bfe6)
fix(login): CVE-2025-55184 and CVE-2025-55183, update next (#11179) # Which Problems Are Solved Updates `next` to version `15.5.9` to address the following security vulnerabilities: - **CVE-2025-55184** - **CVE-2025-55183** # How the Problems Are Solved - Bump `next` from `15.5.7` to `15.5.9` in `apps/login/package.json` --------- Co-authored-by: PhenixH <PhenixH@users.noreply.github.com> (cherry picked from commit 2221b5e)
fix(setup): member role synchronization execution check (#11180) The change was introduced in #11178. The fix is to prevent wiping the memberships because the projection did not init yet. ### Changes - Introduces a check to determine if the member role synchronization should be executed based on the existence of a specific database table (`projections.instance_members4`). - Ensures that the synchronization process only runs if the required table is present in the database. (cherry picked from commit 1b54a9e)
fix(fields): sync membership roles from projections (#11178) # Which Problems Are Solved Zitadel v4.7.2 fixed a security issue by switching to the permission v2 framework for user APIs. It appears that systems that are running since before v2.68 that were affected by a precision bug in the eventstore, which was fixed in that version. The precision bug results in certain events being "skipped" while being projected into the fields table, used by the new permission system. This caused certain membership roles to be missing, resulting in empty user lists when executed by the affected member. The permission system basically finds no matching memberships and therefore returns no users at all. # How the Problems Are Solved After research we concluded that the legacy membership projections are projected correctly. This PR synchronizes the projected state into the fields table. As the membership roles are not marked unique, all rows are first deleted and then the correct membership roles are then inserted. The operation happens in a single transaction, during which the fields table will remain locked for modifications. This to prevent possible concurrent modifications to membership states. # Additional Changes - none # Additional Context - Introduced in 0e17d00 - Released in [v4.7.2](https://github.com/zitadel/zitadel/releases/tag/v4.7.2) - Related: #8863 --------- Co-authored-by: Silvan <27845747+adlerhurst@users.noreply.github.com> (cherry picked from commit 58612a6)
fix: Force v2 permission checks on user listing # Which Problems Are Solved When the feature flag for enabling permission checks v2 is disabled, a user without permission could list users across instances and get the total number of users available. # How the Problems Are Solved Disregard the state of the feature flag and always enforce permission checks v2 on v2 APIs. --------- Co-authored-by: Livio Spring <livio.a@gmail.com> (cherry picked from commit 826039c)
fix: Force v2 permission checks on user listing # Which Problems Are Solved When the feature flag for enabling permission checks v2 is disabled, a user without permission could list users across instances and get the total number of users available. # How the Problems Are Solved Disregard the state of the feature flag and always enforce permission checks v2 on v2 APIs. --------- Co-authored-by: Livio Spring <livio.a@gmail.com> (cherry picked from commit 826039c) (cherry picked from commit 0e17d00)
fix(login): Organization Discovery for Login Without Org Context (#10996 ) # Which Problems Are Solved When users accessed the login page without an organization context and entered a login name with a domain suffix (e.g., [user@company.com], the system would return "user not found" instead of performing organization discovery. # How the Problems Are Solved Added organization discovery logic that triggers after a global user search returns no results. When no organization context is provided: - Extracts the domain suffix from the loginName (e.g., @company.com) - Queries for organizations with that domain as their primary domain - If exactly one organization is found with allowDomainDiscovery enabled, uses it as the discovered organization - Redirects users to the appropriate flow (IDP, registration, or password) with the discovered organization context --------- Co-authored-by: Ramon <mail@conblem.me> (cherry picked from commit 7579136)
fix: validate IDP linking conditions # Which Problems Are Solved When auto-linking was enabled on an IdP, there was no check if linking to the found user is allowed, i.e. if the corresponding IdP is active in the user's organization or if external authentication in general was allowed. # How the Problems Are Solved - (Re)Check the login policy of the user's organization before linking the external identity. # Additional Changes None # Additional Context None --------- Co-authored-by: Max Peintner <peintnerm@gmail.com> (cherry picked from commit 33c51de)
fix: validate IDP linking conditions # Which Problems Are Solved When auto-linking was enabled on an IdP, there was no check if linking to the found user is allowed, i.e. if the corresponding IdP is active in the user's organization or if external authentication in general was allowed. # How the Problems Are Solved - (Re)Check the login policy of the user's organization before linking the external identity. # Additional Changes None # Additional Context None --------- Co-authored-by: Max Peintner <peintnerm@gmail.com> (cherry picked from commit 33c51de)
PreviousNext