CVE-2013-0422

What is Oracle Java SE?

Oracle Java SE includes the Java Runtime Environment (JRE), which enables browser-based Java applets running inside the JRE Security Manager sandbox. The sandbox enforces access controls through permission checks — code running without explicit grants cannot perform privileged operations. CVE-2013-0422 exploits a chain of permission-bypass flaws that together eliminate the Security Manager's protection, allowing untrusted applet code to run as trusted. This was the second critical Java zero-day in five months, following CVE-2012-4681 in August 2012.

Overview

CVE-2013-0422 is a permission bypass vulnerability (CWE-264) in Oracle Java SE 7 that allows an untrusted applet to escape the Security Manager sandbox and execute arbitrary code on the host. The exploit chains two separate issues: a flaw in how the MBeanInstantiator class handles findClass operations, combined with a permissions check bypass in the JMX (Java Management Extensions) infrastructure. Together these allow the applet to obtain a trusted class loader reference and invoke privileged operations.

Oracle released an emergency out-of-band patch (Java 7 Update 11) on January 13, 2013 — three days after the zero-day was published.

Affected Versions

Technical Details

The exploit chain targets Java 7's JMX (Java Management Extensions) infrastructure:

Step 1: The com.sun.jmx.mbeanserver.MBeanInstantiator class contains a findClass method that can be invoked by untrusted code to locate classes by name. This should require a permission check, but the check was bypassable.

Step 2: Using the class reference obtained, the exploit accesses JMXMBeanServerDelegate or related JMX classes that provide privileged access. The combination allows the applet to reflectively invoke methods normally restricted to trusted code, ultimately disabling the Security Manager and running arbitrary Java (including Runtime.exec()).

Why this was the second DHS advisory: This zero-day appeared within months of CVE-2012-4681, demonstrating that fixing one sandbox escape did not address the systemic weakness in Java's permission model. The US Department of Homeland Security published a second advisory urging users to disable Java in browsers — an extraordinary step signaling the security community had lost confidence in the Java browser plugin's security model.

Discovery

The vulnerability was discovered by researchers and confirmed to be actively exploited in the wild on January 10, 2013. Oracle's rapid three-day patch turnaround (compared to their normal quarterly CPU cycle) reflected the severity and breadth of active exploitation.

Exploitation Context

CVE-2013-0422 was weaponized within hours of public disclosure, integrated into Blackhole Exploit Kit, Cool Exploit Kit, and Redkit within the same day. Criminal operators targeting unpatched Java 7 installations used this for mass drive-by malware distribution. The scale prompted the US-CERT advisory — the second in five months — recommending complete Java browser plugin disablement.

Remediation

1. Apply Java 7 Update 11 — Oracle's emergency January 2013 patch
2. Disable the Java browser plugin permanently — this was Oracle's own recommendation following this incident; the plugin's security history made it untenable for general browser use
3. Java 7 reached end-of-life in April 2015 — migrate to Java 17 LTS or 21 LTS for current deployments
4. In enterprise environments, use software inventory tools to audit Java versions and enforce minimum version requirements