Overview 4 matches · 0 in Waratek scope · 0 protected · 0 exploited · 0 CISA KEV · 1 public PoC · 2 EPSS ≥ 0.5
4matches
0in Waratek scope0.0%
0protected0.0%
0exploited0.0%
0CISA KEV0.0%
1public PoC25.0%
2EPSS ≥ 0.550.0%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
0
0.0%
Outside Waratek scope
1
25.0%
Not applicable
3
75.0%
Withdrawn CVE
0
0.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
4
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
1
25.0%
Proof of concept only
0
0.0%
Forecast only
1
25.0%
No public exploit
2
50.0%
split by
peak 1 / quarter
Q2 161
Not applicable1
Medium1
not blocked1
Working exploit published1
Q3 161
Not applicable1
High1
not blocked1
Forecast only1
Q4 160
Q1 170
Q2 171
Not applicable1
Medium1
not blocked1
No public exploit1
Q3 170
Q4 170
Q1 180
Q2 180
Q3 180
Q4 180
Q1 191
Outside Waratek scope1
Medium1
not blocked1
No public exploit1
Q2 16Q3 16Q4 16Q1 17Q2 17Q3 17Q4 17Q1 18Q2 18Q3 18Q4 18Q1 19
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2019-1559 | Medium | 2019-02-27 | Outside Waratek scope | No public exploit | If an application encounters a fatal protocol error and then calls SSL_shutdown() twice (once to send a close_notify, and once to receive one) then OpenSSL can respond differently to the calling application if a 0 byte record is received with invalid padding compared to if a 0 byte record is received with an invalid MAC. If the application then behaves differently based on that in a way that is detectable to the remote peer, then this amounts to a padding oracle that could be used to decrypt data. In order for this to be exploitable "non-stitched" ciphersuites must be in use. Stitched ciphersuites are optimised implementations of certain commonly used ciphersuites. Also the application must call SSL_shutdown() twice even if a protocol error has occurred (applications should not do this but some do anyway). Fixed in OpenSSL 1.0.2r (Affected 1.0.2-1.0.2q). |
| CVE-2017-3732 | Medium | 2017-05-04 | Not applicable | No public exploit | There is a carry propagating bug in the x86_64 Montgomery squaring procedure in OpenSSL 1.0.2 before 1.0.2k and 1.1.0 before 1.1.0d. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. For example this can occur by default in OpenSSL DHE based SSL/TLS ciphersuites. Note: This issue is very similar to CVE-2015-3193 but must be treated as a separate problem. |
| CVE-2016-6304 | High | 2016-09-26 | Not applicable | Forecast only | Multiple memory leaks in t1_lib.c in OpenSSL before 1.0.1u, 1.0.2 before 1.0.2i, and 1.1.0 before 1.1.0a allow remote attackers to cause a denial of service (memory consumption) via large OCSP Status Request extensions. |
| CVE-2016-2107 | Medium | 2016-05-05 | Not applicable | Working exploit published | The AES-NI implementation in OpenSSL before 1.0.1t and 1.0.2 before 1.0.2h does not consider memory allocation during a certain padding check, which allows remote attackers to obtain sensitive cleartext information via a padding-oracle attack against an AES CBC session. NOTE: this vulnerability exists because of an incorrect fix for CVE-2013-0169. |