Overview 5 matches · 4 in Waratek scope · 1 protected · 1 exploited · 0 CISA KEV · 1 public PoC · 1 EPSS ≥ 0.5
5matches
4in Waratek scope80.0%
1protected20.0%
1exploited20.0%
0CISA KEV0.0%
1public PoC20.0%
1EPSS ≥ 0.520.0%
Protected by Waratek
1
20.0%
Rule in development
0
0.0%
Mitigation candidate
1
20.0%
No exploit published
2
40.0%
Outside Waratek scope
1
20.0%
Not applicable
0
0.0%
Withdrawn CVE
0
0.0%
blocked by ARMR today
1
20.0%
partly blocked
0
0.0%
not blocked
4
80.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
1
20.0%
Working exploit published
0
0.0%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
4
80.0%
split by
peak 2 / quarter
Q4 221
No exploit published1
High1
not blocked1
No public exploit1
Q1 230
Q2 230
Q3 230
Q4 230
Q1 240
Q2 240
Q3 240
Q4 240
Q1 252
Protected by Waratek1
Outside Waratek scope1
High2
blocked by ARMR today1
not blocked1
No public exploit2
Q2 251
Mitigation candidate1
High1
not blocked1
Exploited1
Q3 250
Q4 251
No exploit published1
High1
not blocked1
No public exploit1
Q4 22Q2 23Q4 23Q2 24Q4 24Q2 25Q4 25
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2025-66566 | High | 2025-12-05 | No exploit published | No public exploit | yawkat LZ4 Java provides LZ4 compression for Java. Insufficient clearing of the output buffer in Java-based decompressor implementations in lz4-java 1.10.0 and earlier allows remote attackers to read previous buffer contents via crafted compressed input. In applications where the output buffer is reused without being cleared, this may lead to disclosure of sensitive data. JNI-based implementations are not affected. This vulnerability is fixed in 1.10.1. |
| CVE-2025-27817 | High | 2025-06-10 | Mitigation candidate | Exploited | A possible arbitrary file read and SSRF vulnerability has been identified in Apache Kafka Client. Apache Kafka Clients accept configuration data for setting the SASL/OAUTHBEARER connection with the brokers, including "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url". Apache Kafka allows clients to read an arbitrary file and return the content in the error log, or sending requests to an unintended location. In applications where Apache Kafka Clients configurations can be specified by an untrusted party, attackers may use the "sasl.oauthbearer.token.endpoint.url" and "sasl.oauthbearer.jwks.endpoint.url" configuratin to read arbitrary contents of the disk and environment variables or make requests to an unintended location. In particular, this flaw may be used in Apache Kafka Connect to escalate from REST API access to filesystem/environment/URL access, which may be undesirable in certain environments, including SaaS products. Since Apache Kafka 3.9.1/4.0.0, we have added a system property ("-Dorg.apache.kafka.sasl.oauthbearer.allowed.urls") to set the allowed urls in SASL JAAS configuration. In 3.9.1, it accepts all urls by default for backward compatibility. However in 4.0.0 and newer, the default value is empty list and users have to set the allowed urls explicitly. |
| CVE-2025-27553 | High | 2025-03-23 | Protected by Waratek | No public exploit | Relative Path Traversal vulnerability in Apache Commons VFS before 2.10.0. The FileObject API in Commons VFS has a 'resolveFile' method that takes a 'scope' parameter. Specifying 'NameScope.DESCENDENT' promises that "an exception is thrown if the resolved file is not a descendent of the base file". However, when the path contains encoded ".." characters (for example, "%2E%2E/bar.txt"), it might return file objects that are not a descendent of the base file, without throwing an exception. This issue affects Apache Commons VFS: before 2.10.0. Users are recommended to upgrade to version 2.10.0, which fixes the issue. |
| CVE-2025-0509 | High | 2025-02-04 | Outside Waratek scope | No public exploit | A security issue was found in Sparkle before version 2.6.4. An attacker can replace an existing signed update with another payload, bypassing Sparkle’s (Ed)DSA signing checks. |
| CVE-2022-42003 | High | 2022-10-02 | No exploit published | No public exploit | In FasterXML jackson-databind before versions 2.13.4.1 and 2.12.17.1, resource exhaustion can occur because of a lack of a check in primitive value deserializers to avoid deep wrapper array nesting, when the UNWRAP_SINGLE_VALUE_ARRAYS feature is enabled. |