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

CVE-2025-13475 has a contested CVSS base score of 7.3 from a third party (e.g. CISA-ADP), while the vendor rates it High. vuln.today uses the vendor rating as authoritative.

Which versions of WSO2 Identity Server are affected by CVE-2025-13475?

WSO2 Identity Server and API Manager multi-tenant deployments are vulnerable to cross-tenant authorization bypass (no public exploit identified at time of analysis).. A patch is available.

How to fix or mitigate CVE-2025-13475?

Within 24 hours: Identify all WSO2 Identity Server and WSO2 API Manager instances running in multi-tenant mode and confirm current patch level. Within 7 days: Test the vendor-released patch in a non-production multi-tenant environment to validate tenant consent isolation. Within 30 days: Deploy the patch to all production multi-tenant instances, prioritizing customer-facing SaaS environments, and execute post-patch validation that consent granted in one tenant no longer leaks to same-named applications in other tenants.

WSO2 Identity Server CVE-2025-13475

EUVD-2025-210427 HIGH

Authentication Bypass Using an Alternate Path or Channel (CWE-288)

2026-07-04 WSO2

GHSA-9mr3-76h6-25p3

Authentication Bypass Wso2 Identity Server Wso2 Api Manager

High

Disputed · 7.3 NVD

Severity by source

Sources disagree (Low–High)

Vendor (WSO2) PRIMARY

LOW

qualitative

NVD

7.3 HIGH

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

vuln.today AI

8.7 HIGH

Network-reachable consent flow with low complexity; needs an in-tenant app registration (PR:L) and victim consent (UI:R); cross-tenant impact justifies S:C with high C/I and no availability effect.

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

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

vuln.today treats the vendor’s rating as authoritative. A higher third-party CVSS (e.g. CISA-ADP) is shown for transparency but does not drive the headline severity.

CVSS VectorNVD

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

None

Lifecycle Timeline

Analysis Updated

Jul 09, 2026 - 18:14 vuln.today

v3 (cvss_changed)

Analysis Updated

Jul 09, 2026 - 18:13 vuln.today

v2 (cvss_changed)

Re-analysis Queued

Jul 09, 2026 - 18:07 vuln.today

cvss_changed

Severity Changed

Jul 09, 2026 - 18:07 NVD

LOW HIGH

CVSS changed

Jul 09, 2026 - 18:07 NVD

3.5 (LOW) 7.3 (HIGH)

Patch available

Jul 04, 2026 - 14:01 EUVD

Analysis Generated

Jul 04, 2026 - 13:32 vuln.today

DescriptionNVD

In multi-tenanted deployments, the application consent management mechanism fails to correctly isolate consent scopes between tenants. Consent granted by a user for a specific SaaS application within one tenant can be incorrectly applied to SaaS applications with the same name in other tenants, leading to unintended cross-tenant consent sharing.

This vulnerability may result in the exposure of user data across tenants, enabling SaaS applications in different tenants to access and modify information without explicit user authorization. This can lead to unauthorized data access and privacy violations. This vulnerability has no impact if the deployment does not support multi-tenancy.

AnalysisAI

Cross-tenant consent leakage in WSO2 Identity Server and WSO2 API Manager multi-tenant deployments lets a SaaS application in one tenant inherit OAuth/OpenID consent that a user granted to a same-named application in a different tenant, breaking tenant isolation of authorization scopes. Because matching is done by application name rather than a tenant-scoped identifier, an application in attacker-controlled tenant B can read and modify a victim's data in tenant A without that user's explicit authorization. No active exploitation is reported (not in CISA KEV, EPSS 0.15%/4th percentile) and no public exploit is identified, but a vendor patch is available.

Technical ContextAI

The affected component is WSO2's application consent management within its IAM stack - WSO2 Identity Server (an OAuth2/OpenID Connect and SAML identity provider) and WSO2 API Manager (which embeds the same identity/key-manager components). Both are Java-based and support multi-tenancy, where each tenant is meant to be an isolated security domain with its own users, applications and consent records. The root cause maps to CWE-288 (authentication/authorization bypass using an alternate path/channel): consent records are keyed or resolved by SaaS application name without properly binding them to the owning tenant, so the consent lookup resolves across tenant boundaries. The result is that a granted-consent decision - intended as a per-user, per-application, per-tenant authorization - is incorrectly reused for a like-named application registered in a separate tenant.

RemediationAI

Apply the vendor-released WCP/update-level patches: upgrade WSO2 API Manager 3.2.0 to at least 3.2.0.457, WSO2 API Manager 3.2.1 to at least 3.2.1.76, and WSO2 Identity Server 5.10.0 to at least 5.10.0.382, per WSO2 advisory WSO2-2025-1613 (https://security.docs.wso2.com/en/latest/security-announcements/security-advisories/2026/WSO2-2025-1613/). Where immediate patching is not possible, reduce exposure by tightening who can register or name applications in tenants (so an attacker cannot create a SaaS application whose name collides with a target application in another tenant) and, if operationally feasible, avoiding duplicate application names across tenants; single-tenant deployments are not affected and need no action. As a stronger interim control, review and revoke existing cross-tenant consent grants and monitor consent/authorization events for same-named applications across tenants, accepting the operational overhead of manual consent auditing. These are mitigations only - the patch is the sole complete fix.