The product failed to enforce validation constraints on user-supplied input in URL parameters, allowing sensitive data to be passed to flows where it was not intended to be processed. Although the product did not utilize this data, its acceptance could lead to logging.

If a user mistakenly sends sensitive data via URL parameters to any flow, this data could be inadvertently logged in access logs. This has the potential to expose confidential information, compromising the security and privacy of affected systems if the product is used incorrectly.

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.

When a WSO2 product is configured to use an external user store, the system fails to adequately obscure the existence or validity of usernames during authentication attempts. This oversight allows an attacker to repeatedly query the authentication mechanism with different username guesses, enabling the enumeration of valid usernames present in the external user store.

The discovery of valid usernames can increase the risk of targeted brute-force attacks, social engineering, and information leakage. Attackers can leverage this information to craft more convincing phishing campaigns or other social engineering tactics to trick users into revealing sensitive data. The presence of username enumeration could also negatively impact an organization's reputation, leading to loss of customer trust, regulatory non-compliance, and potential legal and financial repercussions.

Due to an incomplete implementation, reCaptcha is not applied to certain authentication flows even when the reCaptcha option is enabled. This oversight permits attackers to bypass the intended protection mechanism.

Brute force attacks, if successful, can lead to unauthorized access to user accounts and sensitive information by systematically attempting various credential combinations.

The callback URL parameter in WSO2 API Manager fails to validate user-supplied input, allowing it to be controlled by malicious actors.

Exploitation of this vulnerability could lead to users being redirected to attacker-controlled web pages. This can be used in conjunction with social engineering techniques to trick users into interacting with malicious links, potentially resulting in phishing attacks aimed at acquiring sensitive information or causing other harm.

The Authentication Endpoint accepts user-supplied input without sufficient encoding, allowing for the injection of malicious JavaScript payloads. This vulnerability can be triggered by submitting crafted input to the Authentication Endpoint.

Successful exploitation allows an attacker to redirect the user's browser to a malicious website, modify the web page's user interface, or extract sensitive information from the browser. However, due to the httpOnly flag on session-related cookies, session hijacking is not possible.

The RemoteUserStoreManagerService does not sufficiently validate password change attempts when the password history validation feature is enabled. This oversight allows an attacker to repeatedly attempt password guesses for a user account without being adequately restricted.

Exploiting this vulnerability enables an attacker to discover a user's password through brute force, leading to account impersonation. The success rate of such an attack is influenced by the complexity of the targeted user's password, with simpler passwords increasing the likelihood of compromise.

The software accepts user-supplied data without sufficient validation, allowing for the injection of malicious Expression Language (EL) code. This can lead to the execution of arbitrary operations within the affected deployment.

Exploitation of this vulnerability requires administrator privileges. The impact is minimal as EL usage is restricted to certain read operations.

Tokens associated with user sessions are not revoked when the corresponding user session is terminated, unless another SSO request is initiated. This occurs when the session-bound token feature is enabled with token binding validation and the "Revoke token upon user logout" option is not active. The software fails to automatically invalidate session-bound tokens upon user session termination.

This vulnerability exists when token binding validation is enabled. As a result, a malicious actor possessing a valid session-bound token could exploit this condition to maintain unauthorized access to applications and resources even after the associated user session has ended, potentially leading to the exposure of sensitive user data.

The authentication endpoint of WSO2 Identity Server fails to provide a consistent system response when a username does not exist in the system, allowing attackers to differentiate between valid and invalid usernames. This difference in responses can be leveraged to enumerate existing user accounts.

Successful exploitation enables an attacker to discover valid usernames within the system, significantly increasing the risk of subsequent attacks such as brute force attacks on user credentials, social engineering attacks, and information leakage. The discovered usernames can be used to craft targeted phishing emails or other social engineering campaigns.

The SCIM endpoint does not sufficiently validate authorization for federated users when performing operations against the local user store. This occurs when a local and a federated user share the same username, allowing a federated user to perform actions intended for a local user, including arbitrary operations.

