A missing authentication enforcement vulnerability exists in the mutual TLS (mTLS) implementation used by System REST APIs and SOAP services in multiple WSO2 products. Due to improper validation of client certificate–based authentication in certain default configurations, the affected components may permit unauthenticated requests even when mTLS is enabled. This condition occurs when relying on the default mTLS settings for System REST APIs or when the mTLS authenticator is enabled for SOAP services, causing these interfaces to accept requests without enforcing additional authentication.
Successful exploitation allows a malicious actor with network access to the affected endpoints to gain administrative privileges and perform unauthorized operations. The vulnerability is exploitable only when the impacted mTLS flows are enabled and accessible in a given deployment. Other certificate-based authentication mechanisms such as Mutual TLS OAuth client authentication and X.509 login flows are not affected, and APIs served through the API Gateway of WSO2 API Manager remain unaffected.
Certain WSO2 products allow unrestricted file upload with resultant remote code execution. The attacker must use a /fileupload endpoint with a Content-Disposition directory traversal sequence to reach a directory under the web root, such as a ../../../../repository/deployment/server/webapps directory. This affects WSO2 API Manager 2.2.0 and above through 4.0.0; WSO2 Identity Server 5.2.0 and above through 5.11.0; WSO2 Identity Server Analytics 5.4.0, 5.4.1, 5.5.0, and 5.6.0; WSO2 Identity Server as Key Manager 5.3.0 and above through 5.10.0; and WSO2 Enterprise Integrator 6.2.0 and above through 6.6.0.
An improper access control vulnerability exists in multiple WSO2 products due to insufficient permission enforcement in certain internal SOAP Admin Services and System REST APIs. A low-privileged user may exploit this flaw to perform unauthorized operations, including accessing server-level information.
This vulnerability affects only internal administrative interfaces. APIs exposed through the WSO2 API Manager's API Gateway remain unaffected.
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.
The XML parsers within multiple WSO2 products accept user-supplied XML data without properly configuring to prevent the resolution of external entities. This omission allows malicious actors to craft XML payloads that exploit the parser's behavior, leading to the inclusion of external resources.
By leveraging this vulnerability, an attacker can read confidential files from the file system and access limited HTTP resources reachable by the product. Additionally, the vulnerability can be exploited to perform denial of service attacks by exhausting server resources through recursive entity expansion or fetching large external resources.
XML External Entity (XXE) vulnerability in the file based service provider creation feature of the Management Console in WSO2 API Manager 2.6.0, 3.0.0, 3.1.0, 3.2.0, and 4.0.0; and WSO2 IS as Key Manager 5.7.0, 5.9.0, and 5.10.0; and WSO2 Identity Server 5.7.0, 5.8.0, 5.9.0, 5.10.0, and 5.11.0. Allows attackers to gain read access to sensitive information or cause a denial of service via crafted GET requests.
A Cross-Site Request Forgery (CSRF) vulnerability exists in multiple WSO2 products due to the use of the HTTP GET method for state-changing operations within admin services, specifically in the event processor of the Carbon console. Although the SameSite=Lax cookie attribute is used as a mitigation, it is ineffective in this context because it allows cookies to be sent with cross-origin top-level navigations using GET requests.
A malicious actor can exploit this vulnerability by tricking an authenticated user into visiting a crafted link, leading the browser to issue unintended state-changing requests. Successful exploitation could result in unauthorized operations such as data modification, account changes, or other administrative actions. According to WSO2 Secure Production Guidelines, exposure of Carbon console services to untrusted networks is discouraged, which may reduce the impact in properly secured deployments.
Multiple WSO2 products have been identified as vulnerable to perform user impersonatoin using JIT provisioning. In order for this vulnerability to have any impact on your deployment, following conditions must be met:
An IDP configured for federated authentication and JIT provisioning enabled with the "Prompt for username, password and consent" option. A service provider that uses the above IDP for federated authentication and has the "Assert identity using mapped local subject identifier" flag enabled.
Attacker should have:
A fresh valid user account in the federated IDP that has not been used earlier. Knowledge of the username of a valid user in the local IDP.
When all preconditions are met, a malicious actor could use JIT provisioning flow to perform user impersonation.
Due to the use of a vulnerable third-party Velocity template engine, a malicious actor with admin privilege may inject and execute arbitrary template syntax within server-side templates.
Successful exploitation of this vulnerability could allow a malicious actor with admin privilege to inject and execute arbitrary template code on the server, potentially leading to remote code execution, data manipulation, or unauthorized access to sensitive information.
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.
An arbitrary file upload vulnerability exists in multiple WSO2 products due to improper validation of user-supplied filenames in the BPEL uploader SOAP service endpoint. A malicious actor with administrative privileges can upload arbitrary files to a user-controlled location on the server.
By leveraging this vulnerability, an attacker can upload a specially crafted payload and achieve remote code execution (RCE), potentially compromising the server and its data.
An arbitrary file upload vulnerability exists in multiple WSO2 products due to improper input validation in the CarbonAppUploader admin service endpoint. An authenticated attacker with appropriate privileges can upload a malicious file to a user-controlled location on the server, potentially leading to remote code execution (RCE).
This functionality is restricted by default to admin users; therefore, successful exploitation requires valid credentials with administrative permissions.
The authentication endpoint fails to encode user-supplied input before rendering it in the web page, allowing for script injection. An attacker can leverage this by injecting malicious scripts into the authentication endpoint. This can result in the user's browser being redirected to a malicious website, manipulation of the web page's user interface, or the retrieval of information from the browser. However, session hijacking is not possible due to the httpOnly flag protecting session-related cookies.
In accountrecoveryendpoint/recoverpassword.do in WSO2 Identity Server 5.7.0, it is possible to perform a DOM-Based XSS attack affecting the callback parameter modifying the URL that precedes the callback parameter. Once the username or password reset procedure is completed, the JavaScript code will be executed. (recoverpassword.do also has an open redirect issue for a similar reason.)
A reflected XSS issue exists in the Management Console of several WSO2 products. This affects API Manager 2.2.0, 2.5.0, 2.6.0, 3.0.0, 3.1.0, 3.2.0, and 4.0.0; API Manager Analytics 2.2.0, 2.5.0, and 2.6.0; API Microgateway 2.2.0; Data Analytics Server 3.2.0; Enterprise Integrator 6.2.0, 6.3.0, 6.4.0, 6.5.0, and 6.6.0; IS as Key Manager 5.5.0, 5.6.0, 5.7.0, 5.9.0, and 5.10.0; Identity Server 5.5.0, 5.6.0, 5.7.0, 5.9.0, 5.10.0, and 5.11.0; Identity Server Analytics 5.5.0 and 5.6.0; and WSO2 Micro Integrator 1.0.0.
The user self-signup flow in multiple WSO2 products fails to adequately validate user-supplied input. This weakness allows arbitrary unvalidated data to be included within user claims, which are then used by downstream processes.
Allowing unvalidated input into user claims can lead to various security risks. Malicious or malformed data injected during signup could be processed by other parts of the application, potentially enabling attacks such as content manipulation, redirection, user interface inconsistencies, unauthorized actions, and data exposure. The actual impact depends on how the compromised data is consumed and the privileges associated with the affected users.
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.
The check user account lock states feature within the email OTP flow fails to validate user input, allowing an attacker to infer the existence of registered user accounts.
The discovery of valid usernames can increase the risk of brute-force and social engineering attacks. Attackers can leverage this information to craft targeted phishing campaigns or other malicious activities aimed at tricking users into divulging sensitive data, potentially damaging the organization's reputation and leading to regulatory non-compliance and financial consequences.
The silent Just-In-Time (JIT) provisioning feature in federated authentication implementations fails to properly segregate user roles during account creation when a federated user shares a username with a local user. This allows the provisioning process to overwrite existing roles of local users with roles assigned to the federated user.
Exploitation requires a federated identity provider (IDP) with silent JIT provisioning enabled and an attacker's knowledge of a local user's username. When these conditions are met, a malicious individual can leverage the JIT provisioning process to modify the roles of local users. The overwritten roles are limited to those defined within the federated IDP, typically granting minimal access rights unless explicitly configured otherwise by the federated IDP administrator.
Unused authorization codes issued to deleted users are not being properly invalidated or removed from the system. This allows for the persistence of these codes, enabling them to be potentially reused.
If an attacker possesses both the authorization code and the associated client credentials (client ID and client secret), they can leverage these unused codes to obtain access tokens on behalf of users who have already been deleted. This may lead to unauthorized access to sensitive resources and services, contingent on the scopes originally authorized for the compromised authorization code.
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 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 validateusername 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.