Oracle Critical Patch Update July 2016
Released July 2016 · Oracle's advisory ↗ · ← Critical Patch Update, April 2016 · Critical Patch Update, October 2016 →
222 CVEs in this release, one square each
By status
4Protected by Waratek1Mitigation candidate108No exploit published30Outside Waratek scope79Not applicable
4Exploited, marked by the ring
No exploit published. For 108 of them, Oracle's security advisory is the source of public detail.
Protected by Waratek. Waratek RASP can block exploitation of these on systems that have not applied the patch yet.
Overview 202 matches · 113 in Waratek scope · 4 protected · 2 exploited · 1 CISA KEV · 6 public PoC · 5 EPSS ≥ 0.5
202matches
113in Waratek scope55.9%
4protected2.0%
2exploited1.0%
1CISA KEV0.5%
6public PoC3.0%
5EPSS ≥ 0.52.5%
Protected by Waratek
4
2.0%
Rule in development
0
0.0%
Mitigation candidate
1
0.5%
No exploit published
108
53.5%
Outside Waratek scope
20
9.9%
Not applicable
69
34.2%
Withdrawn CVE
0
0.0%
blocked by ARMR today
4
2.0%
partly blocked
0
0.0%
not blocked
198
98.0%
not established
0
0.0%
unrecorded
0
0.0%
split by
peak 193 / quarter
Q1 163
Outside Waratek scope1
Not applicable2
Medium3
not blocked3
Proof of concept only1
No public exploit2
Q2 163
Protected by Waratek1
Not applicable2
High2
Medium1
blocked by ARMR today1
not blocked2
Exploited1
Working exploit published1
No public exploit1
Q3 16193
Protected by Waratek2
Mitigation candidate1
No exploit published108
Outside Waratek scope19
Not applicable63
Critical20
High62
Medium96
Low15
blocked by ARMR today2
not blocked191
Working exploit published2
No public exploit191
Q4 160
Q1 171
Not applicable1
High1
not blocked1
No public exploit1
Q2 170
Q3 171
Not applicable1
High1
not blocked1
No public exploit1
Q4 171
Protected by Waratek1
Critical1
blocked by ARMR today1
Exploited1
Q1 16Q2 16Q3 16Q4 16Q1 17Q2 17Q3 17Q4 17
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2016-0800 | Medium | 2016-03-01 | Not applicable | Proof of concept only | The SSLv2 protocol, as used in OpenSSL before 1.0.1s and 1.0.2 before 1.0.2g and other products, requires a server to send a ServerVerify message before establishing that a client possesses certain plaintext RSA data, which makes it easier for remote attackers to decrypt TLS ciphertext data by leveraging a Bleichenbacher RSA padding oracle, aka a "DROWN" attack. |
| CVE-2015-3197 | Medium | 2016-02-15 | Outside Waratek scope | No public exploit | ssl/s2_srvr.c in OpenSSL 1.0.1 before 1.0.1r and 1.0.2 before 1.0.2f does not prevent use of disabled ciphers, which makes it easier for man-in-the-middle attackers to defeat cryptographic protection mechanisms by performing computations on SSLv2 traffic, related to the get_client_master_key and get_client_hello functions. |