Overview 6 matches · 0 protected · 4 exploited · 1 CISA KEV · 5 public PoC · 2 EPSS ≥ 0.5
Protected by Waratek
0
0.0%
Rule in development
6
100.0%
Mitigation candidate
0
0.0%
No exploit published
0
0.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
6
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
4
66.7%
Working exploit published
2
33.3%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
0
0.0%
split by
peak 2 / quarter
Q2 211
Rule in development1
Critical1
not blocked1
Working exploit published1
Q3 210
Q4 210
Q1 220
Q2 221
Rule in development1
High1
not blocked1
Exploited1
Q3 220
Q4 220
Q1 230
Q2 230
Q3 230
Q4 230
Q1 240
Q2 240
Q3 240
Q4 240
Q1 250
Q2 251
Rule in development1
High1
not blocked1
Exploited1
Q3 251
Rule in development1
Medium1
not blocked1
Exploited1
Q4 252
Rule in development2
High1
Medium1
not blocked2
Exploited1
Working exploit published1
Q2 21Q4 21Q2 22Q4 22Q2 23Q4 23Q2 24Q4 24Q2 25Q4 25
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| 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-61884 | High | 2025-10-12 | Rule in development | Exploited | Vulnerability in the Oracle Configurator product of Oracle E-Business Suite (component: Runtime UI). Supported versions that are affected are 12.2.3-12.2.14. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Configurator. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Configurator accessible data. CVSS 3.1 Base Score 7.5 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). |
| CVE-2025-4581 | Medium | 2025-08-09 | Rule in development | Exploited | Liferay Portal 7.4.0 through 7.4.3.132, and Liferay DXP 2025.Q1.0 through 2025.Q1.4 ,2024.Q4.0 through 2024.Q4.7, 2024.Q3.1 through 2024.Q3.13, 2024.Q2.0 through 2024.Q2.13, 2024.Q1.1 through 2024.Q1.15, 7.4 GA through update 92 allows a pre-authentication blind SSRF vulnerability in the portal-settings-authentication-opensso-web due to improper validation of user-supplied URLs. An attacker can exploit this issue to force the server to make arbitrary HTTP requests to internal systems, potentially leading to internal network enumeration or further exploitation. |
| CVE-2024-29198 | High | 2025-06-10 | Rule in development | Exploited | GeoServer is an open source software server written in Java that allows users to share and edit geospatial data. It possible to achieve Service Side Request Forgery (SSRF) via the Demo request endpoint if Proxy Base URL has not been set. Upgrading to GeoServer 2.24.4, or 2.25.2, removes the TestWfsPost servlet resolving this issue. |
| CVE-2021-40822 | High | 2022-05-02 | Rule in development | Exploited | GeoServer through 2.18.5 and 2.19.x through 2.19.2 allows SSRF via the option for setting a proxy host. |
| CVE-2021-27905 | Critical | 2021-04-13 | Rule in development | Working exploit published | The ReplicationHandler (normally registered at "/replication" under a Solr core) in Apache Solr has a "masterUrl" (also "leaderUrl" alias) parameter that is used to designate another ReplicationHandler on another Solr core to replicate index data into the local core. To prevent a SSRF vulnerability, Solr ought to check these parameters against a similar configuration it uses for the "shards" parameter. Prior to this bug getting fixed, it did not. This problem affects essentially all Solr versions prior to it getting fixed in 8.8.2. |