WaratekVRT Sign in
Reset
More filters (1)
Columns
Including CVEs outside Waratek scope✕Product snapmanager✕
Overview 3 matches · 2 in Waratek scope · 1 protected · 0 exploited · 0 CISA KEV · 0 public PoC
3matches 2in Waratek scope66.7% 1protected33.3% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0%
Protected by Waratek 1 33.3% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 1 33.3% Outside Waratek scope 1 33.3% Not applicable 0 0.0% Withdrawn CVE 0 0.0%
Critical 0 0.0% High 1 33.3% Medium 2 66.7% 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 0 0.0% Working exploit published 0 0.0% Proof of concept only 0 0.0% Forecast only 3 100.0% No public exploit 0 0.0%
split by peak 1 / quarter
Q2 21Q4 21Q2 22Q4 22Q2 23Q4 23Q2 24
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-2024-2511 Medium 2024-04-08 Outside Waratek scope Forecast only Issue summary: Some non-default TLS server configurations can cause unbounded memory growth when processing TLSv1.3 sessions Impact summary: An attacker may exploit certain server configurations to trigger unbounded memory growth that would lead to a Denial of Service This problem can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option is being used (but not if early_data support is also configured and the default anti-replay protection is in use). In this case, under certain conditions, the session cache can get into an incorrect state and it will fail to flush properly as it fills. The session cache will continue to grow in an unbounded manner. A malicious client could deliberately create the scenario for this failure to force a Denial of Service. It may also happen by accident in normal operation. This issue only affects TLS servers supporting TLSv1.3. It does not affect TLS clients. The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL 1.0.2 is also not affected by this issue.
CVE-2022-23302 High 2022-01-18 Protected by Waratek Forecast only JMSSink in all versions of Log4j 1.x is vulnerable to deserialization of untrusted data when the attacker has write access to the Log4j configuration or if the configuration references an LDAP service the attacker has access to. The attacker can provide a TopicConnectionFactoryBindingName configuration causing JMSSink to perform JNDI requests that result in remote code execution in a similar fashion to CVE-2021-4104. Note this issue only affects Log4j 1.x when specifically configured to use JMSSink, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2 as it addresses numerous other issues from the previous versions.
CVE-2020-27223 Medium 2021-02-26 No exploit published Forecast only In Eclipse Jetty 9.4.6.v20170531 to 9.4.36.v20210114 (inclusive), 10.0.0, and 11.0.0 when Jetty handles a request containing multiple Accept headers with a large number of “quality” (i.e. q) parameters, the server may enter a denial of service (DoS) state due to high CPU usage processing those quality values, resulting in minutes of CPU time exhausted processing those quality values.