| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The System REST APIs do not correctly enforce access control mechanisms, allowing users with lower privilege roles to execute administrative actions that should be restricted. This weakness permits unauthorized operations on the affected product.
Successful exploitation could enable a malicious actor to perform unauthorized administrative operations, including executing administrative functions. APIs exposed through the WSO2 API Manager's API Gateway are not affected by this vulnerability. |
| The error handling implementation fails to properly sanitize or validate user-supplied input within URL parameters under specific conditions. This allows end-users to manipulate the error messages that are displayed by the application.
By exploiting this vulnerability, malicious actors can inject arbitrary content into error messages. This enables them to perform social engineering attacks, such as phishing or credential theft, by replacing legitimate error messages with malicious content, misleading users into compromising sensitive information or taking harmful actions. |
| When an Event Publisher output adapter is configured with properties that are irrelevant to its function, the affected products log these irrelevant properties. This can inadvertently include sensitive user credentials or other confidential information depending on the nature of the misconfigured property.
A malicious actor with access to the 'wso2carbon' log files could retrieve sensitive information logged by the system. This may potentially lead to unauthorized access if the logged data contains credentials or other critical secrets. |
| The refresh token grant type in WSO2 products fails to re-validate account status before issuing new access tokens. This weakness allows an attacker to obtain valid access tokens for user accounts even after they have been blocked by the user store, bypassing account lockout mechanisms.
This vulnerability can lead to unauthorized access to user accounts and their associated resources. Attackers can leverage this to perform actions on behalf of blocked users, potentially leading to privilege escalation or data exfiltration depending on the permissions of the compromised account. |
| The affected components accept user-supplied input for constructing redirection URLs without enforcing expected validation constraints. This allows an attacker to provide a crafted URL that can redirect users to an arbitrary external domain.
By leveraging this open redirection vulnerability, an attacker can craft a malicious link that, when clicked by a user, redirects them to an attacker-controlled page. This can be used in conjunction with social engineering techniques to execute phishing attacks, aiming to obtain sensitive information or cause other harm. |
| 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. |
| 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 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. |
| Due to the improper implementation of access control rules, the WSO2 product accepts user-supplied input related to resource location without enforcing expected validation constraints. This can be exploited by an unauthenticated actor to direct the server to make requests to arbitrary network locations.
Exploiting this vulnerability allows a malicious actor to access both internal and external resources, available through the network or filesystem, that are reachable by the WSO2 product. This could potentially lead to unauthorized access to sensitive data and systems. |
| When the `allowed_scopes` configuration is enabled, the OAuth2 token introspection mechanism does not immediately invalidate a token in the cache after a revocation request. This results in a scenario where an access token that was introspected immediately before a revocation request may be returned again to the client after revocation, until the relevant cache entry is cleared.
The security consequence is that a revoked access token may be re-issued to the client during the cache lifetime. While the re-issued token is not treated as valid for API authorization, affected users may be unable to obtain a new valid access token until the cache is cleared, which can disrupt authentication flows. |
| 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. |
| 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 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 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. |
| 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. |
| A reflected cross-site scripting (XSS) vulnerability exists in multiple WSO2 products due to insufficient output encoding in error messages generated by the JDBC user store connection validation request. A malicious actor can inject a specially crafted payload into the request, causing the browser to execute arbitrary JavaScript in the context of the vulnerable page.
This vulnerability may allow UI manipulation, redirection to malicious websites, or data exfiltration from the browser. However, since all session-related sensitive cookies are protected with the httpOnly flag, session hijacking is not possible. |
| 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 Ajax processor within the Carbon console fails to adequately protect state-changing operations from Cross-Site Request Forgery (CSRF) attacks. Specifically, it utilizes the HTTP GET method for these operations, and while the SameSite=Lax cookie attribute is employed for mitigation, this mechanism is bypassed as it permits cookies to be sent with cross-origin top-level navigation requests, including GET requests. This allows an attacker to trick an authenticated user's browser into unknowingly executing unintended actions.
An attacker can exploit this vulnerability to perform unauthorized state-altering requests on behalf of authenticated users. This could lead to consequences such as data modification, account changes, or other actions that could result in data compromise or loss of user control over their account. However, this attack is only feasible if the Carbon console and related services are exposed to the public internet, which is not recommended according to WSO2's security guidelines. |
| When Multi-Attribute Login is enabled, the login interface fails to consistently mask the existence of user accounts. For valid users, the server resolves and displays their canonical username, while for non-existent users, it echoes the original input. This occurs regardless of the validate_username configuration.
The discovery of valid usernames can increase the risk of brute force attacks, social engineering attacks, and targeted information leakage. Attackers can leverage this information to craft more effective phishing campaigns or social engineering tactics to compromise user accounts or extract sensitive data. |
| 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. |
