Overview 4 matches · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
4matches
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
4
100.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
0
0.0%
blocked by ARMR today
4
100.0%
partly blocked
0
0.0%
not blocked
0
0.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
0
0.0%
No public exploit
4
100.0%
split by
peak 1 / quarter
Q2 181
Protected by Waratek1
Critical1
blocked by ARMR today1
No public exploit1
Q3 181
Protected by Waratek1
Critical1
blocked by ARMR today1
No public exploit1
Q4 180
Q1 190
Q2 190
Q3 190
Q4 191
Protected by Waratek1
Medium1
blocked by ARMR today1
No public exploit1
Q1 200
Q2 201
Protected by Waratek1
Critical1
blocked by ARMR today1
No public exploit1
Q2 18Q3 18Q4 18Q1 19Q2 19Q3 19Q4 19Q1 20Q2 20
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2020-10683 | Critical | 2020-05-01 | Protected by Waratek | No public exploit | dom4j before 2.0.3 and 2.1.x before 2.1.3 allows external DTDs and External Entities by default, which might enable XXE attacks. However, there is popular external documentation from OWASP showing how to enable the safe, non-default behavior in any application that uses dom4j. |
| CVE-2019-10219 | Medium | 2019-11-08 | Protected by Waratek | No public exploit | A vulnerability was found in Hibernate-Validator. The SafeHtml validator annotation fails to properly sanitize payloads consisting of potentially malicious code in HTML comments and instructions. This vulnerability can result in an XSS attack. |
| CVE-2018-1000613 | Critical | 2018-07-09 | Protected by Waratek | No public exploit | Legion of the Bouncy Castle Legion of the Bouncy Castle Java Cryptography APIs 1.58 up to but not including 1.60 contains a CWE-470: Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') vulnerability in XMSS/XMSS^MT private key deserialization that can result in Deserializing an XMSS/XMSS^MT private key can result in the execution of unexpected code. This attack appear to be exploitable via A handcrafted private key can include references to unexpected classes which will be picked up from the class path for the executing application. This vulnerability appears to have been fixed in 1.60 and later. |
| CVE-2018-8013 | Critical | 2018-05-24 | Protected by Waratek | No public exploit | In Apache Batik 1.x before 1.10, when deserializing subclass of `AbstractDocument`, the class takes a string from the inputStream as the class name which then use it to call the no-arg constructor of the class. Fix was to check the class type before calling newInstance in deserialization. |