WaratekVRT Sign in

High Netapp CVEs with no public exploit

4 CVEs, 1 protected by Waratek

Reset
More filters (1)
Columns
Vendor netapp✕
Overview 4 matches · 1 protected · 0 exploited · 0 CISA KEV · 0 public PoC
4matches 1protected25.0% 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0%
Protected by Waratek 1 25.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 3 75.0%
Critical 0 0.0% High 4 100.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 1 25.0% partly blocked 0 0.0% not blocked 3 75.0% 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 4 100.0% No public exploit 0 0.0%
split by peak 1 / quarter
No exploit published: 3Protected by Waratek: 1 High: 4 not blocked: 3blocked by ARMR today: 1 Forecast only: 4
Q3 201 No exploit published1 High1 not blocked1 Forecast only1 Q4 200 Q1 211 No exploit published1 High1 not blocked1 Forecast only1 Q2 211 No exploit published1 High1 not blocked1 Forecast only1 Q3 210 Q4 210 Q1 221 Protected by Waratek1 High1 blocked by ARMR today1 Forecast only1
Q3 20Q4 20Q1 21Q2 21Q3 21Q4 21Q1 22
4 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-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-2021-28165 High 2021-04-01 No exploit published Forecast only In Eclipse Jetty 7.2.2 to 9.4.38, 10.0.0.alpha0 to 10.0.1, and 11.0.0.alpha0 to 11.0.1, CPU usage can reach 100% upon receiving a large invalid TLS frame.
CVE-2021-21341 High 2021-03-23 No exploit published Forecast only XStream is a Java library to serialize objects to XML and back again. In XStream before version 1.4.16, there is vulnerability which may allow a remote attacker to allocate 100% CPU time on the target system depending on CPU type or parallel execution of such a payload resulting in a denial of service only by manipulating the processed input stream. No user is affected who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types. If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.16.
CVE-2020-13934 High 2020-07-14 No exploit published Forecast only An h2c direct connection to Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M5 to 9.0.36 and 8.5.1 to 8.5.56 did not release the HTTP/1.1 processor after the upgrade to HTTP/2. If a sufficient number of such requests were made, an OutOfMemoryException could occur leading to a denial of service.