| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| The product fails to sufficiently validate callback URLs, allowing them to be manipulated with malicious payloads when processed through a weak regular expression or when validation is omitted.
An attacker can exploit this by crafting a link that appears legitimate but redirects users to an attacker-controlled page. This redirection facilitates phishing attacks, enabling the harvesting of sensitive user information, potentially leading to unauthorized access or data theft. |
| 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. |
| 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 Admin REST API accepts user-supplied input without adequately sanitizing it, allowing it to be included in the structure of SQL statements.
A user with administrator privileges can exploit this by influencing the structure of executed SQL statements, enabling blind SQL injection to infer database information and potentially impact the availability of the database service. |
| The user search function within the management console fails to properly encode user-supplied input before rendering it in the browser. This allows an attacker to inject malicious scripts that are then executed by the user's browser in the context of the management console.
Successful exploitation enables an attacker to redirect the user's browser to a malicious website, modify the web page's user interface, or extract information from the browser. However, due to the use of the httpOnly flag on sensitive session cookies, session hijacking or similar attacks are prevented. |
| 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. |
| The account lock feature fails to correctly enforce account lockouts on the primary user store when users with identical usernames exist in both primary and secondary user stores. This occurs because the lock condition is only applied to the secondary user store account in such scenarios, allowing continued authentication attempts against the primary user store account.
This functional flaw enables brute force attacks. By systematically attempting different passwords against the primary user store account, an attacker can potentially gain unauthorized access to sensitive information or accounts, as the intended account lockout mechanism does not prevent repeated login attempts. |
| 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 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 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 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 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. |
| The authentication endpoint generates an error message that includes reflected data directly from the request without sufficient sanitization or encoding. This allows an attacker to inject malicious scripts that can be executed in the context of a victim's browser.
Successful exploitation enables an attacker to perform actions within the user's browser, such as redirecting the user to a malicious website, modifying the web page's user interface, or retrieving information. However, due to the httpOnly flag on session-related cookies, session hijacking or similar attacks are not possible. |
| 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. |
| In deployments of WSO2 Identity Server configured with a case-insensitive user store and a case-sensitive database for identity data, mismatches in username case handling can occur. This inconsistency results in OAuth token revocation operations failing to correctly identify usernames containing mixed-case characters during certain lifecycle events, preventing tokens from being invalidated.
A malicious actor can exploit this vulnerability by possessing a valid access or refresh token associated with a mixed-case username. In affected configurations, these tokens may not be revoked when expected. The actor can then leverage these unrevoked tokens, before their expiry, to continue performing actions that should have been restricted, effectively bypassing intended access controls. |
| The BPMN System REST APIs do not sufficiently validate input parameters, allowing authenticated users to submit crafted requests that can lead to the execution of arbitrary commands on the server.
An authenticated user can leverage this vulnerability to execute arbitrary commands with the privileges of the product's runtime account. The scope of potential damage is contingent upon the permissions assigned to this account. |
| 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. |
