HowToFixMe
● Critical · CVSS 9.8 ⚠ ACTIVELY EXPLOITED — CISA KEV

How to Fix CVE-2013-0422: Oracle Java 7 RCE Before Update 11

By the Sai Kiran Pandrala · Reviewed and edited by Sai Kiran Pandrala, Editor

⚡ At a glance
SeverityCVSS 9.8 Critical (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
Actively exploited?Yes. Zero-day in Jan 2013 (Blackhole, Nuclear Pack); CISA KEV added 2022-05-25
ProductOracle Java 7 (JRE and JDK), all platforms
Affected versionsJava 7 before Update 11 (Java 6 retracted as not exploitable)
Fixed inOracle Java 7 Update 11 (Oracle Security Alert CVE-2013-0422)
Type (CWE)CWE-284 Improper Access Control (chained to sandbox-escape RCE)

Exploitation status

CVE-2013-0422 is actively exploited in the wild. It surfaced as an unpatched zero-day in January 2013, and within days it was bundled into the Blackhole and Nuclear Pack exploit kits, two of the most widely deployed drive-by crimeware kits of that era. CISA later added it to the Known Exploited Vulnerabilities (KEV) catalog on , which makes patching mandatory for U.S. federal agencies under Binding Operational Directive 22-01. The federal remediation deadline was . If you still run an affected build, treat this as an emergency change, not a scheduled one.

Public exploit availability: weaponized code is widely available. Beyond the two exploit kits, Immunity published a detailed technical analysis of the MBeanInstantiator.findClass vector, and working modules circulated publicly almost immediately after disclosure. There is no ambiguity here: assume any unpatched Java 7 endpoint reachable by a malicious web page is exploitable. The CISA KEV record for this CVE does not flag it for known ransomware-campaign use, so this guide does not claim ransomware involvement; the documented use was exploit-kit-driven mass malware delivery.

Authoritative references:

Patch immediately. Upgrade to Oracle Java 7 Update 11 (or remove Java 7 entirely). CISA lists this CVE in its Known Exploited Vulnerabilities catalog; the KEV entry was added 2022-05-25 with a federal due date of 2022-06-15.

What is CVE-2013-0422?

CVE-2013-0422 is a critical, unauthenticated remote code execution vulnerability in Oracle Java 7, affecting every build before Java 7 Update 11. It is not an operating-system package bug and it is not specific to any Linux distribution. The vulnerable code is in the Java runtime itself, and the practical attack surface is the browser Java plug-in: a victim simply visits a web page hosting a malicious applet, and attacker code runs outside the Java sandbox with the privileges of the user.

The CVE actually bundles two distinct flaws that chain together into a full sandbox escape. The first abuses the public getMBeanInstantiator method in the JmxMBeanServer class to grab a reference to a private MBeanInstantiator object, then calls findClass on it to obtain references to arbitrary, normally restricted classes. The second uses the Reflection API with recursion to defeat a security check in java.lang.invoke.MethodHandles.Lookup.checkSecurityManager, because sun.reflect.Reflection.getCallerClass could not skip the stack frames introduced by the new reflection API. Either weakness is dangerous on its own; combined, they let untrusted applet code disable the Security Manager and run anything it wants. That is why the record is classified under CWE-284 (Improper Access Control) even though the end result is code execution.

For the record, this is a different vulnerability from CVE-2012-4681 and CVE-2012-3174. Some parties mapped the recursive Reflection API piece to CVE-2012-3174, but the source record is explicit that CVE-2012-3174 covers a separate, non-public issue, and CVE-2013-0422 covers both the JMX/MBean and Reflection API vectors. Java 6 was initially reported as vulnerable, but the original reporter retracted that, stating Java 6 is not exploitable because the relevant code is reached in a way that does not bypass the security checks. Plan your remediation around Java 7 only.

Why this CVE matters

At the start of 2013 this was the marquee browser-exploit bug. It was already being used in the wild before a patch existed, it required zero authentication and zero user interaction beyond loading a page, and it was wired into the Blackhole and Nuclear Pack exploit kits, which meant ordinary criminals could rent it without writing a line of exploit code. The CVSS 3.1 base score is 9.8 (vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H): network-reachable, low complexity, no privileges, no interaction, with total loss of confidentiality, integrity, and availability.

The honest, uncomfortable detail you should not skip: at disclosure, a reliable third party reported that the findClass/MBeanInstantiator vector was not fully fixed in Java 7 Update 11. Install Update 11 because it closes the actively exploited path, but do not treat it as the end of the story. Keep applying every subsequent Java Critical Patch Update, and where you can, get Java 7 off the machine altogether.

Check whether you are affected

This is a Java runtime version problem, so the only check that matters is the actual Java version, not an OS package name. Run the right command for where Java is installed.

# Linux / macOS: ask Java itself. Anything reporting 1.7.0_10 or lower is vulnerable.
java -version
# If multiple JDKs/JREs exist, check each one explicitly:
/usr/lib/jvm/*/bin/java -version

# Windows: find every installed Oracle Java and read its version.
Get-ChildItem 'C:\Program Files\Java','C:\Program Files (x86)\Java' -ErrorAction SilentlyContinue |
  ForEach-Object { & "$($_.FullName)\bin\java.exe" -version 2>&1 }
# Also check the registry for installed JRE/JDK builds:
Get-ChildItem 'HKLM:\SOFTWARE\JavaSoft' -Recurse -ErrorAction SilentlyContinue | Select-Object Name

A version string of 1.7.0_11 or higher means you are on Update 11 or later. Anything from 1.7.0_10 downward is in the affected range and needs the fix below.

How to fix CVE-2013-0422

There is no apt or dnf one-liner that fixes Oracle Java, because Oracle Java is not a distribution package. The fix path depends on where your Java came from.

Oracle Java 7 (downloaded from Oracle)

Upgrade to Java 7 Update 11 or later, per Oracle Security Alert CVE-2013-0422. Download the current Java 7 (or, far better, a current supported Java release) from Oracle, run the installer, and let it remove the old build. On Windows, do this through the Java installer or your software-deployment tool (SCCM/Intune package, Group Policy MSI), not Windows Update, because Oracle Java is not serviced by Microsoft. After installing, open the Java Control Panel and confirm the old version is gone; stale JRE folders are a common reason a scanner keeps flagging the host.

Distribution OpenJDK / IcedTea

If your Java actually came from a Linux distribution (OpenJDK 7 / IcedTea), install that vendor's security update. Use the package name your distribution actually ships, for example java-1.7.0-openjdk on Red Hat-family systems or openjdk-7-jre on Debian/Ubuntu, not a hardcoded modern package name.

# Red Hat / CentOS (RHSA-2013:0156, RHSA-2013:0165)
sudo yum update java-1.7.0-openjdk
java -version

# Debian / Ubuntu (USN-1693-1)
sudo apt-get update
sudo apt-get install --only-upgrade openjdk-7-jre openjdk-7-jdk
java -version

# openSUSE (openSUSE-SU-2013:0199): IcedTea 2.1.4 / 2.2.4 / 2.3.4
sudo zypper refresh
sudo zypper update java-1_7_0-openjdk

After any upgrade, restart every long-running process that has the old Java loaded (application servers, agents, browsers) so the patched runtime is the one actually executing.

If you can't patch immediately

Patching or removing Java 7 is the only durable fix. Until then, the single most effective stopgap is to cut off the browser attack path, because that is how this CVE is exploited.

These reduce exposure; they do not remove the vulnerability from an unpatched runtime.

Verify the fix

Confirm the version, then confirm a scanner agrees.

# Must report 1.7.0_11 or higher (or a later major Java release).
java -version

Run an authenticated vulnerability scan with a current signature set and confirm it no longer flags CVE-2013-0422 on the host. Because this was exploited as a zero-day before the patch shipped, any system that browsed the web while running an affected Java 7 build during the exposure window should be reviewed for compromise: check for unexpected processes spawned by the Java plug-in, new local accounts, and unusual outbound connections, and rotate credentials that were stored or typed on that machine.

Frequently asked questions

What product and versions does CVE-2013-0422 affect?

Oracle Java 7 (the JRE and JDK) on every platform, in every build before Java 7 Update 11. Java 6 was initially reported as affected, but the reporter retracted that claim because the relevant code path in Java 6 does not bypass the security checks. The flaw lives in the Java plug-in and runtime, not in any operating-system package.

What is the fix for CVE-2013-0422?

Upgrade to Oracle Java 7 Update 11 or later from Oracle's download site, per Oracle Security Alert CVE-2013-0422. If you run a Linux distribution's OpenJDK or IcedTea build, install the vendor update instead: Red Hat RHSA-2013:0156 and RHSA-2013:0165, Ubuntu USN-1693-1, openSUSE-SU-2013:0199, Mandriva MDVSA-2013:095, or IcedTea 2.1.4 / 2.2.4 / 2.3.4. The right long-term move is to remove Java 7 entirely and move to a current supported release.

Is CVE-2013-0422 a remote code execution bug or just an access-control issue?

It is unauthenticated remote code execution. It is classified under CWE-284 (Improper Access Control) because two access-control failures chain together: the public getMBeanInstantiator method exposes a private MBeanInstantiator so attacker code can call findClass to load arbitrary classes, and a Reflection API recursion bypasses the MethodHandles.Lookup security-manager check. Together they let a malicious applet escape the sandbox and run native code.

Does Java 7 Update 11 fully fix CVE-2013-0422?

Update 11 is the fix Oracle shipped and you should install it, but at disclosure a reliable third party reported that the findClass/MBeanInstantiator vector was not fully closed in Update 11. Treat Update 11 as the minimum, keep patching every quarterly Java release after it, and disable the browser Java plug-in if you do not need applets.

Is CVE-2013-0422 being exploited in the wild?

Yes. It was exploited as a zero-day in January 2013 and folded into the Blackhole and Nuclear Pack exploit kits within days. CISA later added it to the Known Exploited Vulnerabilities catalog on 2022-05-25 with a federal remediation due date of 2022-06-15.

References

This guide was assembled from the official vendor advisory, the NVD record, and the CISA KEV catalog entry on 2026-05-25. Always confirm against the vendor advisory before applying changes in production.

Other flaws in this area worth reviewing while you patch this one:

People also ask

What product and versions does CVE-2013-0422 affect?

Oracle Java 7 (the JRE and JDK) on every platform, in every build before Java 7 Update 11. Java 6 was initially reported as affected but the reporter retracted that claim, since the relevant code path in Java 6 does not bypass the security checks.

What is the fix for CVE-2013-0422?

Upgrade to Oracle Java 7 Update 11 or later from Oracle. For distribution OpenJDK/IcedTea builds, apply the vendor update instead (Red Hat RHSA-2013:0156/0165, Ubuntu USN-1693-1, openSUSE-SU-2013:0199, or IcedTea 2.1.4 / 2.2.4 / 2.3.4). Better still, remove Java 7 and move to a current supported release.

Does Java 7 Update 11 fully fix CVE-2013-0422?

Install Update 11 because it closes the actively exploited path, but a reliable third party reported at disclosure that the findClass/MBeanInstantiator vector was not fully fixed in Update 11. Keep patching every later Java release and disable the browser Java plug-in where you do not need applets.