CVE-2013-0422: Oracle JRE Remote Code Execution Vulnerability
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.
CVE-2013-0422 is a remote code execution vulnerability in Oracle Java Runtime Environment (JRE). It stems from a flaw in how Java restricts the permissions of Java applets, which can let an attacker execute commands on a vulnerable system. This matters because JRE is widely deployed on desktops and servers that run Java-based applications or browser applets; successful abuse can give an attacker control of the host. Public reporting also links this vulnerability to known ransomware use, raising the stakes for unpatched systems.
How it works
The weakness is classified as CWE-264, which covers improper handling of permissions, privileges, and access controls. In this case, the CISA summary describes a problem in the way Java restricts the permissions of Java applets. An attacker who can deliver a malicious applet—typically through a web page or other content that invokes the JRE—may bypass those restrictions and run arbitrary commands with the privileges of the Java process.
Exact exploit mechanics, payload formats, and affected applet configurations are not detailed in the provided facts. Defenders should treat this as a classic applet sandbox escape in the JRE class of products and confirm technical specifics against the vendor advisory rather than relying on incomplete public summaries.
Am I affected? How to find it in your systems
Oracle JRE commonly appears on end-user workstations, developer machines, and servers that host or launch Java applications. Inventory every system that has a JRE installed, including those that still support browser plugins or legacy Java Web Start usage.
- Enumerate installed JRE versions with your software inventory tools, package managers, or by checking the Java control panel and installation directories on Windows, macOS, and Linux hosts.
- Identify configurations that still allow applets or unsigned/untrusted content; these are the primary attack surface described for this issue.
- Confirm exact affected versions and any version-specific notes against the Oracle vendor advisory; do not assume a build is safe without that check.
- Review web proxy, endpoint, and browser logs for unexpected Java applet launches, especially from untrusted sites, and watch for subsequent unusual process creation or command execution under the Java user context. Telemetry that shows Java spawning shells or unexpected binaries can indicate exploitation attempts.
How to remediate
Patch first. Apply the updates issued by Oracle for the JRE exactly as directed in the vendor advisory. CISA’s required action is to apply updates per vendor instructions; treat that as the primary fix.
- After patching, verify the new JRE version is active and that older runtimes have been removed or disabled so applications cannot fall back to a vulnerable build.
- For this permission-restriction class of flaw, harden remaining Java deployments: disable browser applet support where it is no longer required, enforce the principle of least privilege for the accounts that run Java processes, and restrict which sites or code sources are allowed to load applets.
- Re-scan inventory after remediation to confirm no lingering vulnerable JRE instances remain.
If you can't patch immediately
If immediate patching is not possible, reduce exposure with compensating controls until the vendor update can be applied.
- Segment systems that still require JRE so they cannot reach untrusted networks or be reached from high-risk zones.
- Use application control or endpoint policies to block Java from launching applets or from executing unexpected child processes.
- Where a web application firewall or virtual patching capability exists, apply rules that detect or block known malicious applet delivery patterns; validate any such rules against current threat intelligence and the vendor advisory.
- Disable the affected feature—Java applet support in browsers and the JRE plugin—on hosts that do not need it.
- Increase monitoring for Java-spawned commands, anomalous network connections from java.exe or equivalent processes, and ransomware-like behavior (mass file encryption, shadow copy deletion), given the known ransomware association.
If your data may have been exposed
Actively exploited vulnerabilities, especially those tied to ransomware, frequently lead to broader compromise and data theft. If you suspect exploitation, isolate affected hosts, preserve forensic evidence, and follow your incident response process. As an additional check, you can run a free exposure scan of your email addresses against known breach data to see whether credentials or personal information have already appeared in public breach sets.
AICompiled with AI assistance from public sources and published under our editorial standards.
Details
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HReferences
- blog.fireeye.com/research/2013/01/happy-new-year-from-new-java-zero-day.html
- blog.fuseyism.com/index.php/2013/01/15/security-icedtea-2-1-4-2-2-4-2-3-4-releas
- immunityproducts.blogspot.ca/2013/01/confirmed-java-only-fixed-one-of-two.html
- krebsonsecurity.com/2013/01/zero-day-java-exploit-debuts-in-crimeware/
- labs.alienvault.com/labs/index.php/2013/new-year-new-java-zeroday/
- lists.opensuse.org/opensuse-security-announce/2013-01/msg00025.html
- malware.dontneedcoffee.com/2013/01/0-day-17u10-spotted-in-while-disable.html
- rhn.redhat.com/errata/RHSA-2013-0156.html