A username enumeration vulnerability exists in multiple WSO2 products when Multi-Attribute Login is enabled. In this configuration, the system returns a distinct "User does not exist" error message to the login form, regardless of the validate_username setting. This behavior allows malicious actors to determine which usernames exist in the system based on observable discrepancies in the application's responses.
Exploitation of this vulnerability could aid in brute-force attacks, targeted phishing campaigns, or other social engineering techniques by confirming the validity of user identifiers within the system.
An authentication bypass vulnerability exists in multiple WSO2 products when FIDO authentication is enabled. When a user account is deleted, the system does not automatically remove associated FIDO registration data. If a new user account is later created using the same username, the system may associate the new account with the previously registered FIDO device.
This flaw may allow a previously deleted user to authenticate using their FIDO credentials and impersonate the newly created user, resulting in unauthorized access. The vulnerability applies only to deployments that utilize FIDO-based authentication.
A reflected cross-site scripting (XSS) vulnerability exists in the account registration flow of WSO2 Identity Server due to improper output encoding. A malicious actor can exploit this vulnerability by injecting a crafted payload that is reflected in the server response, enabling the execution of arbitrary JavaScript in the victim's browser.
This vulnerability could allow attackers to redirect users to malicious websites, modify the user interface, or exfiltrate data from the browser. However, session-related sensitive cookies are protected using the httpOnly flag, which mitigates the risk of session hijacking.
A cross-tenant authentication vulnerability exists in multiple WSO2 products due to improper cryptographic design in Adaptive Authentication. A single cryptographic key is used across all tenants to sign authentication cookies, allowing a privileged user in one tenant to forge authentication cookies for users in other tenants.
Because the Auto-Login feature is enabled by default, this flaw may allow an attacker to gain unauthorized access and potentially take over accounts in other tenants. Successful exploitation requires access to Adaptive Authentication functionality, which is typically restricted to high-privileged users. The vulnerability is only exploitable when Auto-Login is enabled, reducing its practical impact in deployments where the feature is disabled.
An authenticated remote code execution (RCE) vulnerability exists in multiple WSO2 products due to improper input validation in the event processor admin service. A user with administrative access to the SOAP admin services can exploit this flaw by deploying a Siddhi execution plan containing malicious Java code, resulting in arbitrary code execution on the server.
Exploitation of this vulnerability requires a valid user account with administrative privileges, limiting the attack surface to authenticated but potentially malicious users.
An authenticated stored cross-site scripting (XSS) vulnerability exists in multiple WSO2 products due to improper validation of user-supplied input during API document upload in the Publisher portal. A user with publisher privileges can upload a crafted API document containing malicious JavaScript, which is later rendered in the browser when accessed by other users.
A successful attack could result in redirection to malicious websites, unauthorized UI modifications, or exfiltration of browser-accessible data. However, session-related sensitive cookies are protected by the httpOnly flag, preventing session hijacking.
An open redirection vulnerability exists in multiple WSO2 products due to improper validation of the multi-option URL in the authentication endpoint when multi-option authentication is enabled. A malicious actor can craft a valid link that redirects users to an attacker-controlled site.
By exploiting this vulnerability, an attacker may trick users into visiting a malicious page, enabling phishing attacks to harvest sensitive information or perform other harmful actions.
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.
A stored cross-site scripting (XSS) vulnerability exists in the Management Console of multiple WSO2 products due to insufficient input validation in the Rich Text Editor within the registry section.
To exploit this vulnerability, a malicious actor must have a valid user account with administrative access to the Management Console. If successful, the actor could inject persistent JavaScript payloads, enabling the theft of user data or execution of unauthorized actions on behalf of other users.
While this issue enables persistent client-side script execution, session-related cookies remain protected with the httpOnly flag, preventing session hijacking.
An arbitrary file upload vulnerability exists in multiple WSO2 products due to improper validation of user input in SOAP admin services. A malicious actor with administrative privileges can upload an arbitrary file to a user-controlled location on the server.
By leveraging this vulnerability, an attacker could upload a specially crafted payload, potentially achieving remote code execution (RCE) on the server. Exploitation requires valid admin credentials, limiting its impact to authorized but potentially malicious users.
A server-side request forgery (SSRF) vulnerability exists in multiple WSO2 products due to improper input validation in SOAP admin services. This flaw allows unauthenticated attackers to manipulate server-side requests, enabling access to internal and external resources available through the network or filesystem.
Exploitation of this vulnerability could lead to unauthorized access to sensitive data and systems, including resources within private networks, as long as they are reachable by the affected product.
An incorrect authorization vulnerability exists in multiple WSO2 products due to a flaw in the SOAP admin service, which allows user account creation regardless of the self-registration configuration settings. This vulnerability enables malicious actors to create new user accounts without proper authorization.
Exploitation of this flaw could allow an attacker to create multiple low-privileged user accounts, gaining unauthorized access to the system. Additionally, continuous exploitation could lead to system resource exhaustion through mass user creation.
A privilege escalation vulnerability exists in multiple WSO2 products due to a business logic flaw in SOAP admin services. A malicious actor can create a new user with elevated permissions only when all of the following conditions are met:
* SOAP admin services are accessible to the attacker.
* The deployment includes an internally used attribute that is not part of the default WSO2 product configuration.
* At least one custom role exists with non-default permissions.
* The attacker has knowledge of the custom role and the internal attribute used in the deployment.
Exploiting this vulnerability allows malicious actors to assign higher privileges to self-registered users, bypassing intended access control mechanisms.
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.
Multiple WSO2 products have a vulnerability that allows unrestricted file upload, which can lead to remote code execution. This vulnerability has been exploited in the wild and is known to be used in ransomware campaigns. No specific affected versions or patches are provided in the available data.