A malicious actor authenticated as a federated user may perform arbitrary operations on local user accounts via the SCIM 2.0 or SCIM 1.1 endpoints when local and federated users share the same username. This could lead to user account takeover. Deployments that do not support user self-registration are considered medium severity.

The Management Console and product files expose sensitive data, including remote log server credentials, truststore passwords, and keystore passwords, in plain text. This occurs because the system does not sufficiently protect or obscure these credentials when the remote logging feature is enabled.

An attacker with administrative access to the Management Console or direct access to product files can retrieve these sensitive credentials. This allows for potential manipulation of log entries and compromise of the integrity and confidentiality of the remote log server.

The ForgeRock client fails to correctly validate refresh tokens. This allows a refresh token to be treated as a valid access token, enabling its use for consuming protected resources. This bypasses the intended security control that requires valid client credentials in addition to a refresh token to obtain a new access token.

An attacker who obtains a stolen or exposed refresh token can leverage this vulnerability to directly access protected resources. This is possible because the standard security flow requiring client credentials to exchange a refresh token for an access token is circumvented.

The carbon console accepts user-supplied XML input without sufficiently encoding potentially executable content, allowing for the injection of malicious scripts.

Successful exploitation allows a remote attacker to execute arbitrary JavaScript in the context of a victim's browser, leading to actions such as redirecting the user to a malicious website or modifying the web page's user interface. Session hijacking is not possible as sensitive session cookies are protected by the httpOnly flag.

The Management Console fails to properly validate input related to the configuration of JDBC user stores. This weakness allows an attacker to supply specially crafted input that can lead to the execution of arbitrary code on the affected server.

Successful exploitation of this vulnerability enables an attacker to execute arbitrary code on the server with the privileges of the WSO2 product. This could lead to a full compromise of the system.

The WSO2 Identity Server fails to enforce a default expiry time for SMS One-Time Passwords (OTPs) used in multi-factor authentication (MFA). This allows unused OTPs to remain valid indefinitely, presenting an opportunity for malicious actors to conduct brute force attacks by repeatedly guessing the OTP.

The absence of automatic expiration for OTPs grants attackers an unlimited timeframe to attempt guessing the correct code. A successful brute force attack can lead to an MFA bypass, resulting in the unauthorized takeover of a user's account and compromising the security and privacy of both the individual and the system.

The SMS OTP flow fails to adequately handle error messages, allowing an attacker to infer the existence of registered user accounts based on the responses received during the OTP initiation process.

This weakness can be exploited by an attacker to discover valid usernames within the system. The impact is amplified for accounts that have not configured a mobile number, as the enumeration is specifically tied to this condition. The discovery of these usernames can facilitate subsequent brute force attacks, social engineering attempts, and information leakage, potentially leading to reputational damage, loss of customer trust, and regulatory non-compliance.

Insufficient HTML sanitization in the Publisher Portal and Developer Portal allows untrusted user input to be rendered without proper encoding or neutralization. This enables the injection and execution of malicious JavaScript when affected API documents are viewed.

Successful exploitation may result in the execution of malicious scripts within the user's browser context when viewing API documentation. Users with permissions to access the API documentation through these portals may be impacted, potentially allowing attackers to perform actions on behalf of the user, depending on their session privileges.

The product's web portals allow external links to be opened in a new browser tab. In certain configurations, the originating window retains access to the newly opened page, allowing interaction between the two browser contexts when navigating to external destinations.

This vulnerability could allow an attacker to manipulate the original trusted application window after a user clicks a malicious external link. This manipulation can lead to users being redirected to phishing pages, enabling credential theft, or facilitating other unauthorized actions within the context of the trusted site.

The administrative operations within the Carbon Console do not adequately validate specific user-supplied input. This oversight allows a malicious actor with administrative privileges to inject and execute arbitrary code remotely.

Successful exploitation enables a threat actor with administrative privileges and Carbon Console access to execute remote arbitrary code through specific administrative operations, leading to a complete compromise of the affected system.

