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 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.

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 Management Console and product files expose sensitive data, including remote log server credentials, truststore passwords, and keystore passwords, in plain text. This occurs because the system does not sufficiently protect or obscure these credentials when the remote logging feature is enabled.

An attacker with administrative access to the Management Console or direct access to product files can retrieve these sensitive credentials. This allows for potential manipulation of log entries and compromise of the integrity and confidentiality of the remote log server.

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.

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 input via a URL parameter without adequate output encoding before reflecting it back to the user's browser. This condition allows an attacker to inject malicious script content into pages served by the application.

By leveraging this weakness, an attacker can cause the user's browser to redirect to a malicious website, modify the UI of the webpage, or retrieve information from the browser. However, the impact is mitigated by the use of httpOnly flags on session-related cookies, preventing session hijacking.

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 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.

Tokens issued to a low-privileged user are not sufficiently restricted, allowing them to be used to access product-level Admin REST APIs.

Exploitation of this vulnerability allows a low-privileged user to invoke the Admin REST APIs of WSO2 products, potentially leading to full administrative account takeover. This requires the attacker to already possess a low-privileged user account and be able to obtain a valid token for it.

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 information disclosure vulnerability exists in multiple WSO2 products due to improper implementation of the enrich mediator. Authenticated users may be able to view unintended business data from other mediation contexts because the internal state is not properly isolated or cleared between executions.

This vulnerability does not impact user credentials or access tokens but may lead to leakage of sensitive business information handled during message flows.

Due to an insufficient access control implementation in multiple WSO2 Products, authentication and authorization checks for certain REST APIs can be bypassed, allowing them to be invoked without proper validation.

Successful exploitation of this vulnerability could lead to a malicious actor gaining administrative access and performing unauthenticated and unauthorized administrative operations.

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.

SSRF and Reflected XSS Vulnerabilities exist in multiple WSO2 products within the deprecated Try-It feature, which was accessible only to administrative users. This feature accepted user-supplied URLs without proper validation, leading to server-side request forgery (SSRF). Additionally, the retrieved content was directly reflected in the HTTP response, enabling reflected cross-site scripting (XSS) in the admin user's browser context.

By tricking an administrator into accessing a crafted link, an attacker could force the server to fetch malicious content and reflect it into the admin’s browser, leading to arbitrary JavaScript execution for UI manipulation or data exfiltration. While session cookies are protected with the HttpOnly flag, the XSS still poses a significant security risk.

Furthermore, SSRF can be used by a privileged user to query internal services, potentially aiding in internal network enumeration if the target endpoints are reachable from the affected product.

A reflected cross-site scripting (XSS) vulnerability exists in the authentication endpoints of multiple WSO2 products due to a lack of output encoding. A malicious actor can inject arbitrary JavaScript payloads into the authentication endpoint, which are reflected back in the response, enabling browser-based attacks.

Exploitation may result in redirection to malicious websites, UI manipulation, or unauthorized data access from the victim’s browser. However, session-related cookies are protected with the httpOnly flag, which mitigates session hijacking via this vector.