CVE-2024-4457

The refresh token grant type in WSO2 products fails to re-validate account status before issuing new access tokens. This allows an attacker to obtain valid access tokens for user accounts even after they have been blocked by the user store, bypassing account lockout mechanisms.

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. Successful exploitation allows a malicious actor with network access to the affected endpoints to gain administrative privileges and perform unauthorized operations.

Due to improper implementation of access control rules, the WSO2 product accepts user-supplied input related to resource location without enforcing expected validation constraints. An unauthenticated actor can direct the server to make requests to arbitrary network locations, accessing internal and external resources reachable by the product.

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 allows an attacker to repeatedly query the authentication mechanism with different username guesses, enabling enumeration of valid usernames in the external user store.

In WSO2 products, when internal roles are removed from a user, the system fails to invalidate previously issued authentication tokens. Users may retain access privileges even after role revocation.

The Class Mediator in WSO2 products fails to properly validate or sanitize messageContext properties used for dynamic values. Authenticated users may access or modify data across invocations.

When an Event Publisher output adapter is configured with irrelevant properties, the affected products log these properties without sufficient validation or sanitization. An attacker with access to 'wso2carbon' log files could retrieve sensitive information, such as credentials, potentially leading to unauthorized access.

The system accepts authentication requests without sufficient validation to enforce tenant isolation when using Email OTP, SMS OTP, or Magic Link as first-factor authenticators. This can lead to exposure of personally identifiable information of users in different tenants.

When secondary user stores are configured, the implicit-association resolver incorrectly initializes from a secondary user store and bypasses the primary user store during search and uniqueness checks. This can lead to associating a subject with an unintended local account if the same lookup claim exists in both stores.

The throttling event handling mechanism in multiple WSO2 products accepts user-supplied JSON payloads without sufficient validation of their structure and content. This allows an unauthenticated remote attacker to inject malicious JSON data that can lead to a persistent denial of service condition.