Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Update 30 and earlier, and 5.0 Update 33 and earlier allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to Concurrency. NOTE: the previous information was obtained from the February 2012 Oracle CPU. Oracle has not commented on claims from a downstream vendor and third party researchers that this issue occurs because the AtomicReferenceArray class implementation does not ensure that the array is of the Object[] type, which allows attackers to cause a denial of service (JVM crash) or bypass Java sandbox restrictions. NOTE: this issue was originally mapped to CVE-2011-3571, but that identifier was already assigned to a different issue.

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.

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

Last updated 14 January 2026

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.

It was discovered that MethodHandle did not properly handle variable argument lists when permuting or dropping arguments. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.

Oracle Java SE 7u55 and 8u5 fixes an unspecified vulnerability in the Libraries component (CVE-2014-0432). Upstream has CVSSv2 scored this issue as: 9.3/AV:N/AC:M/Au:N/C:C/I:C/A:C

External Reference:

http://www.oracle.com/technetwork/topics/security/cpuapr2014-1972952.html#AppendixJAVA

It was discovered that the CORBA component of OpenJDK failed to properly perform security checks IIOP input streams. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.

It was discovered that certain medialib operations do not properly validate that mlib and raster images correspond to each other. A remote attacker could possibly use this flaw to trigger a Java Virtual Machine memory corruption.

Oracle Java SE 5.0u71, 6u71 and 7u51 fixes an unspecified vulnerability in the 2D component (CVE-2014-0417). Upstream has CVSSv2 scored this issue as: 9.3/AV:N/AC:M/Au:N/C:C/I:C/A:C

External Reference:

http://www.oracle.com/technetwork/topics/security/cpujan2014-1972949.html#AppendixJAVA

It was discovered that the Naming / JNDI component of OpenJDK failed to implement required package access checks. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.

Oracle Java SE 6u71 and 7u51 fixes an unspecified vulnerability in the Deployment component (CVE-2014-0415). 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/cpujan2014-1972949.html#AppendixJAVA

Oracle Java SE 6u71 and 7u51 fixes an unspecified vulnerability in the Deployment component (CVE-2014-0410). 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/cpujan2014-1972949.html#AppendixJAVA

Unspecified vulnerability in Oracle Java SE 7u45, when running on OS X, allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to Hotspot.

Unspecified vulnerability in Oracle Java SE 7u45, when installing on OS X, allows remote attackers to affect confidentiality, integrity, and availability via unknown vectors related to Install.

It was discovered that the 2D component did not properly verify certain image channels. An untrusted Java application or applet could possibly use this flaw to bypass Java sandbox restrictions.

Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using the public getMBeanInstantiator method in the JmxMBeanServer class to obtain a reference to a private MBeanInstantiator object, then retrieving arbitrary Class references using the findClass method, and (2) using the Reflection API with recursion in a way that bypasses a security check by the java.lang.invoke.MethodHandles.Lookup.checkSecurityManager method due to the inability of the sun.reflect.Reflection.getCallerClass method to skip frames related to the new reflection API, as exploited in the wild in January 2013, as demonstrated by Blackhole and Nuclear Pack, and a different vulnerability than CVE-2012-4681 and CVE-2012-3174. NOTE: some parties have mapped the recursive Reflection API issue to CVE-2012-3174, but CVE-2012-3174 is for a different vulnerability whose details are not public as of 20130114. CVE-2013-0422 covers both the JMX/MBean and Reflection API issues. NOTE: it was originally reported that Java 6 was also vulnerable, but the reporter has retracted this claim, stating that Java 6 is not exploitable because the relevant code is called in a way that does not bypass security checks. NOTE: as of 20130114, a reliable third party has claimed that the findClass/MBeanInstantiator vector was not fixed in Oracle Java 7 Update 11. If there is still a vulnerable condition, then a separate CVE identifier might be created for the unfixed issue.

Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allows remote attackers to affect confidentiality, integrity, and availability, related to JAX-WS.