It was discovered that the AccessController class implementation in the Security component of OpenJDK failed, in certain cases, to consider the current context and correctly restrict privileges based on it. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.
A use-after-free vulnerability was discovered in the pngimagefree function in the libpng library. This could lead to denial of service or a potentially exploitable crash when a malformed image is processed.
A flaw was found in the BigDecimal implementation in the Libraries component of OpenJDK. An untrusted numeric value parsed by a Java application could the application to use an excessive amount of CPU time.
A flaw was found in the RMI registry implementation in the RMI component of OpenJDK. Incorrect handling of the server-side dispatch could lead to selection of an incorrect skeleton class.
Vulnerability in the Java SE, Java SE Embedded component of Oracle Java SE (subcomponent: Networking). Supported versions that are affected are Java SE: 7u221, 8u212, 11.0.3 and 12.0.1; Java SE Embedded: 8u211. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Java SE, Java SE Embedded accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.0 Base Score 3.1 (Confidentiality impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N).
It was discovered that the implementation of the Collections class in the Utilities component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.
It was discovered that crypto provider implementations in the JCE component of OpenJDK for crypto algorithms such as AES or SHA did not perform array bounds checks. This could lead to out-of-bounds access if compiler intrinsics were used instead of the Java runtime implementations of the specific operations.
The Elliptic Curve (EC) cryptography in the Security component of OpenJDK was modernized to use formulas that are more efficient, easier to implement, and offer greater resiliency against side-channel attacks (timing or cache).
For more detailed information, refer to upstream bug:
https://bugs.openjdk.java.net/browse/JDK-8208698
Upstream commit:
http://hg.openjdk.java.net/jdk/jdk/rev/752e57845ad2
A out of bounds access flaw was found in the font layout engine in the 2D component of OpenJDK. Missing validation of the position value in GlyphIterator::setCurrGlyphID could lead to memory corruption, triggered by a specially crafted font file. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.
A memory disclosure flaw was found in the FileChannelImpl class in the Libraries component of OpenJDK. An untrusted Java application or applet could use this flaw leak limited amount of Java Virtual Machine memory possibly containing sensitive information, resulting in a partial bypass of Java sandbox restrictions.
It was discovered that the implementation of the Throwable class in the Utilities component of OpenJDK did not sufficiently validate serial stream before deserializing suppressed exceptions. A specially-crafted input could cause a Java application to construct inconsistent object and possibly use an excessive amount of system resources when deserialized.
An input validation flaw was found in the URL class implementation in the Networking component of OpenJDK. A URL class instance could have been created for a URL string containing invalid characters not permitted in URLs.
Vulnerability in the Java SE component of Oracle Java SE (subcomponent: Networking). Supported versions that are affected are Java SE: 7u201, 8u192 and 11.0.1; Java SE Embedded: 8u191. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Java SE accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.0 Base Score 3.7 (Confidentiality impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).
Oracle Java SE 6u201, 7u191, 8u181, and 10.0.2 fixes an unspecified vulnerability in the JSSE component (CVE-2018-2973). Upstream has CVSS scored this issue as: 5.9/CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
External Reference:
http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html#AppendixJAVA
It was discovered that the Hotspot component of OpenJDK did not perform access checks correctly in certain cases when performing field link resolution. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
An infinite loop flaw was found in the RIFF (Resource Interchange File Format) file format reader in the Sound component of OpenJDK. A specially crafted RIFF file could cause a Java application to enter an infinite loop while reading the RIFF file.
It was discovered that the JNDI comment of OpenJDK did not properly enforce the restriction controlled by the com.sun.jndi.ldap.object.trustURLCodebase system property. In certain cases, a Java LDAP client could unexpectedly load and execute code form an LDAP server.
An information leak flaw was found in the Networking component of OpenJDK. The HttpURLConnection class implementation could re-send HTTP headers containing sensitive data (such as Cookie or Authorization headers) to a different host when following HTTP redirects. This could lead to exposure of data to unintended HTTP hosts.
It was discovered that the Security component of OpenJDK could incorrectly use unsigned manifest attribute entries when only properly signed entries were meant to be used. This could lead to bypass of protections provided by Jar signing. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.
Oracle Java SE 6u201, 7u191, 8u181, and 10.0.2 fixes an unspecified vulnerability in the Libraries component (CVE-2018-2940). Upstream has CVSS scored this issue as: 4.3/CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N
External Reference:
http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html#AppendixJAVA
It was discovered that the Scripting component of OpenJDK did not properly restrict access to scripting engine via Global object's engine variable when using Security Manager or class filtering. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
A certificate verification flaw was found in the JSSE component of OpenJDK. No check was preformed during the TLS session resumption to ensure that the same endpoint identification algorithm had been used when originally opening the session as was required when resuming the session. In certain cases, this could lead to having TLS connection established without required server identity verification.
It was discovered that the implementation of the PatternSyntaxException class in the Concurrency component of OpenJDK failed to sufficiently validate the 'index' value (to ensure it's not greater than the regular expression length) in the getMessage() method. An instance of the class with invalid index value, for example one created via deserialization on an untrusted input, could cause a Java application to use an excessive amount of memory.
It was discovered that the implementation of the StubIORImpl class in the Serialization component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.
It was discovered that the Security component of OpenJDK did not correctly perform merging of multiple sections for the same file listed in the JAR archive file manifest. An attacker could possibly use this flaw to alter certain attributes specified in the manifest without changing archive signature.
It was discovered that the implementation of the PriorityBlockingQueue class in the Concurrency component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.
It was discovered that the implementation of the Container class in the AWT component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.
Last updated 25 August 2025
A flaw was found in the way the Hotspot component of OpenJDK handled clones of the java.lang.ref.Reference objects. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the implementation of the NamedNodeMapImpl class in the JAXP component of OpenJDK did not limit the amount of memory allocated when creating object instance from a serialized form. A specially-crafted input could cause a Java application to use an excessive amount of memory when deserialized.