Overview 6 matches · 0 in Waratek scope · 0 protected · 3 exploited · 2 CISA KEV · 5 public PoC
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
0
0.0%
Outside Waratek scope
1
16.7%
Not applicable
5
83.3%
Withdrawn CVE
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
3
50.0%
Working exploit published
2
33.3%
Proof of concept only
0
0.0%
Forecast only
1
16.7%
No public exploit
0
0.0%
split by
peak 2 / year
20141
Not applicable1
High1
not blocked1
Exploited1
20150
20160
20170
20181
Not applicable1
Medium1
not blocked1
Exploited1
20190
20200
20211
Outside Waratek scope1
High1
not blocked1
Forecast only1
20220
20232
Not applicable2
High2
not blocked2
Working exploit published2
20240
20250
20261
Not applicable1
Critical1
not blocked1
Exploited1
2014201620182020202220242026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-20253 | Critical | 2026-06-10 | Not applicable | Exploited | In Splunk Enterprise 10.2 versions below 10.2.4 and 10 versions below 10.0.7, an unauthenticated user could create or truncate arbitrary files through a PostgreSQL sidecar service endpoint. The vulnerability exists because the PostgreSQL sidecar service endpoint lacks authentication controls, allowing any network-reachable user to invoke file operations without credentials. Splunk Enterprise versions 9.4 and earlier are not affected. If you cannot immediately upgrade to a fixed version, you can mitigate this vulnerability by disabling the PostgreSQL sidecar service. |
| CVE-2023-46214 | High | 2023-11-16 | Not applicable | Working exploit published | In Splunk Enterprise versions below 9.0.7 and 9.1.2, Splunk Enterprise does not safely sanitize extensible stylesheet language transformations (XSLT) that users supply. This means that an attacker can upload malicious XSLT which can result in remote code execution on the Splunk Enterprise instance. |
| CVE-2023-32707 | High | 2023-06-01 | Not applicable | Working exploit published | In versions of Splunk Enterprise below 9.0.5, 8.2.11, and 8.1.14, and Splunk Cloud Platform below version 9.0.2303.100, a low-privileged user who holds a role that has the ‘edit_user’ capability assigned to it can escalate their privileges to that of the admin user by providing specially crafted web requests. |
| CVE-2021-22901 | High | 2021-06-11 | Outside Waratek scope | Forecast only | curl 7.75.0 through 7.76.1 suffers from a use-after-free vulnerability resulting in already freed memory being used when a TLS 1.3 session ticket arrives over a connection. A malicious server can use this in rare unfortunate circumstances to potentially reach remote code execution in the client. When libcurl at run-time sets up support for TLS 1.3 session tickets on a connection using OpenSSL, it stores pointers to the transfer in-memory object for later retrieval when a session ticket arrives. If the connection is used by multiple transfers (like with a reused HTTP/1.1 connection or multiplexed HTTP/2 connection) that first transfer object might be freed before the new session is established on that connection and then the function will access a memory buffer that might be freed. When using that memory, libcurl might even call a function pointer in the object, making it possible for a remote code execution if the server could somehow manage to get crafted memory content into the correct place in memory. |
| CVE-2018-11409 | Medium | 2018-06-08 | Not applicable | Exploited | Splunk through 7.0.1 allows information disclosure by appending __raw/services/server/info/server-info?output_mode=json to a query, as demonstrated by discovering a license key. |
| CVE-2014-0160 | High | 2014-04-07 | Not applicable | Exploited | The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeat Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c, aka the Heartbleed bug. |