Oracle Critical Patch Update July 2018
Released July 2018 · Oracle's advisory ↗ · ← Critical Patch Update, April 2018 · Critical Patch Update, October 2018 →
247 CVEs in this release, one square each
By status
16Protected by Waratek126No exploit published41Outside Waratek scope64Not applicable
7Exploited, marked by the ring
No exploit published. For 125 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 4 matches · 1 in Waratek scope · 1 protected · 0 exploited · 0 CISA KEV · 1 public PoC · 1 EPSS ≥ 0.5
4matches
1in Waratek scope25.0%
1protected25.0%
0exploited0.0%
0CISA KEV0.0%
1public PoC25.0%
1EPSS ≥ 0.525.0%
Protected by Waratek
1
25.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
0
0.0%
Outside Waratek scope
2
50.0%
Not applicable
1
25.0%
Withdrawn CVE
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
1
25.0%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
3
75.0%
split by
peak 2 / month
Apr 17May 17Jun 17
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2017-5664 | High | 2017-06-06 | Outside Waratek scope | No public exploit | The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method. If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. The Default Servlet in Apache Tomcat 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43 and 7.0.0 to 7.0.77 did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page. Notes for other user provided error pages: (1) Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must must ensure that they handle any error dispatch as a GET request, regardless of the actual method. (2) By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method. |
| CVE-2016-9843 | Critical | 2017-05-23 | Outside Waratek scope | No public exploit | The crc32_big function in crc32.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact via vectors involving big-endian CRC calculation. |
| CVE-2017-5662 | High | 2017-04-18 | Not applicable | No public exploit | In Apache Batik before 1.9, files lying on the filesystem of the server which uses batik can be revealed to arbitrary users who send maliciously formed SVG files. The file types that can be shown depend on the user context in which the exploitable application is running. If the user is root a full compromise of the server - including confidential or sensitive files - would be possible. XXE can also be used to attack the availability of the server via denial of service as the references within a xml document can trivially trigger an amplification attack. |
| CVE-2017-5645 | Critical | 2017-04-17 | Protected by Waratek | Working exploit published | In Apache Log4j 2.x before 2.8.2, when using the TCP socket server or UDP socket server to receive serialized log events from another application, a specially crafted binary payload can be sent that, when deserialized, can execute arbitrary code. |