Wso2 Identity Server
Monthly
OAuth token revocation in WSO2 Identity Server fails to invalidate access and refresh tokens for accounts whose usernames contain mixed-case characters when the deployment pairs a case-insensitive user store with a case-sensitive identity database. An authenticated attacker (PR:L) who already holds a valid, unexpired token for such an account can keep using it for actions that should have been blocked after a revocation-triggering lifecycle event, bounded by the token's natural expiry. Affected deployments are a non-default configuration subset, the trigger requires that specific store/database mismatch plus a mixed-case username, and no public exploit has been identified at time of analysis; the input 7.4 score assumes AC:L, whereas the assessed vector uses AC:H, so real-world risk is materially lower than the headline number suggests.
Cached OAuth2 introspection responses in WSO2 API Manager, WSO2 Identity Server and related WSO2 identity/gateway products can cause a revoked access token to be returned to the client again until the cache entry is cleared, but only when the allowed_scopes configuration is enabled. An authenticated OAuth2 client able to call both the introspection and revocation endpoints must also hit a narrow ordering window - introspecting a token immediately before revoking it - which is why the issue is rated low (CVSS 3.1, AV:N/AC:H/PR:L, C:N/I:N/A:L). The re-issued token is not accepted for API authorization, so there is no confidentiality or integrity loss; the practical effect is a limited availability/authentication-flow disruption, since affected users may be unable to obtain a new valid token until the cache is flushed. No public exploit code and no active exploitation have been identified at time of analysis, and the priority decision is monitor.
Reflected cross-site scripting (CWE-79) affects WSO2's authentication endpoint, which echoes unsanitized request data into error messages; per the vendor advisory, default configurations of WSO2 API Manager, WSO2 API Control Plane, and WSO2 Identity Server are impacted. An unauthenticated remote attacker must convince a victim to follow a crafted link (UI:R), after which injected script runs in the WSO2 origin and can redirect the user, alter the page interface, or read script-accessible information. Because session-related cookies carry the httpOnly flag, the vendor explicitly notes that session hijacking and cookie theft are not possible, keeping this at medium severity (CVSS 6.1); no public exploit or active exploitation is identified at time of analysis.
Server-side request forgery in WSO2 API Manager and related WSO2 products lets a remote attacker direct the server to arbitrary internal or external network locations and to filesystem resources reachable from the WSO2 host. The vendor CVSS vector requires low-level privileges (PR:L), while the advisory text claims an unauthenticated actor can exploit the flaw, so the authentication barrier is unresolved and should be confirmed with WSO2. No public exploit identified at time of analysis, no CISA KEV entry is present in the supplied data, and the issue is prioritized for handling this week.
The system fails to invalidate existing access tokens associated with sub-organization users during sensitive account management operations such as password reset, role change, or sub-organization disablement. This oversight allows previously issued tokens to remain active even after the user's access context has been modified or revoked through administrative actions. The identified issue could lead to unauthorized access by a malicious actor, but only when all of the following conditions are met: previously issued access tokens remain active, and these tokens have been exposed to malicious actors.
WSO2 Carbon OAuth, as shipped in WSO2 Identity Server, API Manager, and related WSO2 products, can leave session-bound tokens valid after the user session ends when token binding validation is enabled and the 'Revoke token upon user logout' option is inactive. An attacker who already possesses such a token can retain access to protected applications and data after logout; this is a moderate, conditionally exploitable session-management flaw that requires a non-default configuration and prior token acquisition, and no public exploit code or active exploitation is identified at time of analysis.
Username enumeration in WSO2 Identity Server allows unauthenticated remote attackers to distinguish valid accounts from invalid ones by observing inconsistent responses from the authentication endpoint when a supplied username does not exist. The issue affects deployments using the Email OTP Authenticator and WSO2 Carbon Abstract OTP Authenticator, and it is a low-to-moderate severity information-disclosure flaw (CVSS 5.3) rather than a direct path to credential theft, data access, or code execution. No public exploit code was identified at time of analysis, and the practical risk comes from chaining discovered usernames with brute-force, password-spraying, or social-engineering campaigns.
The SCIM provisioning endpoints in WSO2 Identity Server, Identity Server as Key Manager, and Open Banking IAM fail to disambiguate between a local user and a federated user that share the same username, so a federated identity can be acted upon as if it were the colliding local account. An attacker who can authenticate as a federated user - and who either already holds a federated identity matching a target's username or can self-register one where self-registration is enabled - can reach the SCIM 2.0 or SCIM 1.1 user endpoints and perform arbitrary operations against the local user store, up to and including account takeover; deployments without self-registration are rated medium severity by the vendor because the collision must be pre-arranged. Exploitation requires authentication as a federated user and a reachable SCIM endpoint, and no public exploit code or confirmed active exploitation was identified at time of analysis; the vendor's own CVSS of 8.2 uses a PR:N vector while our assessment treats the federated-user requirement as PR:L, giving 8.1-equivalent integrity impact with limited confidentiality exposure.
Cleartext storage of remote log server credentials, truststore passwords, and keystore passwords in WSO2 API Manager and related WSO2 products lets high-privileged authenticated Management Console users or anyone with direct read access to product files recover secrets when remote logging is enabled. The flaw is medium severity (CVSS 4.9, CWE-312) and limited to confidentiality; it can enable manipulation of log entries and compromise of the remote log server after credentials are obtained. No public exploit was identified at time of analysis, and deployments without remote logging enabled are not exposed through this path.
WSO2 Identity Server exposes a user-enumeration weakness in its SMS OTP login flow: the error messages returned when the OTP challenge is initiated differ depending on whether the supplied account exists, giving unauthenticated remote attackers a way to confirm valid usernames. The signal is strongest for accounts that have no mobile number registered, which produce a distinct response. No public exploit code or CISA KEV entry was identified at time of analysis, and the CVSS 3.1 score is only 3.7 — the practical value to an attacker is the harvested username list, which feeds later brute-force and social-engineering campaigns rather than yielding direct compromise.
The self-registration flow in WSO2 Identity Server and related WSO2 identity/API management products returns a distinct error when a submitted username already exists, letting unauthenticated users enumerate valid accounts. Any remote party who can reach the self-registration endpoint can harvest a list of confirmed usernames, which then feeds credential-stuffing, brute-force, and targeted phishing campaigns. Rated CVSS 5.3 (medium) with confidentiality-only impact; no public exploit code or active exploitation is identified in the supplied data at time of analysis.
OS command injection (CWE-78) in WSO2's shared Carbon Console administrative interface allows an authenticated administrator with adjacent network access to execute arbitrary operating system commands, leading to complete compromise of the affected system. The vulnerability spans at least eight WSO2 middleware products - including API Manager, Identity Server, Open Banking components, Traffic Manager, Universal Gateway, and API Control Plane - all of which share the Carbon Console administrative layer. The CVSS scope-change flag (S:C) indicates that successful exploitation extends impact beyond the WSO2 application boundary to the underlying host and potentially adjacent systems.
Authentication bypass in WSO2 Identity Server and multiple WSO2 platform products (API Manager, Open Banking AM/IAM/KM, Traffic Manager, Universal Gateway, API Control Plane, Identity Server as Key Manager) lets an attacker skip intermediate multi-factor challenges when the Conditional (Adaptive) Authentication script is configured with a particular multi-step callback/re-execution pattern, resulting in unauthorized takeover of a targeted user account. The flaw stems from the adaptive script failing to enforce completion of all required steps, and carries a high CVSS of 9.4 (C:H/I:H). There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the affected components underpin enterprise SSO/MFA and open-banking IAM, making impact severe where the vulnerable flow exists.
Sensitive information disclosure in WSO2's Carbon Event Publisher Core affects nine WSO2 platform products, including API Manager, Identity Server, and Open Banking components. When an Event Publisher output adapter is misconfigured with extraneous or irrelevant properties, those property values - which may include user credentials or confidential data - are written to the wso2carbon log files without sanitization or masking (CWE-532). A local, high-privileged actor with read access to those log files can extract the inadvertently logged secrets and leverage them for unauthorized access. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.
CSRF in the WSO2 Carbon console Ajax processor enables an attacker to silently execute unauthorized state-changing operations on behalf of authenticated administrators across more than ten WSO2 products including Identity Server, API Manager, and Enterprise Integrator. The vulnerability combines two compounding weaknesses: state-altering operations are routed over HTTP GET, and the sole CSRF mitigation - SameSite=Lax - is defeated because browsers permit session cookies to accompany cross-origin top-level GET navigations. No public exploit code has been reported and this CVE does not appear in CISA KEV at time of analysis; however, the breadth of affected WSO2 products and the IAM/API management context make misconfigured internet-exposed deployments a meaningful target for targeted social engineering.
Tenant isolation failure in WSO2 Identity Server allows authenticated low-privilege users to disclose personally identifiable information belonging to users in separate tenants. The vulnerability exists specifically when Email OTP, SMS OTP, or Magic Link are configured as first-factor authenticators - authentication requests processed through these flows lack sufficient validation to enforce organizational tenant boundaries, exposing data such as mobile numbers. No public exploit code or CISA KEV listing exists at time of analysis, but the low-complexity, network-accessible attack vector (CVSS PR:L/AV:N/AC:L) makes this a credible insider threat and compromised-account scenario for multi-tenant deployments.
Insufficient refresh token invalidation in WSO2 Identity Server's user impersonation flow allows a privileged attacker who has already obtained an impersonated access token to silently renew that authorization via the OAuth refresh token grant, sustaining unauthorized access well beyond the intended session lifetime. The integrity impact is two-fold: the attacker continues performing actions on behalf of the legitimate user, and audit logs attribute those actions to the victim identity rather than the true actor, corrupting traceability and compliance posture. No public exploit is identified and exploitation is bounded by high privilege prerequisites (PR:H) and adjacent network access (AV:A), placing realistic risk firmly in insider-threat and compromised-administrator scenarios.
Cross-organizational secret deletion in WSO2 Identity Server's Secret Type Management REST API allows an administrator with delete permissions to inadvertently remove secrets across all organizations in a multi-tenant deployment. The on-delete cascade logic, triggered when a secret type is deleted, fails to enforce organizational boundaries - a multi-tenancy isolation failure classified as CWE-281 (Improper Preservation of Permissions). Exploitation yields availability and integrity impact across the entire deployment, though it is constrained to high-privilege administrator accounts. No public exploit is identified and this vulnerability is not listed in the CISA KEV catalog.
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.
Username enumeration via observable login response discrepancy affects WSO2 Identity Server, WSO2 Identity Server as Key Manager, WSO2 API Manager, WSO2 Open Banking AM, and WSO2 Open Banking IAM when the Multi-Attribute Login feature is enabled. When a valid username is submitted, the server resolves and returns the canonical form of that username; when an invalid username is submitted, the server echoes the raw input unchanged - creating a deterministic, scriptable oracle for account existence. This disclosure path persists regardless of the validate_username configuration setting, meaning a common hardening measure provides no defense. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Reflected cross-site scripting across at least eight WSO2 platform products - including Identity Server, API Manager, API Control Plane, Traffic Manager, Universal Gateway, Open Banking AM/IAM, and Identity Server as Key Manager - allows unauthenticated remote attackers to inject arbitrary script via unsanitized URL parameters. An attacker who tricks an authenticated user into clicking a crafted link can redirect the victim to a malicious site, tamper with rendered page content, or exfiltrate non-session browser data; partial mitigation is provided by httpOnly flags on session cookies, which block direct session token theft. No public exploit identified at time of analysis; WSO2 self-reported the issue and published advisory WSO2-2025-4343.
The silent Just-In-Time (JIT) provisioning feature in federated authentication implementations fails to properly segregate user roles during account creation when a federated user shares a username. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
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.
Memory exhaustion denial-of-service in WSO2 Identity Server's Magic Link authenticator allows remote unauthenticated attackers to crash the authentication service by flooding invalid login requests without rate limiting. The vulnerability affects deployments using the Magic Link authentication flow and has an EPSS score indicating moderate exploitation likelihood. WSO2 has published a security advisory (WSO2-2025-4469) with remediation guidance for affected Identity Server and Carbon MagicLink Authenticator Module installations.
Adaptive authentication flows in WSO2 Identity Server 7.1.0 (up to 7.1.0.26) and the Conditional Authentication User and Roles Related Functions module 1.2.76 (up to 1.2.76.1) fail to validate the organization context in which they execute, allowing authentication logic configured for one organization to run against other organizations and sub-organizations. An attacker who already holds privileges to configure adaptive authentication within at least one tenant can therefore cross tenant authorization boundaries to perform critical operations, escalate privileges, and potentially take over accounts in other organizations - an authenticated, high-privilege prerequisite (CVSS:3.1/AV:N/AC:L/PR:H/UI:N) that limits the realistic attacker set to insiders or compromised tenant administrators. Exploitation requires a multi-organization deployment with adaptive authentication enabled; EPSS is low at 0.02% (6th percentile), SSVC records Exploitation: none and Automatable: no, and no public exploit has been identified at time of analysis, though the vendor rates technical impact as total.
Account-lockout bypass in WSO2 Identity Server (6.0.0, 6.1.0, 7.0.0, 7.1.0) and the Carbon MagicLink Authenticator Module allows accounts that have been administratively or automatically locked to still authenticate through the Magic Link and Passkey (FIDO2) flows, because those paths do not validate account state. An attacker in possession of a valid magic link or passkey for a locked account can reach the application and its sensitive data despite the lock, and the lockout control intended to stop further login attempts is rendered ineffective. There is no public exploit identified at time of analysis, EPSS is negligible (0.03%), and the flaw is not in CISA KEV.
The check user account lock states feature within the email OTP flow fails to validate user input, allowing an attacker to infer the existence of registered user accounts. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Reflected cross-site scripting in WSO2 Identity Server's authentication endpoint allows remote unauthenticated attackers to inject arbitrary JavaScript into victims' browsers by luring them to click a crafted URL. Versions 7.1.0 prior to 7.1.0.28 are confirmed affected; a vendor patch is available. While the attack can enable browser redirection, UI manipulation, and theft of browser-accessible data, the explicit use of the httpOnly flag on session cookies prevents session hijacking, partially constraining real-world impact. No public exploit code or active exploitation has been identified at time of analysis, and EPSS places exploitation probability at 0.03%.
Unauthorized access persists in WSO2 Identity Server after user accounts are locked because existing access tokens are not revoked, allowing locked users to continue accessing protected resources until the tokens naturally expire. Affected versions prior to 5.2.0.35 are vulnerable. A vendor patch is available, but no active exploitation or public exploits are known at this time.
Reflected cross-site scripting in the authentication endpoint of WSO2 API Manager and Identity Server allows unauthenticated attackers to inject arbitrary web scripts. Affected versions include API Manager 3.1.0 to 4.1.0 and Identity Server 5.10.0 to 5.11.0. While exploitation requires user interaction, successful attacks can result in information disclosure or UI manipulation; EPSS indicates very low exploitation likelihood, and no active exploitation or public exploit is currently identified.
The XML parsers within multiple WSO2 products accept user-supplied XML data without properly configuring to prevent the resolution of external entities. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This XML External Entity (XXE) vulnerability could allow attackers to read arbitrary files or perform SSRF through XML processing.
OAuth token revocation in WSO2 Identity Server fails to invalidate access and refresh tokens for accounts whose usernames contain mixed-case characters when the deployment pairs a case-insensitive user store with a case-sensitive identity database. An authenticated attacker (PR:L) who already holds a valid, unexpired token for such an account can keep using it for actions that should have been blocked after a revocation-triggering lifecycle event, bounded by the token's natural expiry. Affected deployments are a non-default configuration subset, the trigger requires that specific store/database mismatch plus a mixed-case username, and no public exploit has been identified at time of analysis; the input 7.4 score assumes AC:L, whereas the assessed vector uses AC:H, so real-world risk is materially lower than the headline number suggests.
Cached OAuth2 introspection responses in WSO2 API Manager, WSO2 Identity Server and related WSO2 identity/gateway products can cause a revoked access token to be returned to the client again until the cache entry is cleared, but only when the allowed_scopes configuration is enabled. An authenticated OAuth2 client able to call both the introspection and revocation endpoints must also hit a narrow ordering window - introspecting a token immediately before revoking it - which is why the issue is rated low (CVSS 3.1, AV:N/AC:H/PR:L, C:N/I:N/A:L). The re-issued token is not accepted for API authorization, so there is no confidentiality or integrity loss; the practical effect is a limited availability/authentication-flow disruption, since affected users may be unable to obtain a new valid token until the cache is flushed. No public exploit code and no active exploitation have been identified at time of analysis, and the priority decision is monitor.
Reflected cross-site scripting (CWE-79) affects WSO2's authentication endpoint, which echoes unsanitized request data into error messages; per the vendor advisory, default configurations of WSO2 API Manager, WSO2 API Control Plane, and WSO2 Identity Server are impacted. An unauthenticated remote attacker must convince a victim to follow a crafted link (UI:R), after which injected script runs in the WSO2 origin and can redirect the user, alter the page interface, or read script-accessible information. Because session-related cookies carry the httpOnly flag, the vendor explicitly notes that session hijacking and cookie theft are not possible, keeping this at medium severity (CVSS 6.1); no public exploit or active exploitation is identified at time of analysis.
Server-side request forgery in WSO2 API Manager and related WSO2 products lets a remote attacker direct the server to arbitrary internal or external network locations and to filesystem resources reachable from the WSO2 host. The vendor CVSS vector requires low-level privileges (PR:L), while the advisory text claims an unauthenticated actor can exploit the flaw, so the authentication barrier is unresolved and should be confirmed with WSO2. No public exploit identified at time of analysis, no CISA KEV entry is present in the supplied data, and the issue is prioritized for handling this week.
The system fails to invalidate existing access tokens associated with sub-organization users during sensitive account management operations such as password reset, role change, or sub-organization disablement. This oversight allows previously issued tokens to remain active even after the user's access context has been modified or revoked through administrative actions. The identified issue could lead to unauthorized access by a malicious actor, but only when all of the following conditions are met: previously issued access tokens remain active, and these tokens have been exposed to malicious actors.
WSO2 Carbon OAuth, as shipped in WSO2 Identity Server, API Manager, and related WSO2 products, can leave session-bound tokens valid after the user session ends when token binding validation is enabled and the 'Revoke token upon user logout' option is inactive. An attacker who already possesses such a token can retain access to protected applications and data after logout; this is a moderate, conditionally exploitable session-management flaw that requires a non-default configuration and prior token acquisition, and no public exploit code or active exploitation is identified at time of analysis.
Username enumeration in WSO2 Identity Server allows unauthenticated remote attackers to distinguish valid accounts from invalid ones by observing inconsistent responses from the authentication endpoint when a supplied username does not exist. The issue affects deployments using the Email OTP Authenticator and WSO2 Carbon Abstract OTP Authenticator, and it is a low-to-moderate severity information-disclosure flaw (CVSS 5.3) rather than a direct path to credential theft, data access, or code execution. No public exploit code was identified at time of analysis, and the practical risk comes from chaining discovered usernames with brute-force, password-spraying, or social-engineering campaigns.
The SCIM provisioning endpoints in WSO2 Identity Server, Identity Server as Key Manager, and Open Banking IAM fail to disambiguate between a local user and a federated user that share the same username, so a federated identity can be acted upon as if it were the colliding local account. An attacker who can authenticate as a federated user - and who either already holds a federated identity matching a target's username or can self-register one where self-registration is enabled - can reach the SCIM 2.0 or SCIM 1.1 user endpoints and perform arbitrary operations against the local user store, up to and including account takeover; deployments without self-registration are rated medium severity by the vendor because the collision must be pre-arranged. Exploitation requires authentication as a federated user and a reachable SCIM endpoint, and no public exploit code or confirmed active exploitation was identified at time of analysis; the vendor's own CVSS of 8.2 uses a PR:N vector while our assessment treats the federated-user requirement as PR:L, giving 8.1-equivalent integrity impact with limited confidentiality exposure.
Cleartext storage of remote log server credentials, truststore passwords, and keystore passwords in WSO2 API Manager and related WSO2 products lets high-privileged authenticated Management Console users or anyone with direct read access to product files recover secrets when remote logging is enabled. The flaw is medium severity (CVSS 4.9, CWE-312) and limited to confidentiality; it can enable manipulation of log entries and compromise of the remote log server after credentials are obtained. No public exploit was identified at time of analysis, and deployments without remote logging enabled are not exposed through this path.
WSO2 Identity Server exposes a user-enumeration weakness in its SMS OTP login flow: the error messages returned when the OTP challenge is initiated differ depending on whether the supplied account exists, giving unauthenticated remote attackers a way to confirm valid usernames. The signal is strongest for accounts that have no mobile number registered, which produce a distinct response. No public exploit code or CISA KEV entry was identified at time of analysis, and the CVSS 3.1 score is only 3.7 — the practical value to an attacker is the harvested username list, which feeds later brute-force and social-engineering campaigns rather than yielding direct compromise.
The self-registration flow in WSO2 Identity Server and related WSO2 identity/API management products returns a distinct error when a submitted username already exists, letting unauthenticated users enumerate valid accounts. Any remote party who can reach the self-registration endpoint can harvest a list of confirmed usernames, which then feeds credential-stuffing, brute-force, and targeted phishing campaigns. Rated CVSS 5.3 (medium) with confidentiality-only impact; no public exploit code or active exploitation is identified in the supplied data at time of analysis.
OS command injection (CWE-78) in WSO2's shared Carbon Console administrative interface allows an authenticated administrator with adjacent network access to execute arbitrary operating system commands, leading to complete compromise of the affected system. The vulnerability spans at least eight WSO2 middleware products - including API Manager, Identity Server, Open Banking components, Traffic Manager, Universal Gateway, and API Control Plane - all of which share the Carbon Console administrative layer. The CVSS scope-change flag (S:C) indicates that successful exploitation extends impact beyond the WSO2 application boundary to the underlying host and potentially adjacent systems.
Authentication bypass in WSO2 Identity Server and multiple WSO2 platform products (API Manager, Open Banking AM/IAM/KM, Traffic Manager, Universal Gateway, API Control Plane, Identity Server as Key Manager) lets an attacker skip intermediate multi-factor challenges when the Conditional (Adaptive) Authentication script is configured with a particular multi-step callback/re-execution pattern, resulting in unauthorized takeover of a targeted user account. The flaw stems from the adaptive script failing to enforce completion of all required steps, and carries a high CVSS of 9.4 (C:H/I:H). There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the affected components underpin enterprise SSO/MFA and open-banking IAM, making impact severe where the vulnerable flow exists.
Sensitive information disclosure in WSO2's Carbon Event Publisher Core affects nine WSO2 platform products, including API Manager, Identity Server, and Open Banking components. When an Event Publisher output adapter is misconfigured with extraneous or irrelevant properties, those property values - which may include user credentials or confidential data - are written to the wso2carbon log files without sanitization or masking (CWE-532). A local, high-privileged actor with read access to those log files can extract the inadvertently logged secrets and leverage them for unauthorized access. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.
CSRF in the WSO2 Carbon console Ajax processor enables an attacker to silently execute unauthorized state-changing operations on behalf of authenticated administrators across more than ten WSO2 products including Identity Server, API Manager, and Enterprise Integrator. The vulnerability combines two compounding weaknesses: state-altering operations are routed over HTTP GET, and the sole CSRF mitigation - SameSite=Lax - is defeated because browsers permit session cookies to accompany cross-origin top-level GET navigations. No public exploit code has been reported and this CVE does not appear in CISA KEV at time of analysis; however, the breadth of affected WSO2 products and the IAM/API management context make misconfigured internet-exposed deployments a meaningful target for targeted social engineering.
Tenant isolation failure in WSO2 Identity Server allows authenticated low-privilege users to disclose personally identifiable information belonging to users in separate tenants. The vulnerability exists specifically when Email OTP, SMS OTP, or Magic Link are configured as first-factor authenticators - authentication requests processed through these flows lack sufficient validation to enforce organizational tenant boundaries, exposing data such as mobile numbers. No public exploit code or CISA KEV listing exists at time of analysis, but the low-complexity, network-accessible attack vector (CVSS PR:L/AV:N/AC:L) makes this a credible insider threat and compromised-account scenario for multi-tenant deployments.
Insufficient refresh token invalidation in WSO2 Identity Server's user impersonation flow allows a privileged attacker who has already obtained an impersonated access token to silently renew that authorization via the OAuth refresh token grant, sustaining unauthorized access well beyond the intended session lifetime. The integrity impact is two-fold: the attacker continues performing actions on behalf of the legitimate user, and audit logs attribute those actions to the victim identity rather than the true actor, corrupting traceability and compliance posture. No public exploit is identified and exploitation is bounded by high privilege prerequisites (PR:H) and adjacent network access (AV:A), placing realistic risk firmly in insider-threat and compromised-administrator scenarios.
Cross-organizational secret deletion in WSO2 Identity Server's Secret Type Management REST API allows an administrator with delete permissions to inadvertently remove secrets across all organizations in a multi-tenant deployment. The on-delete cascade logic, triggered when a secret type is deleted, fails to enforce organizational boundaries - a multi-tenancy isolation failure classified as CWE-281 (Improper Preservation of Permissions). Exploitation yields availability and integrity impact across the entire deployment, though it is constrained to high-privilege administrator accounts. No public exploit is identified and this vulnerability is not listed in the CISA KEV catalog.
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.
Username enumeration via observable login response discrepancy affects WSO2 Identity Server, WSO2 Identity Server as Key Manager, WSO2 API Manager, WSO2 Open Banking AM, and WSO2 Open Banking IAM when the Multi-Attribute Login feature is enabled. When a valid username is submitted, the server resolves and returns the canonical form of that username; when an invalid username is submitted, the server echoes the raw input unchanged - creating a deterministic, scriptable oracle for account existence. This disclosure path persists regardless of the validate_username configuration setting, meaning a common hardening measure provides no defense. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Reflected cross-site scripting across at least eight WSO2 platform products - including Identity Server, API Manager, API Control Plane, Traffic Manager, Universal Gateway, Open Banking AM/IAM, and Identity Server as Key Manager - allows unauthenticated remote attackers to inject arbitrary script via unsanitized URL parameters. An attacker who tricks an authenticated user into clicking a crafted link can redirect the victim to a malicious site, tamper with rendered page content, or exfiltrate non-session browser data; partial mitigation is provided by httpOnly flags on session cookies, which block direct session token theft. No public exploit identified at time of analysis; WSO2 self-reported the issue and published advisory WSO2-2025-4343.
The silent Just-In-Time (JIT) provisioning feature in federated authentication implementations fails to properly segregate user roles during account creation when a federated user shares a username. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity. No vendor patch available.
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.
Memory exhaustion denial-of-service in WSO2 Identity Server's Magic Link authenticator allows remote unauthenticated attackers to crash the authentication service by flooding invalid login requests without rate limiting. The vulnerability affects deployments using the Magic Link authentication flow and has an EPSS score indicating moderate exploitation likelihood. WSO2 has published a security advisory (WSO2-2025-4469) with remediation guidance for affected Identity Server and Carbon MagicLink Authenticator Module installations.
Adaptive authentication flows in WSO2 Identity Server 7.1.0 (up to 7.1.0.26) and the Conditional Authentication User and Roles Related Functions module 1.2.76 (up to 1.2.76.1) fail to validate the organization context in which they execute, allowing authentication logic configured for one organization to run against other organizations and sub-organizations. An attacker who already holds privileges to configure adaptive authentication within at least one tenant can therefore cross tenant authorization boundaries to perform critical operations, escalate privileges, and potentially take over accounts in other organizations - an authenticated, high-privilege prerequisite (CVSS:3.1/AV:N/AC:L/PR:H/UI:N) that limits the realistic attacker set to insiders or compromised tenant administrators. Exploitation requires a multi-organization deployment with adaptive authentication enabled; EPSS is low at 0.02% (6th percentile), SSVC records Exploitation: none and Automatable: no, and no public exploit has been identified at time of analysis, though the vendor rates technical impact as total.
Account-lockout bypass in WSO2 Identity Server (6.0.0, 6.1.0, 7.0.0, 7.1.0) and the Carbon MagicLink Authenticator Module allows accounts that have been administratively or automatically locked to still authenticate through the Magic Link and Passkey (FIDO2) flows, because those paths do not validate account state. An attacker in possession of a valid magic link or passkey for a locked account can reach the application and its sensitive data despite the lock, and the lockout control intended to stop further login attempts is rendered ineffective. There is no public exploit identified at time of analysis, EPSS is negligible (0.03%), and the flaw is not in CISA KEV.
The check user account lock states feature within the email OTP flow fails to validate user input, allowing an attacker to infer the existence of registered user accounts. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Reflected cross-site scripting in WSO2 Identity Server's authentication endpoint allows remote unauthenticated attackers to inject arbitrary JavaScript into victims' browsers by luring them to click a crafted URL. Versions 7.1.0 prior to 7.1.0.28 are confirmed affected; a vendor patch is available. While the attack can enable browser redirection, UI manipulation, and theft of browser-accessible data, the explicit use of the httpOnly flag on session cookies prevents session hijacking, partially constraining real-world impact. No public exploit code or active exploitation has been identified at time of analysis, and EPSS places exploitation probability at 0.03%.
Unauthorized access persists in WSO2 Identity Server after user accounts are locked because existing access tokens are not revoked, allowing locked users to continue accessing protected resources until the tokens naturally expire. Affected versions prior to 5.2.0.35 are vulnerable. A vendor patch is available, but no active exploitation or public exploits are known at this time.
Reflected cross-site scripting in the authentication endpoint of WSO2 API Manager and Identity Server allows unauthenticated attackers to inject arbitrary web scripts. Affected versions include API Manager 3.1.0 to 4.1.0 and Identity Server 5.10.0 to 5.11.0. While exploitation requires user interaction, successful attacks can result in information disclosure or UI manipulation; EPSS indicates very low exploitation likelihood, and no active exploitation or public exploit is currently identified.
The XML parsers within multiple WSO2 products accept user-supplied XML data without properly configuring to prevent the resolution of external entities. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This XML External Entity (XXE) vulnerability could allow attackers to read arbitrary files or perform SSRF through XML processing.