Vulnerabilities

The administrative operations within the Carbon Console do not adequately validate specific user-supplied input.

The Conditional Authentication (Adaptive Authentication) script does not correctly enforce the completion of all required authentication steps when a specific multi-step pattern involving certain authenticators is config…

When a proxy server is configured with `customUrl.enabled`, the component accepts user-supplied input within forwarded HTTP headers without enforcing expected validation constraints.

The Ajax processor within the Carbon console fails to adequately protect state-changing operations from Cross-Site Request Forgery (CSRF) attacks.

The system accepts authentication requests without sufficient validation to enforce tenant isolation when using Email OTP, SMS OTP, or Magic Link as first-factor authenticators.

The user impersonation flow in WSO2 Identity Server fails to properly manage refresh tokens associated with impersonated sessions.

The Secret Type Management REST API does not correctly isolate access controls when deleting a secret type.

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.

When Multi-Attribute Login is enabled, the login interface fails to consistently mask the existence of user accounts.

The user self-signup flow in multiple WSO2 products fails to adequately validate user-supplied input.

The account locking mechanism fails to trigger when secondary user stores are inaccessible.

Unused authorization codes issued to deleted users are not being properly invalidated or removed from the system.

The affected product accepts user-supplied input within a URL parameter without enforcing expected sanitization or encoding before rendering it within the response.

The software accepts user-supplied input via a URL parameter without adequate output encoding before reflecting it back to the user's browser.

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 with a local user.

In multi-tenanted deployments, the application consent management mechanism fails to correctly isolate consent scopes between tenants.

The Magic Link authentication flow accepts multiple invalid authentication requests without adequate rate limiting or resource control, leading to uncontrolled memory usage growth.

Due to not validating the organization context when executing adaptive authentication flows, the WSO2 Identity Server allows adaptive authentication logic to be triggered on unintended organizations.

Due to a lack of user account state validation during authentication, locked user accounts can be successfully authenticated using Magic Link or Pass Key methods.

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.

The authentication endpoint accepts user-supplied input without enforcing expected validation constraints, leading to a lack of proper output encoding.

Active access tokens are not revoked or invalidated when a user account is locked within WSO2 Identity Server.

The authentication endpoint fails to encode user-supplied input before rendering it in the web page, allowing for script injection.

The XML parsers within multiple WSO2 products accept user-supplied XML data without properly configuring to prevent the resolution of external entities.

When the "Silent Just-In-Time Provisioning" feature is enabled for a federated identity provider (IDP) there is a risk that a local user store user's information may be replaced during the account provisioning process in…