CVE-2012-5076

What is Oracle Java SE?

Oracle Java SE includes the Java Runtime Environment (JRE), which enables browser-based Java applets — programs that run inside the JRE security sandbox. The sandbox restricts which Java packages and APIs untrusted applets can access, using a security properties configuration that defines package access restrictions. When this configuration is incomplete or incorrect, untrusted applets can access internal Java or bundled third-party packages that provide privileged access to JVM internals — enabling a sandbox escape without any memory corruption.

Overview

CVE-2012-5076 is a sandbox bypass vulnerability in Oracle Java SE arising from an incomplete package access restriction in Java's default security configuration. The com.sun.org.glassfish.external and com.sun.org.glassfish.gmbal packages — bundled GlassFish application server monitoring libraries included with the JDK — were not restricted from access by untrusted applets. These packages provide APIs that can be used to access JVM internals and bypass the Security Manager, enabling a complete sandbox escape.

Oracle patched this in the October 2012 Critical Patch Update (Java 7 Update 9, Java 6 Update 37).

Affected Versions

Technical Details

Java's security architecture restricts untrusted applet code from accessing certain package namespaces via the package.access property in the Java security properties file (java.security). Packages listed in this property cannot be loaded by untrusted code.

The vulnerability exists because the GlassFish-related packages (com.sun.org.glassfish.external.* and com.sun.org.glassfish.gmbal.*) were bundled into the JRE but not included in the package.access restriction list. These packages provide management and monitoring APIs that, when accessed by untrusted code, can be used to:

1. Access Java Management Extensions (JMX) infrastructure
2. Obtain references to internal JVM objects through the monitoring API
3. Invoke privileged operations that bypass the Security Manager
4. Achieve arbitrary code execution outside the sandbox

Why this class of vulnerability is significant: Unlike memory corruption exploits, sandbox bypass via missing package restrictions requires no exploit code — the attack is a pure logic flaw in Java's configuration, making it reliable across all JRE versions and platforms simultaneously. The exploitation complexity is low once the bypass mechanism is understood.

Discovery

The missing package access restriction was identified through security research into Java's sandbox architecture. The October 2012 CPU addressed this alongside other Java sandbox issues discovered in the same research period — a period of intensive scrutiny of Java's security model following the CVE-2012-4681 zero-day crisis in August 2012.

Exploitation Context

CISA confirmed exploitation in the wild. The October 2012 timeframe coincided with peak crimeware exploitation of Java vulnerabilities. Exploit kits — Blackhole, Nuclear, Redkit, and others — maintained portfolios of Java sandbox escapes and rapidly integrated newly disclosed vulnerabilities. CVE-2012-5076 would have been integrated into exploit kit rotation immediately after the October 2012 CPU, with criminal operators targeting users who had patched to Java 7u7 (fixing CVE-2012-4681) but not yet to 7u9.

Remediation

1. Apply Oracle CPU October 2012 — update to Java 7u9 / Java 6u37 / Java 5u38
2. Disable the Java browser plugin — this eliminates the entire applet sandbox attack surface; the browser plugin has been the source of the vast majority of Java CVEs
3. Java SE 5.0 and 6 are end-of-life (2009 and 2013 respectively); Java SE 7 EOL'd in 2015 — migrate all deployments to Java 17 LTS or Java 21 LTS
4. In enterprise environments, enforce minimum Java version requirements via Group Policy or endpoint management and audit for outdated JRE installations using software inventory tools