The API Publisher component previously used a non-cryptographic pseudorandom number generator (PRNG) to create shared secrets for Webhook HMAC validation. This PRNG lacks sufficient entropy for security-sensitive operations, allowing a sophisticated attacker to predict future secrets. This enables malicious actors to forge event payloads with valid HMAC signatures, bypassing the API Gateway's authenticity verification.

Successful exploitation could allow an attacker to predict shared secrets used for Webhook HMAC validation and forge event payloads with valid signatures. This may enable bypassing API Gateway authenticity checks, leading to unauthorized event injection, data manipulation, or downstream system compromise.

The System REST API accepts user-supplied file uploads without enforcing sufficient validation on the file type or destination, allowing files to be written to arbitrary server-accessible locations. Exploitation requires authenticated administrative access with publisher privileges.

Successful exploitation permits an authenticated publisher to upload files to server-accessible locations. Depending on the deployment environment and how uploaded files are handled, this could lead to the execution of uploaded content, potentially resulting in remote code execution.

The XML and schema validation functionalities within the SchemaValidator Mediator process XML input as part of validation flows. Under certain conditions, the XML parser allows the resolution of external entities when handling user-supplied XML content during validation operations. This behavior can occur when an attacker supplies crafted XML payloads to the relevant mediator flows with sufficient privileges.

Successful exploitation may allow a highly privileged actor to read files accessible within the server hosting the affected product. Additionally, it may be possible to trigger outbound requests to unintended internal or external locations, depending on the server environment and network configuration. Specially crafted XML payloads can also lead to excessive resource consumption during parsing, impacting the availability of the product.

In multi-tenant deployments, the Publisher REST APIs fail to enforce tenant isolation correctly. This allows a user in one tenant, possessing sufficient privileges to invoke these APIs, to perform operations that impact other tenants.

The vulnerability allows a privileged user to perform publisher operations such as exposing or modifying API Metadata in another tenant environment. This impact is only realized in multi-tenant deployments.

When internal roles are removed from a user within the WSO2 product, the system fails to invalidate any previously issued authentication tokens associated with that user.

This vulnerability could allow users to retain their previous access privileges even after their roles have been revoked. As a result, a user can continue to perform unauthorized actions or access restricted resources until the expired tokens naturally expire.

The Swagger UI Try-out console within the API Publisher documentation allows an external Swagger API definition URL to be loaded, overriding the existing API definitions within the Publisher portal.

By exploiting this vulnerability, malicious actors can deceive users into interacting with these overwritten API definitions. This could lead to the exposure of sensitive information or the initiation of unintended requests to backend services.

The JWT authentication mechanism accepts tokens signed with algorithms other than those explicitly configured or supported. This allows an attacker to craft a JWT with an unsupported algorithm, which is then incorrectly validated, leading to unauthorized access.

Successful exploitation of this vulnerability may result in unauthorized access to the system, including the potential compromise of administrative accounts and full account takeover. The CVSS score is adjusted to 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) in single-tenant deployments, reflecting that the impact is contained within a single security authority boundary.

Tokens issued to a low-privileged user are not sufficiently restricted, allowing them to be used to access product-level Admin REST APIs.

Exploitation of this vulnerability allows a low-privileged user to invoke the Admin REST APIs of WSO2 products, potentially leading to full administrative account takeover. This requires the attacker to already possess a low-privileged user account and be able to obtain a valid token for it.

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 configured. This allows an attacker to bypass intermediate authentication challenges by exploiting how the script handles callbacks and re-execution of authentication steps.

Successful exploitation allows a malicious actor to gain unauthorized access to a targeted user account. This vulnerability can only be exploited when all of the following conditions are met: the application login flow contains a specific secondary authenticator, the Conditional Authentication script is configured with particular event callbacks and re-executes an authentication step, the targeted user has one of the impacted authenticators enrolled, and the attacker successfully completes any preceding authentication steps.

When an Event Publisher output adapter is configured with irrelevant properties, the affected products log these properties. This logging occurs without sufficient validation or sanitization of the property values.

A malicious actor with access to the 'wso2carbon' log files could retrieve sensitive information, such as user credentials or other confidential data, that was inadvertently logged due to misconfiguration, potentially leading to unauthorized access.