Vulnerabilities

The administrative operations within the Carbon Console do not adequately validate specific user-supplied input.

The API Publisher component previously used a non-cryptographic pseudorandom number generator (PRNG) to create shared secrets for Webhook HMAC validation.

The JWT authentication mechanism accepts tokens signed with algorithms other than those explicitly configured or supported.

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

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 config…

When a proxy server is configured with `customUrl.enabled`, the component accepts user-supplied input within forwarded HTTP headers without enforcing expected validation constraints.

The Ajax processor within the Carbon console fails to adequately protect state-changing operations from Cross-Site Request Forgery (CSRF) attacks.

When Multi-Attribute Login is enabled, the login interface fails to consistently mask the existence of user accounts.

The user self-signup flow in multiple WSO2 products fails to adequately validate user-supplied input.

The account locking mechanism fails to trigger when secondary user stores are inaccessible.

Unused authorization codes issued to deleted users are not being properly invalidated or removed from the system.

The affected product accepts user-supplied input within a URL parameter without enforcing expected sanitization or encoding before rendering it within the response.

The throttling event handling mechanism in multiple WSO2 products accepts user-supplied JSON payloads without sufficient validation of their structure and content.

The software accepts user-supplied input via a URL parameter without adequate output encoding before reflecting it back to the user's browser.

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.

In multi-tenanted deployments, the application consent management mechanism fails to correctly isolate consent scopes between tenants.

The WSO2 API Manager's message flow component, when processing WS-Addressing headers, does not sufficiently validate or restrict user-controlled input within these headers.

The software fails to enforce role-based access controls for certain Gateway API invocations.

In Webhook API invocations, the component accepts user-supplied input for HTTP request headers without sufficient validation or sanitization, allowing these headers to be injected into HTTP responses.

The authentication endpoint fails to encode user-supplied input before rendering it in the web page, allowing for script injection.

The authentication endpoint fails to adequately validate user-supplied input before reflecting it back in the response.

The component accepts XML input through the publisher without disabling external entity resolution.

The WSO2 API Manager developer portal accepts user-supplied input without enforcing expected validation constraints or proper output encoding.

The XML parsers within multiple WSO2 products accept user-supplied XML data without properly configuring to prevent the resolution of external entities.

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…