Vendor scorecard
WSO2
WSO2 security disclosure record — CVE volume, CVSS severity mix and product-category breakdown, sourced from the NIST NVD.
CPE: wso2
Product families
1
Open in latest
71
Inferred — see methodology
Last disclosure
Aug 6, 2026
01
Product categories
1 trackedCVE volume, severity mix and the inferred latest shipping version per category.
| Category | CVEs | Volume | Severity mix | Open | Inferred latest |
|---|---|---|---|---|---|
| Identity Server (IAM/CIAM)Identity & Access Managementidentity_server, api_manager | 125 | 71 | 4.6.0.21HIGH |
02
Recent CVEs
12 shownMost recently published, newest first. Each ID links to its NVD record.
| CVE | Severity | CVSS | Summary | Published |
|---|---|---|---|---|
| CVE-2026-5430(opens NVD record) | Critical | 10.0 | The JWT authentication mechanism accepts tokens signed with algorithms other than those explicitly configured or supported. This allows an attacker to craft a JWT with an unsupported algorithm, which is then incorrectly validated, leading to unauthorized access. Successful exploitation of this vulnerability may result in unauthorized access to the system, including the potential compromise of administrative accounts and full account takeover. The CVSS score is adjusted to 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) in single-tenant deployments, reflecting that the impact is contained within a single security authority boundary. | Aug 6, 2026 |
| CVE-2026-1728(opens NVD record) | Critical | 9.8 | 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. | Aug 6, 2026 |
| CVE-2026-0637(opens NVD record) | Medium | 4.4 | When an Event Publisher output adapter is configured with irrelevant properties, the affected products log these properties. This logging occurs without sufficient validation or sanitization of the property values. A malicious actor with access to the 'wso2carbon' log files could retrieve sensitive information, such as user credentials or other confidential data, that was inadvertently logged due to misconfiguration, potentially leading to unauthorized access. | Aug 6, 2026 |
| CVE-2025-15039(opens NVD record) | Critical | 9.4 | 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 configured. This allows an attacker to bypass intermediate authentication challenges by exploiting how the script handles callbacks and re-execution of authentication steps. Successful exploitation allows a malicious actor to gain unauthorized access to a targeted user account. This vulnerability can only be exploited when all of the following conditions are met: the application login flow contains a specific secondary authenticator, the Conditional Authentication script is configured with particular event callbacks and re-executes an authentication step, the targeted user has one of the impacted authenticators enrolled, and the attacker successfully completes any preceding authentication steps. | Aug 6, 2026 |
| CVE-2025-14779(opens NVD record) | Low | 3.8 | The Secret Type Management REST API does not correctly isolate access controls when deleting a secret type. The on-delete cascade logic, when triggered, fails to enforce organizational boundaries, leading to the removal of secrets associated with that type across all organizations. Exploitation of this vulnerability can result in the unintended deletion of secrets across the entire deployment, potentially causing configuration failures, service interruptions, and a denial-of-service condition. This vulnerability requires delete permissions for the Secret Type Management REST API, which are by default only granted to administrators. | Aug 6, 2026 |
| CVE-2025-13909(opens NVD record) | Medium | 4.3 | 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 failure to adequately separate user data between tenants can lead to the exposure of personally identifiable information. Successful exploitation allows an attacker to disclose personally identifiable information of users in different tenants, resulting in privacy violations and potential regulatory non-compliance. This may include unauthorized access to user details such as mobile numbers. | Aug 6, 2026 |
| CVE-2025-13736(opens NVD record) | Low | 3.7 | When Multi-Attribute Login is enabled, the login interface fails to consistently mask the existence of user accounts. For valid users, the server resolves and displays their canonical username, while for non-existent users, it echoes the original input. This occurs regardless of the validate_username configuration. The discovery of valid usernames can increase the risk of brute force attacks, social engineering attacks, and targeted information leakage. Attackers can leverage this information to craft more effective phishing campaigns or social engineering tactics to compromise user accounts or extract sensitive data. | Aug 6, 2026 |
| CVE-2025-13394(opens NVD record) | Medium | 5.4 | The Ajax processor within the Carbon console fails to adequately protect state-changing operations from Cross-Site Request Forgery (CSRF) attacks. Specifically, it utilizes the HTTP GET method for these operations, and while the SameSite=Lax cookie attribute is employed for mitigation, this mechanism is bypassed as it permits cookies to be sent with cross-origin top-level navigation requests, including GET requests. This allows an attacker to trick an authenticated user's browser into unknowingly executing unintended actions. An attacker can exploit this vulnerability to perform unauthorized state-altering requests on behalf of authenticated users. This could lead to consequences such as data modification, account changes, or other actions that could result in data compromise or loss of user control over their account. However, this attack is only feasible if the Carbon console and related services are exposed to the public internet, which is not recommended according to WSO2's security guidelines. | Aug 6, 2026 |
| CVE-2025-12627(opens NVD record) | Low | 2.4 | The user impersonation flow in WSO2 Identity Server fails to properly manage refresh tokens associated with impersonated sessions. This allows an attacker who has obtained an access token for an impersonated user to leverage the refresh token grant to obtain new access tokens, extending their ability to act as the legitimate user. An attacker who gains access to an impersonated user's access token can exploit this weakness to renew their authorization. This results in the continued ability to perform actions on behalf of the actual user, compromising log integrity and traceability by masking the true actor. | Aug 6, 2026 |
| CVE-2025-11850(opens NVD record) | Medium | 4.3 | 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 allows a subject to be associated with an unintended local account if the same lookup claim (e.g., username or email) exists in both the primary and a secondary store. If duplicate claim values exist across user stores, this issue can lead to identity confusion due to incorrect implicit associations when using an external Identity Provider (IDP). Legitimate user accounts in the primary user store may fail to associate correctly with their corresponding external IDP accounts, potentially restricting access if the secondary account has fewer privileges. Deployments are not affected if no secondary user stores are configured, implicit association is disabled, or claim values are globally unique. | Aug 6, 2026 |
| CVE-2024-8995(opens NVD record) | Medium | 4.9 | Unused authorization codes issued to deleted users are not being properly invalidated or removed from the system. This allows for the persistence of these codes, enabling them to be potentially reused. If an attacker possesses both the authorization code and the associated client credentials (client ID and client secret), they can leverage these unused codes to obtain access tokens on behalf of users who have already been deleted. This may lead to unauthorized access to sensitive resources and services, contingent on the scopes originally authorized for the compromised authorization code. | Aug 6, 2026 |
| CVE-2024-6832(opens NVD record) | Medium | 5.9 | 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. | Aug 6, 2026 |
82 CVEs · 1 product families