WaratekVRT Sign in
Reset
More filters (2)
Columns
Published from 2024-04-01✕Oracle product: Oracle SQL Developer✕
Overview 3 matches · 1 protected · 1 exploited · 0 CISA KEV · 1 public PoC · 1 EPSS ≥ 0.5
3matches 1protected33.3% 1exploited33.3% 0CISA KEV0.0% 1public PoC33.3% 1EPSS ≥ 0.533.3%
Protected by Waratek 1 33.3% Rule in development 0 0.0% Mitigation candidate 1 33.3% No exploit published 1 33.3%
Critical 0 0.0% High 3 100.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 1 33.3% partly blocked 0 0.0% not blocked 2 66.7% not established 0 0.0% unrecorded 0 0.0%
Exploited 1 33.3% Working exploit published 0 0.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 2 66.7%
split by peak 1 / month
No exploit published: 1Mitigation candidate: 1Protected by Waratek: 1 High: 3 not blocked: 2blocked by ARMR today: 1 No public exploit: 2Exploited: 1
Mar 251 Protected by Waratek1 High1 blocked by ARMR today1 No public exploit1 Apr 250 May 250 Jun 251 Mitigation candidate1 High1 not blocked1 Exploited1 Jul 250 Aug 250 Sep 250 Oct 250 Nov 250 Dec 251 No exploit published1 High1 not blocked1 No public exploit1
Mar 25Apr 25May 25Jun 25Jul 25Aug 25Sep 25Oct 25Nov 25Dec 25
3 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
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.