What is the CVSS score of CVE-2025-11850?

CVE-2025-11850 has a CVSS 3.1 base score of 4.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L. EPSS exploitation probability: 0.2%.

Is there a patch available for CVE-2025-11850?

Yes, a patch is available for CVE-2025-11850. Update the affected software to the latest version immediately.

WSO2 Identity Server CVE-2025-11850

EUVD-2025-210627 MEDIUM

Authorization Bypass Through User-Controlled Key (CWE-639)

2026-08-06 WSO2

GHSA-25wv-6jh5-5g7f

Authentication Bypass Wso2 Identity Server Token Exchange Grant Type For Oauth Wso2

4.3

CVSS 3.1 · Vendor: WSO2

Severity by source

Vendor (WSO2) PRIMARY

4.3 MEDIUM

AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L

vuln.today AI

5.4 MEDIUM

Added I:L over vendor's I:N because incorrect IDP account association constitutes an integrity violation; all other metrics align with the described behavior.

3.1 AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L

4.0 AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N

Primary rating from Vendor (WSO2).

CVSS VectorVendor: WSO2

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

Low

Lifecycle Timeline

Patch available

Aug 06, 2026 - 09:01 EUVD

Analysis Generated

Aug 06, 2026 - 08:31 vuln.today

CVE Published

Aug 06, 2026 - 07:33 cve.org

MEDIUM 4.3

DescriptionCVE.org

When secondary user stores are configured, the implicit-association resolver incorrectly initializes from a secondary user store and bypasses the primary user store during search and uniqueness checks. This allows a subject to be associated with an unintended local account if the same lookup claim (e.g., username or email) exists in both the primary and a secondary store.

If duplicate claim values exist across user stores, this issue can lead to identity confusion due to incorrect implicit associations when using an external Identity Provider (IDP). Legitimate user accounts in the primary user store may fail to associate correctly with their corresponding external IDP accounts, potentially restricting access if the secondary account has fewer privileges. Deployments are not affected if no secondary user stores are configured, implicit association is disabled, or claim values are globally unique.

AnalysisAI

WSO2 Identity Server's implicit-association resolver incorrectly initializes from a secondary user store rather than the primary store when multiple user stores are configured, causing identity confusion during external IDP authentication flows. When the same lookup claim - such as a username or email address - exists in both the primary and a secondary store, an external IDP subject is silently associated with the wrong local account, either denying legitimate users their expected access level or, in adversarially constructed scenarios, potentially hijacking an IDP association intended for a primary-store user. The vulnerability is only triggered when secondary user stores are active, implicit association is enabled, and duplicate claim values exist across stores - deployments not meeting all three conditions are unaffected. No public exploit code has been identified at time of analysis and the issue is not listed in the CISA KEV catalog.

Technical ContextAI

WSO2 Identity Server is an enterprise-grade Identity and Access Management (IAM) platform supporting federated authentication via external Identity Providers (IDPs) through standards such as OIDC and SAML. The affected mechanism, implicit association, automatically links an incoming IDP subject to an existing local account by matching a configurable claim - typically email or username - without requiring an explicit linking step by the user. The resolver is responsible for searching user stores in the correct priority order (primary first, secondary second) to ensure uniqueness and prevent cross-store ambiguity. The defect is a logic initialization error: when secondary stores are present, the resolver starts its search in the secondary store, meaning a claim match there short-circuits any check against the primary store. The CPE strings confirm two affected products: wso2:wso2_identity_server (all tracked versions) and wso2:token_exchange_grant_type_for_oauth (all tracked versions), the latter indicating the flaw also surfaces in OAuth 2.0 token exchange flows. No CWE was assigned by the reporter, but the root cause aligns most closely with CWE-706 (Use of Incorrectly-Resolved Name or Reference) or CWE-287 (Improper Authentication) given the misordered store resolution that undermines identity uniqueness guarantees.

RemediationAI

Consult WSO2 Security Advisory WSO2-2025-4493 (https://security.docs.wso2.com/en/latest/security-announcements/security-advisories/2026/WSO2-2025-4493/) for the vendor-released patch; the exact fixed version is not specified in the currently available data and should be confirmed directly from that advisory before upgrading. If patching is not immediately possible, three compensating controls exist with distinct trade-offs: first, disable implicit association entirely - this eliminates the attack surface but requires users to manually link their IDP accounts, adding friction for all federated users; second, enforce globally unique claim values across all configured user stores by auditing and removing or renaming duplicate usernames and email addresses - this removes the collision condition but is operationally intensive and must be maintained as an ongoing control; third, remove or deconfigure secondary user stores if they are not operationally required - this is the most complete workaround but may break integrations that depend on those stores. Organizations that have already ensured claim-value uniqueness across stores, disabled implicit association, or run without secondary user stores are not exposed and need no immediate action.