It was discovered that the DGCClient (for RMI distributed garbage-collection - DGC) class in the RMI component of OpenJDK failed to use restricted access control context when handling JRMP (Java Remote Method Protocol) messages. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the IIOPInputStream class in the CORBA component of OpenJDK failed to properly check object and field types during object deserialization. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that ICU Layout Engine was missing multiple boundary and error return checks. These could lead to buffer overflows and memory corruption. A specially crafted font file could cause an application using ICU to parse untrusted fonts to crash and, possibly, execute arbitrary code.
ICU code is embedded the 2D component in OpenJDK and used by FontManager. An untrusted Java application or applet could use this flaw to execute arbitrary code with Java Virtual Machine privileges and bypass Java sandbox restrictions.
It was discovered that the DGCImpl (for RMI distributed garbage-collection - DGC) class in the RMI component of OpenJDK failed to use restricted access control context when processing untrusted input. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
Multiple integer overflow issues were found in the implementation of Buffers in the java.nio (Non-blocking I/O) packages in the Libraries component of OpenJDK. These could lead to out of bounds buffer access and Java Virtual Machine memory corruption. An untursted Java application or applet could use these flaws to run arbitrary code with the Java Virtual Machine privileges or bypass Java sandbox restrictions.
It was discovered that the StubGenerator class in the CORBA component of OpenJDK failed to generate code with all needed permission checks related to object (de-)serialization. An untursted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the ObjectStreamClass in the Serialization component of OpenJDK failed to ensure that the object is fully initialized before allowing calls of certain methods. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that ICU Layout Engine was missing multiple boundary checks. These could lead to buffer overflows and JVM memory corruption. A specially crafted file could cause an application using ICU to parse untrusted font files to crash and, possibly, execute arbitrary code.
ICU code is embedded the 2D component in OpenJDK and used by FontManager. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the Libraries component of OpenJDK failed to check current context / thread while performing object deserialization, possibly leading to incorrect input deserialization. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the JMX component in OpenJDK failed to properly handle MBean connection proxy classes. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the IIOPInputStream class in the CORBA component in OpenJDK failed to properly check object field types. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
Oracle Java SE 6u101, 7u85 and 8u51 fixes an unspecified vulnerability in the 2D component (CVE-2015-2638). Upstream has CVSSv2 scored this issue as: 10.0/AV:N/AC:L/Au:N/C:C/I:C/A:C
External Reference:
http://www.oracle.com/technetwork/topics/security/cpujul2015-2367936.html#AppendixJAVA
An off-by-one error, leading to heap-based buffer overflow in the ICU Layout Engine ligature substitution processor. A check which was added as part of fix for CVE-2013-1569 (bug 952711) / CVE-2013-2383 (bug 952708) / CVE-2013-2384 (bug 952709) was found to contain an incorrect array boundary check. A specially crafted file could cause an application using ICU to parse untrusted font files to crash or, possibly, execute arbitrary code.
The original fix was added to OpenJDK and ICU via the following commits:
http://hg.openjdk.java.net/jdk7u/jdk7u-dev/jdk/rev/6784c9903db7
http://bugs.icu-project.org/trac/changeset/33535 http://bugs.icu-project.org/trac/ticket/10107
ICU code is embedded the 2D component in OpenJDK and used by FontManager. An untrusted Java application or applet could use this flaw to bypass certain Java sandbox restrictions.
An old inffast.c optimization turns out to not be optimal anymore with modern compilers, and furthermore was not compliant with the C standard, for which decrementing a pointer before its allocated memory is undefined.
External References:
https://wiki.mozilla.org/images/0/09/Zlib-report.pdf https://docs.google.com/document/d/10i1KZS5so8xDqH2rplRa2xet0tyTvvJlLbQQmZIUIKE/edit#heading=h.t13tvnx4loq7
Upstream patch:
https://github.com/madler/zlib/commit/9aaec95e82117c1cb0f9624264c3618fc380cecb
CVE assignment:
http://seclists.org/oss-sec/2016/q4/602
Multiple vulnerabilities in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 6 and earlier allow remote attackers to execute arbitrary code via a crafted applet that bypasses SecurityManager restrictions by (1) using com.sun.beans.finder.ClassFinder.findClass and leveraging an exception with the forName method to access restricted classes from arbitrary packages such as sun.awt.SunToolkit, then (2) using "reflection with a trusted immediate caller" to leverage the getField method to access and modify private fields, as exploited in the wild in August 2012 using Gondzz.class and Gondvv.class.
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 update 32 and earlier, 5 update 35 and earlier, and 1.4.237 and earlier allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to Hotspot.
Last updated 14 January 2026
A Spring MVC or Spring WebFlux application running on JDK 9+ may be vulnerable to remote code execution (RCE) via data binding. The specific exploit requires the application to run on Tomcat as a WAR deployment. If the application is deployed as a Spring Boot executable jar, i.e. the default, it is not vulnerable to the exploit. However, the nature of the vulnerability is more general, and there may be other ways to exploit it.
Airport. A permissions issue was addressed with improved redaction of sensitive information.
An insecure class construction flaw, related to the incorrect handling of exception stack frames, was found in the Hotspot component of OpenJDK. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the atomic field updaters in the in the java.util.concurrent.atomic package in the Libraries component of OpenJDK did not properly restrict access to protected field members. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the RMI registry and DCG (Distributed Garbage Collector) implementations in the RMI component of OpenJDK performed deserialization of untrusted inputs. A remote attacker could possibly use this flaw to execute arbitrary code with the privileges of RMI registry or a Java RMI application.
It was discovered that the RMI (Java Remote Method Invocation) server implementation in the JMX (Java Management Extensions) component of OpenJDK did not restrict which classes can be deserialized when deserializing authentication credentials. A remote unauthenticated attacker able to connect to a JMX port could possibly use this flaw trigger deserialization flaws.
An unspecified flaw was found in the Libraries component in OpenJDK. ObjectInputStream's readSerialData() could, in certain cases, incorrectly perform deserialization of data from serialized input. An untrusted Java application or applet could use this flaw to bypass Java sandbox restrictions.
It was discovered that the JPEG decoder did not properly handle certain input streams. An untrusted Java application or applet could possibly use this flaw to trigger a Java Virtual Machine memory corruption.
Unspecified vulnerability in Oracle Java SE 8 allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to JavaFX.
It was discovered that the class file parser did not properly parse class files with an invalid BootstrapMethods attribute length. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.
It was discovered that the ScriptEngineManager did not properly manage ScriptEngines. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.
It was discovered that the System.arraycopy() method has a race condition between verifying source elements and storing them. An untrusted Java application or applet could possibly use this flaw to trigger a Java Virtual Machine memory corruption.
It was discovered that the ServiceLoader did not perform exception handling in a secure manner. An untrusted Java application or applet could possibly use this flaw to bypass security mechanisms and perform operations with full permissions.