It was discovered that the TLS implementation in the Security component of OpenJDK was vulnerable to an RSA padding issue and timing side-channel attack. This could possibly lead to disclosure of some information meant to be protected by encryption.

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 covert timing channel flaw was found in the ECDSA implementation in the Libraries component of OpenJDK. A remote attacker able to make a Java application generate ECDSA signatures on demand could possibly use this flaw to extract certain information about the key use via a timing side channel.

A covert timing channel flaw was found in the DSA implementation in the Libraries component of OpenJDK. A remote attacker able to make a Java application generate DSA signatures on demand could possibly use this flaw to extract certain information about the used key via a timing side channel.

A flaw was found in the way the imaging library in the 2D component of OpenJDK performed affine transformations of images. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

It was discovered that the boundary checks in the java.nio.Buffer class in the Libraries component of OpenJDK could have been bypassed when class instance was accessed concurrently. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

It was discovered that the Nashorn JavaScript engine in the Scripting component of OpenJDK could allow JavaScripts to access Java APIs even when access to Java APIs was disabled. An untrusted JavaScript executed by Nashorn could use this flaw to bypass intended restrictions.

It was discovered that the JAR (Java ARchive) verifier in the Security component of OpenJDK did not correctly handle files inside archives with missing digest. An attacker could possibly use this flaw to manipulate content of a singed JAR, bypassing intended verification.

It was discovered that the JMX component of OpenJDK failed to properly set the deserialization filter for the SingleEntryRegistry in certain cases. A remote attacker could possibly use this flaw to bypass intended deserialization restrictions.

It was discovered that the Hotspot component of OpenJDK failed to properly validate uses of the invokeinterface Java Virtual Machine instruction. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

The JGSS component of OpenJDK ignores the value of javax.security.auth.useSubjectCredsOnly when using HTTP/SPNEGO authentication and always uses global credentials, see:

https://bugs.openjdk.java.net/browse/JDK-6560359

This could cause global credentials to be unexpectedly used by an untrusted Java application. The fix adds new system property http.use.global.creds which, when set to false, prevents the use of global credentials.

A flaw was found in the loop optimizations performed by the Hotspot component of OpenJDK when generating range check predicates. An untrusted Java application or applet could use this flaw to corrupt JVM memory and cause it to crash or, possibly, execute arbitrary code, bypassing Java sandbox restrictions.

It was discovered that the C1 compiler in the Hotspot component of OpenJDK did not correctly apply an unsigned integer left shift to calculate the actual address offset under certain conditions. This could lead to an integer overflow and out-of-bounds array access, potentially corrupting the JVM memory.

A flaw was found in the C2 compiler in the Hotspot component of OpenJDK. C2 compilation fails with "Exceeded noderegs array" due to an improper size validation and out-of-bounds array access, potentially resulting in a corruption of the JVM memory.

Upstream OpenJDK issue: https://bugs.openjdk.org/browse/JDK-8317507

It was discovered that the Hotspot component of OpenJDK did not properly restrict access to the invokeBasic() method of the MethodHandle class. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.

OpenJDK can apply two different security meanings to the same wildcard dNSName SAN across certificate policy enforcement and hostname verification. During path validation, DNSName.constrains compares .foo.com and secret.foo.com literally and returns NAMESAMETYPE, so NameConstraintsExtension.verify does not reject the chain when secret.foo.com is an exact-host exclusion. Later, HostnameChecker interprets the same SAN as a wildcard template and accepts secret.foo.com for .foo.com.

It was discovered that the password-based encryption (PBE) implementation in the Libraries component of OpenJDK specified incorrect key length. This could lead to generation of keys that were weaker than expected in certain cases.

It was discovered that the RMIConnector and RMIConnectionImpl classes in the JMX component of OpenJDK could log sensitive information such as user passwords in its debug log, possibly leading the exposure of the information.

It was discovered that the AlgorithmChecker class in the Security component of OpenJDK failed to properly check if a certificate satisfies all defined constraints in certain cases. This could cause a Java application to accept an X.509 certificate which does not meet requirements of the policy defined in the java.security file.

It was discovered that the JAXP component of OpenJDK did not enforce the maximum XML name limit (jdk.xml.MaxXMLNameLimit) when parsing XML files. A specially crafted XML document could cause a Java application using JAXP to consume an excessive amount of memory and CPU time when parsed.

It was discovered that the 2D component of OpenJDK could perform out of bounds access and possibly disclose portions of the Java Virtual Machine memory when processing specially crafted color profiles. The issue was caused by having bundled lcms2 code use fast floor() implementation. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

An information disclosure flaw was found in the JAXP component of OpenJDK. An untrusted Java application or applet could use this flaw to get information about user home directory location (the content of the "user.dir" system property), hence bypassing certain Java sandbox restrictions.

It was discovered that the RemoteObjectInvocationHandler class in the RMI component of OpenJDK did not check if object proxy is an instance of a proxy class and that it uses correct invocation handler. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions by gaining access to data that should by protected by the sandbox.

It was discovered that the CORBA component of OpenJDK did not sufficiently restrict the use of custom ValueHandler when performing object deserialization. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

It was discovered that the JAXP component of OpenJDK did not place a limit on the number of entity replacements performed when parsing XML files. A specially crafted XML document could cause a Java application using JAXP to consume an excessive amount of memory and CPU time when parsed.

Updates correcting this issue address the problem by introducing a limit on the number of entity replacements that can be performed. The limit can be controlled using the jdk.xml.entityReplacementLimit system property.

Integer overflow flaws were found in the way the Hotspot component of OpenJDK read bytecode from class files. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

It was discovered that the JAXP (Java API for XML Processing) component of OpenJDK failed to properly handle Unicode surrogate pairs used as part of the XML attribute values. A specially-crafted XML input could cause a Java application to use an excessive amount of memory when parsed.

It was discovered that the ClassLoaderWithRepository class in the JMX component of OpenJDK did not sufficiently perform classloader consistency checks, allowing classloader to return class with different name than requested. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.

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 Utility component of OpenJDK. The Multi-Release attribute could have been read from outside of the main attributes in a Jar manifest, possibly leading to a use of an unsigned value for this attribute. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.