EUVD-2025-210427
GHSA-9mr3-76h6-25p3
Severity by source
Sources disagree (Low–High)AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N
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.
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
Lifecycle Timeline
7DescriptionNVD
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.
More in Wso2 Identity Server
View allMemory exhaustion denial-of-service in WSO2 Identity Server's Magic Link authenticator allows remote unauthenticated att
The XML parsers within multiple WSO2 products accept user-supplied XML data without properly configuring to prevent the
Due to a lack of user account state validation during authentication, locked user accounts can be successfully authentic
WSO2 Identity Server in multi-organization deployments fails to validate organization context during adaptive authentica
Reflected cross-site scripting across at least eight WSO2 platform products - including Identity Server, API Manager, AP
The authentication endpoint accepts user-supplied input without enforcing expected validation constraints, leading to a
The authentication endpoint fails to encode user-supplied input before rendering it in the web page, allowing for script
Active access tokens are not revoked or invalidated when a user account is locked within WSO2 Identity Server. This fail
The silent Just-In-Time (JIT) provisioning feature in federated authentication implementations fails to properly segrega
The check user account lock states feature within the email OTP flow fails to validate user input, allowing an attacker
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today