Privilege escalation via client credentials grant in WSO2 Identity Server
The system fails to properly enforce scope authorization when the `authorize_all_scopes` configuration is enabled.
187 records
The system fails to properly enforce scope authorization when the `authorize_all_scopes` configuration is enabled.
This issue only impacts deployments where WSO2 Identity Server is configured as a Resident Key Manager with database sharing.
The authentication endpoint does not properly encode user-supplied input before rendering it within the web page.
When utilizing JWT Bearer or SAML2 Bearer grant types, the system fails to validate the status of the Identity Provider (IDP) before issuing access tokens.
The error handling implementation fails to properly sanitize or validate user-supplied input within URL parameters under specific conditions.
The product fails to sufficiently validate callback URLs, allowing them to be manipulated with malicious payloads when processed through a weak regular expression or when validation is omitted.
The refresh token grant type in WSO2 products fails to re-validate account status before issuing new access tokens.
The affected components accept user-supplied input for constructing redirection URLs without enforcing expected validation constraints.
The Publisher portal fails to enforce proper validation on uploaded SVG files, allowing users with the Publisher role to inject malicious scripts.
The Admin REST API accepts user-supplied input without adequately sanitizing it, allowing it to be included in the structure of SQL statements.
When an Event Publisher output adapter is configured with properties that are irrelevant to its function, the affected products log these irrelevant properties.
The affected component fails to enforce expected validation constraints on the `content-type` header when processing certain requests.
The user search function within the management console fails to properly encode user-supplied input before rendering it in the browser.
The account lock feature fails to correctly enforce account lockouts on the primary user store when users with identical usernames exist in both primary and secondary user stores.
The System REST APIs do not correctly enforce access control mechanisms, allowing users with lower privilege roles to execute administrative actions that should be restricted.
The BPMN System REST APIs do not sufficiently validate input parameters, allowing authenticated users to submit crafted requests that can lead to the execution of arbitrary commands on the server.
In deployments of WSO2 Identity Server configured with a case-insensitive user store and a case-sensitive database for identity data, mismatches in username case handling can occur.
When the `allowed_scopes` configuration is enabled, the OAuth2 token introspection mechanism does not immediately invalidate a token in the cache after a revocation request.
The authentication endpoint generates an error message that includes reflected data directly from the request without sufficient sanitization or encoding.
Due to the improper implementation of access control rules, malicious actors could perform a Server Side Request Forgery (SSRF) attack on affected WSO2 Products.
The product failed to enforce validation constraints on user-supplied input in URL parameters, allowing sensitive data to be passed to flows where it was not intended to be processed.
The system fails to invalidate existing access tokens associated with sub-organization users during sensitive account management operations such as password reset, role change, or sub-organization disablement.
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.
Due to an incomplete implementation, reCaptcha is not applied to certain authentication flows even when the reCaptcha option is enabled.
The callback URL parameter in WSO2 API Manager fails to validate user-supplied input, allowing it to be controlled by malicious actors.