The authentication endpoint accepts user-supplied input without enforcing expected validation constraints, leading to a lack of proper output encoding. This allows for the injection of malicious JavaScript payloads, enabling reflected cross-site scripting.
An attacker can leverage this vulnerability to redirect the user's browser to a malicious website, modify the user interface of the web page, retrieve information from the browser, or cause other harmful actions. However, due to the protection of session-related cookies with the httpOnly flag, session hijacking is not possible.
Active access tokens are not revoked or invalidated when a user account is locked within WSO2 Identity Server. This failure to enforce revocation allows previously issued, valid tokens to remain usable, enabling continued access to protected resources by locked user accounts.
The security consequence is that a locked user account can maintain access to protected resources through the use of existing, unexpired access tokens. This creates a security gap where access control policies are bypassed, potentially leading to unauthorized data access or actions until the tokens naturally expire.
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.
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.
When the "Silent Just-In-Time Provisioning" feature is enabled for a federated identity provider (IDP) there is a risk that a local user store user's information may be replaced during the account provisioning process in cases where federated users share the same username as local users.
There will be no impact on your deployment if any of the preconditions mentioned below are not met. Only when all the preconditions mentioned below are fulfilled could a malicious actor associate a targeted local user account with a federated IDP user account that they control.
The Deployment should have:
-An IDP configured for federated authentication with Silent JIT provisioning enabled.
The malicious actor 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.
-An account at the federated IDP matching the targeted local username.
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.
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.
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.
A reflected cross-site scripting (XSS) vulnerability exists in the management console of multiple WSO2 products due to improper output encoding. By tampering with specific parameters, a malicious actor can inject arbitrary JavaScript into the response, leading to reflected XSS.
Successful exploitation could result in UI manipulation, redirection to malicious websites, or data theft from the browser. However, session-related sensitive cookies are protected with the httpOnly flag, which mitigates the risk of session hijacking.
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.