Oracle Critical Patch Update July 2023
Released July 2023 · Oracle's advisory ↗ · ← Critical Patch Update, April 2023 · Critical Patch Update, October 2023 →
269 CVEs in this release, one square each
By status
45Protected by Waratek5Mitigation candidate105No exploit published31Outside Waratek scope83Not applicable
12Exploited, marked by the ring
No exploit published. For 37 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 107 matches · 59 in Waratek scope · 12 protected · 4 exploited · 0 CISA KEV · 4 public PoC · 6 EPSS ≥ 0.5
107matches
59in Waratek scope55.1%
12protected11.2%
4exploited3.7%
0CISA KEV0.0%
4public PoC3.7%
6EPSS ≥ 0.55.6%
Protected by Waratek
12
11.2%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
47
43.9%
Outside Waratek scope
17
15.9%
Not applicable
31
29.0%
Withdrawn CVE
0
0.0%
blocked by ARMR today
12
11.2%
partly blocked
0
0.0%
not blocked
95
88.8%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
4
3.7%
Working exploit published
0
0.0%
Proof of concept only
10
9.3%
Forecast only
3
2.8%
No public exploit
90
84.1%
split by
peak 37 / quarter
Q3 181
No exploit published1
Medium1
not blocked1
No public exploit1
Q4 180
Q1 190
Q2 190
Q3 190
Q4 190
Q1 200
Q2 200
Q3 200
Q4 203
Protected by Waratek2
Outside Waratek scope1
Medium3
blocked by ARMR today2
not blocked1
No public exploit3
Q1 213
No exploit published3
Medium3
not blocked3
Forecast only1
No public exploit2
Q2 213
Protected by Waratek1
No exploit published1
Not applicable1
Medium3
blocked by ARMR today1
not blocked2
No public exploit3
Q3 214
Protected by Waratek1
No exploit published2
Not applicable1
Medium4
blocked by ARMR today1
not blocked3
Exploited1
No public exploit3
Q4 215
Protected by Waratek2
Outside Waratek scope3
Medium5
blocked by ARMR today2
not blocked3
Exploited2
Proof of concept only1
No public exploit2
Q1 224
No exploit published1
Not applicable3
Medium4
not blocked4
No public exploit4
Q2 225
Protected by Waratek3
No exploit published2
Medium5
blocked by ARMR today3
not blocked2
Exploited1
Proof of concept only1
No public exploit3
Q3 227
Protected by Waratek2
No exploit published2
Outside Waratek scope1
Not applicable2
Medium7
blocked by ARMR today2
not blocked5
Proof of concept only3
No public exploit4
Q4 225
No exploit published3
Not applicable2
Medium5
not blocked5
Proof of concept only2
No public exploit3
Q1 2320
Protected by Waratek1
No exploit published7
Outside Waratek scope1
Not applicable11
Medium20
blocked by ARMR today1
not blocked19
Proof of concept only3
Forecast only1
No public exploit16
Q2 2310
No exploit published5
Not applicable5
Medium10
not blocked10
Forecast only1
No public exploit9
Q3 2337
No exploit published20
Outside Waratek scope11
Not applicable6
Medium37
not blocked37
No public exploit37
Q3 18Q1 19Q3 19Q1 20Q3 20Q1 21Q3 21Q1 22Q3 22Q1 23Q3 23
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2020-1926 | Medium | 2021-03-16 | No exploit published | No public exploit | Apache Hive cookie signature verification used a non constant time comparison which is known to be vulnerable to timing attacks. This could allow recovery of another users cookie signature. The issue was addressed in Apache Hive 2.3.8 |
| CVE-2021-21295 | Medium | 2021-03-09 | No exploit published | No public exploit | Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`. |
| CVE-2020-13947 | Medium | 2021-02-08 | No exploit published | Forecast only | An instance of a cross-site scripting vulnerability was identified to be present in the web based administration console on the message.jsp page of Apache ActiveMQ versions 5.15.12 through 5.16.0. |
| CVE-2020-17521 | Medium | 2020-12-07 | Protected by Waratek | No public exploit | Apache Groovy provides extension methods to aid with creating temporary directories. Prior to this fix, Groovy's implementation of those extension methods was using a now superseded Java JDK method call that is potentially not secure on some operating systems in some contexts. Users not using the extension methods mentioned in the advisory are not affected, but may wish to read the advisory for further details. Versions Affected: 2.0 to 2.4.20, 2.5.0 to 2.5.13, 3.0.0 to 3.0.6, and 4.0.0-alpha-1. Fixed in versions 2.4.21, 2.5.14, 3.0.7, 4.0.0-alpha-2. |
| CVE-2020-13956 | Medium | 2020-12-02 | Outside Waratek scope | No public exploit | Apache HttpClient versions prior to version 4.5.13 and 5.0.3 can misinterpret malformed authority component in request URIs passed to the library as java.net.URI object and pick the wrong target host for request execution. |
| CVE-2020-15250 | Medium | 2020-10-12 | Protected by Waratek | No public exploit | In JUnit4 from version 4.7 and before 4.13.1, the test rule TemporaryFolder contains a local information disclosure vulnerability. On Unix like systems, the system's temporary directory is shared between all users on that system. Because of this, when files and directories are written into this directory they are, by default, readable by other users on that same system. This vulnerability does not allow other users to overwrite the contents of these directories or files. This is purely an information disclosure vulnerability. This vulnerability impacts you if the JUnit tests write sensitive information, like API keys or passwords, into the temporary folder, and the JUnit tests execute in an environment where the OS has other untrusted users. Because certain JDK file system APIs were only added in JDK 1.7, this this fix is dependent upon the version of the JDK you are using. For Java 1.7 and higher users: this vulnerability is fixed in 4.13.1. For Java 1.6 and lower users: no patch is available, you must use the workaround below. If you are unable to patch, or are stuck running on Java 1.6, specifying the `java.io.tmpdir` system environment variable to a directory that is exclusively owned by the executing user will fix this vulnerability. For more information, including an example of vulnerable code, see the referenced GitHub Security Advisory. |
| CVE-2018-8032 | Medium | 2018-08-02 | No exploit published | No public exploit | Apache Axis 1.x up to and including 1.4 is vulnerable to a cross-site scripting (XSS) attack in the default servlet/services. |