WSO2 Identity Server EUVD-2025-210627

Three conditions must simultaneously be true: secondary user stores must be actively configured in the WSO2 Identity Server deployment; the implicit association feature must be enabled (it is not enabled by default in all configurations - verify deployment settings); and the same lookup claim value (e.g., the exact same email address or username) must exist in both the primary user store and at least one secondary user store. External IDP authentication must be in use, as implicit association is only invoked during federated login flows. The practical limiting factor is claim collision: in environments that enforce globally unique email addresses or usernames across all directories (primary and secondary), the resolver's incorrect ordering produces no observable effect. Exploitation is further constrained by the requirement for UI:R - a legitimate user or an attacker must actively initiate an authentication attempt through the external IDP to trigger the flawed resolution path. Environments with read-only secondary stores where claim values cannot be influenced by external parties have a significantly reduced adversarial risk profile.

The vendor-assigned CVSS 3.1 score of 4.3 (Medium) with vector AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L frames this primarily as an availability concern - legitimate users may be restricted from their expected resources. However, the 'Authentication Bypass' tag signals a potentially more impactful exploitation path: if an adversary can place an account with a matching claim value into a secondary user store (e.g., via self-registration, a compromised directory, or administrative access to a secondary LDAP), they could capture an IDP association intended for a primary-store user, which has integrity implications the CVSS vector does not fully capture. The I:N metric therefore may underrepresent risk in environments where secondary stores can be written to by non-administrators. AC:L is credible - no race condition or special timing is required; the resolver's incorrect behavior is deterministic whenever conditions are met. PR:N reflects that the triggering subject is the external IDP user authenticating normally. No EPSS data was supplied; without it, exploitation probability cannot be quantified. The absence from CISA KEV and the absence of public exploit code both reduce urgency. Real-world priority depends heavily on whether secondary stores in a given deployment allow claim values that can collide with primary-store accounts - environments with tightly controlled, globally unique claim namespaces are not functionally at risk.

An attacker who can register or insert an account into a secondary user store with an email address identical to a high-privilege administrator in the primary store waits for that administrator to authenticate through an external IDP. The implicit-association resolver, starting from the secondary store, matches the email claim to the attacker's lower-privilege (or attacker-controlled) secondary account and permanently links the IDP identity to it, denying the legitimate administrator their expected access and potentially allowing the attacker to later authenticate via that IDP link. No public exploit code is known, but the deterministic nature of the resolver bug means the scenario requires no advanced exploitation technique - only the ability to insert a matching claim into a secondary store.