| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| When a proxy server is configured with `customUrl.enabled`, the component accepts user-supplied input within forwarded HTTP headers without enforcing expected validation constraints. A malicious actor can manipulate these headers to influence the URL construction process, leading to an open redirect vulnerability. Additionally, unsanitized header values are written to application logs.
An attacker can exploit this to force redirection to arbitrary malicious domains, potentially enabling phishing attacks. Furthermore, they can inject forged entries into application logs, impacting the reliability of security logs and potentially hindering incident investigation. |
| This issue only impacts deployments where WSO2 Identity Server is configured as a Resident Key Manager with database sharing. In such environments, a self-registered user may gain access to the System REST APIs of WSO2 API Manager by obtaining a token from the WSO2 Identity Server token endpoint. |
| When utilizing JWT Bearer or SAML2 Bearer grant types, the system fails to validate the status of the Identity Provider (IDP) before issuing access tokens. This oversight permits tokens to be generated even when the associated IDP has been disabled.
A malicious actor could leverage this vulnerability to obtain access tokens by targeting a disabled IDP. This could enable them to bypass intended security controls and potentially access protected resources that should be inaccessible due to the IDP's disabled state. |
| The Publisher portal fails to enforce proper validation on uploaded SVG files, allowing users with the Publisher role to inject malicious scripts. This weakness can be exploited by uploading a crafted SVG file, which is then stored and rendered by the application.
The security consequences include the ability for a malicious actor to redirect the victim's browser to an arbitrary website, modify the web page's UI, or retrieve information from the browser. However, the impact is mitigated as session-related sensitive cookies are protected with the httpOnly flag, preventing session hijacking. |
| 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. |
| Due to the improper implementation of access control rules, malicious actors could perform a Server Side Request Forgery (SSRF) attack on affected WSO2 Products. Exploiting this vulnerability allows a malicious actor to access both internal and external resources, available through the network or filesystem. This could potentially lead to unauthorized access to sensitive data and systems, regardless of whether these resources are located within a private network, as long as they are reachable by the WSO2 product. |
| The authentication endpoint does not properly encode user-supplied input before rendering it within the web page. This lack of output encoding allows an attacker to inject malicious JavaScript payloads into the authentication flow, which are then executed by the victim's browser.
By exploiting this vulnerability, an attacker can redirect the user's browser to a malicious website, modify the content of the web page displayed to the user, or exfiltrate information from the browser. However, due to the implementation of the httpOnly flag on session-related sensitive cookies, session hijacking and similar attacks are not possible. |
| 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. |
| 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 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 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 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. |
| 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 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. |
| 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 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. |
| 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. |
| 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. |
