| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| 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 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. |
| 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 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. |
| 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. |
| 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 Velocity template engine, utilized by the affected product, accepts and processes template syntax without sufficient sanitization or validation of user-controlled input. This allows an authenticated administrator to inject arbitrary template syntax.
Successful exploitation enables an attacker with administrative privileges to execute arbitrary template code on the server. This can lead to significant security consequences, including remote code execution, manipulation of data, and unauthorized access to sensitive information. |
| The affected product accepts user-supplied input within a URL parameter without enforcing expected sanitization or encoding before rendering it within the response. This condition allows for the injection of malicious JavaScript payloads.
An attacker can leverage this vulnerability to cause the user's browser to redirect to a malicious website, modify the user interface of the webpage, or retrieve sensitive information from the browser. However, the impact is mitigated for session hijacking as all session-related sensitive cookies are protected by the httpOnly flag. |
| 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. |
| 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. |
| 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 account locking mechanism fails to trigger when secondary user stores are inaccessible. The software does not maintain a consistent state for account locking if it cannot reach all configured user stores, allowing an attacker to repeatedly attempt authentication with invalid credentials without triggering the lockout mechanism for users within active stores.
When the account locking mechanism is bypassed due to the inaccessibility of secondary user stores, users in accessible user stores are left vulnerable to brute force attacks. A malicious actor can exploit this by attempting numerous invalid password combinations against a user account without the expected account lockout consequence. |
