Overview 7 matches · 0 protected · 1 exploited · 0 CISA KEV · 2 public PoC · 0 EPSS ≥ 0.5
Protected by Waratek
0
0.0%
Rule in development
1
14.3%
Mitigation candidate
1
14.3%
No exploit published
5
71.4%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
7
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
1
14.3%
Working exploit published
1
14.3%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
5
71.4%
split by
peak 3 / month
Sep 251
No exploit published1
Medium1
not blocked1
No public exploit1
Oct 252
Rule in development1
Mitigation candidate1
Medium2
not blocked2
Exploited1
Working exploit published1
Nov 251
No exploit published1
Medium1
not blocked1
No public exploit1
Dec 250
Jan 260
Feb 260
Mar 260
Apr 260
May 260
Jun 260
Jul 260
Aug 263
No exploit published3
Medium3
not blocked3
No public exploit3
Sep 25Oct 25Nov 25Dec 25Jan 26Feb 26Mar 26Apr 26May 26Jun 26Jul 26Aug 26
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2025-13394 | Medium | 2026-08-06 | No exploit published | No public exploit | 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. |
| CVE-2024-8995 | Medium | 2026-08-06 | No exploit published | No public exploit | 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. |
| CVE-2024-10302 | Medium | 2026-08-06 | No exploit published | No public exploit | The user self-signup flow in multiple WSO2 products fails to adequately validate user-supplied input. This weakness allows arbitrary unvalidated data to be included within user claims, which are then used by downstream processes. Allowing unvalidated input into user claims can lead to various security risks. Malicious or malformed data injected during signup could be processed by other parts of the application, potentially enabling attacks such as content manipulation, redirection, user interface inconsistencies, unauthorized actions, and data exposure. The actual impact depends on how the compromised data is consumed and the privileges associated with the affected users. |
| CVE-2025-10853 | Medium | 2025-11-05 | No exploit published | No public exploit | 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. |
| CVE-2025-5605 | Medium | 2025-10-24 | Mitigation candidate | Exploited | An authentication bypass vulnerability exists in the Management Console of multiple WSO2 products. A malicious actor with access to the console can manipulate the request URI to bypass authentication and access certain restricted resources, resulting in partial information disclosure. The known exposure from this issue is limited to memory statistics. While the vulnerability does not allow full account compromise, it still enables unauthorized access to internal system details. |
| CVE-2025-5350 | Medium | 2025-10-24 | Rule in development | Working exploit published | SSRF and Reflected XSS Vulnerabilities exist in multiple WSO2 products within the deprecated Try-It feature, which was accessible only to administrative users. This feature accepted user-supplied URLs without proper validation, leading to server-side request forgery (SSRF). Additionally, the retrieved content was directly reflected in the HTTP response, enabling reflected cross-site scripting (XSS) in the admin user's browser context. By tricking an administrator into accessing a crafted link, an attacker could force the server to fetch malicious content and reflect it into the admin’s browser, leading to arbitrary JavaScript execution for UI manipulation or data exfiltration. While session cookies are protected with the HttpOnly flag, the XSS still poses a significant security risk. Furthermore, SSRF can be used by a privileged user to query internal services, potentially aiding in internal network enumeration if the target endpoints are reachable from the affected product. |
| CVE-2025-4760 | Medium | 2025-09-23 | No exploit published | No public exploit | An authenticated stored cross-site scripting (XSS) vulnerability exists in multiple WSO2 products due to improper validation of user-supplied input during API document upload in the Publisher portal. A user with publisher privileges can upload a crafted API document containing malicious JavaScript, which is later rendered in the browser when accessed by other users. A successful attack could result in redirection to malicious websites, unauthorized UI modifications, or exfiltration of browser-accessible data. However, session-related sensitive cookies are protected by the httpOnly flag, preventing session hijacking. |