CVE-2012-0507

CVE-2012-0507 is a critical-severity vulnerability in Oracle Jre with a CVSS 3.x base score of 9.8. It is listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, confirming it has been exploited in the wild (added 2022-03-03). The underlying weakness is classified as CWE-843.

Key facts

Description

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.

CVE-2012-0507: Java AtomicReferenceArray Type Confusion Enables Sandbox Bypass and RCE

AI-generated analysis based on the vulnerability data on this page.

Attribute Value
CVE CVE-2012-0507
CVSS v2 10.0 Critical — AV:N/AC:L/Au:N/C:C/I:C/A:C
CVSS v3 9.8 Critical — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE CWE-843 (Access of Resource Using Incompatible Type / Type Confusion)
EPSS 0.98113 (99.9th percentile)
Known Exploited (KEV) Yes — added 2022-03-03
Published 2012-06-07
Source Oracle February 2012 CPU

Summary

CVE-2012-0507 is a type-confusion vulnerability in the Java Runtime Environment (JRE). The AtomicReferenceArray class fails to verify that the underlying array is of the Object[] type, allowing an attacker to manipulate internal memory references. This can be exploited to escape the Java sandbox and achieve remote code execution.

Background

The AtomicReferenceArray class, introduced in Java 5 as part of the java.util.concurrent package, provides thread-safe operations on arrays of objects. It relies on the sun.misc.Unsafe API for low-level memory access. In early 2012, security researchers and a downstream vendor reported that this class did not perform adequate type checking on the array it wrapped, exposing a fundamental flaw in the Java security model.

Root Cause

CWE-843: Access of Resource Using Incompatible Type

The AtomicReferenceArray implementation used sun.misc.Unsafe to read and write array elements without ensuring the array was actually an Object[]. Because Unsafe operates on raw memory offsets, a specially crafted array of a different type could be supplied, causing the JVM to dereference incompatible types. This type confusion corrupts the JVM's internal state, leading to sandbox escape.

Impact

This vulnerability scores the maximum possible CVSS v2 score of 10.0 and a near-maximum CVSS v3 score of 9.8.

  • Confidentiality: Complete — an attacker can read arbitrary memory or filesystem data.
  • Integrity: Complete — arbitrary code can be executed, allowing system modification.
  • Availability: Complete — the JVM can be crashed or the host system compromised.

The attack requires no authentication, low complexity, and is exploitable over the network. The EPSS score of 0.98113 indicates an extremely high probability of active exploitation in the wild.

Exploitation Walkthrough (Defensive Perspective)

Ethics caveat: This section is written for defenders and auditors. No weaponized exploit code is provided.

An attacker crafts a malicious Java applet or JNLP application. The payload:

  1. Allocates a non-Object[] array (for example, an array of primitive types or mismatched objects).
  2. Wraps it inside an AtomicReferenceArray via reflection or deserialization.
  3. Triggers read/write operations through AtomicReferenceArray methods.
  4. Because Unsafe performs unchecked memory access, the attacker gains a corrupted reference that can be used to overwrite JVM security manager fields or invoke arbitrary native methods.

From a defensive standpoint, this is a deserialization and reflection abuse pattern. Hardening against it requires restricting untrusted Java execution entirely, not merely patching the single class.

Affected and Patched Versions

Affected (per Oracle advisory and NVD CPE data):

  • Oracle Java SE 7 Update 2 and earlier
  • Oracle Java SE 6 Update 30 and earlier
  • Sun/Oracle Java SE 5.0 Update 33 and earlier
  • Debian 6.0 and 7.0
  • SUSE Linux Enterprise Server/Desktop/Java/SDK 10 SP4 and 11 SP1/SP2

Patched versions: Oracle released fixes in the February 2012 Critical Patch Update. Users should upgrade to versions released after the CPU (i.e., Java 7 Update 3+, Java 6 Update 31+, Java 5.0 Update 34+). Specific patch numbers for downstream distributions (Debian, SUSE, Red Hat) are documented in their respective security advisories.

Remediation

  1. Upgrade immediately: Remove all affected Java versions and install patches released after the February 2012 CPU. Java 5 and 6 are long past end-of-life and must not be used in production.
  2. Disable browser plugins: Uninstall or disable the Java browser plugin. This is the primary attack vector for drive-by exploitation.
  3. Application whitelisting: Use OS-level controls to prevent execution of untrusted Java binaries.
  4. Network segmentation: Block outbound Java applet traffic at the perimeter.
  5. Compensating controls: For systems that cannot be patched, disable the Java security manager only as a last resort; instead, remove the JRE entirely or containerize the application with strict seccomp/apparmor profiles.

Detection

  • Network: Monitor for JAR downloads from unexpected domains, especially paired with browser exploitation frameworks.
  • Endpoint: Alert on execution of java.exe or javaw.exe with AtomicReferenceArray in stack traces (requires Java Flight Recorder or APM instrumentation).
  • Historical context: This CVE was integrated into exploit kits shortly after disclosure. Check historical EDR logs for 2012-era exploit kit activity if retroactive threat hunting is required.
  • File integrity: Verify installed JRE versions against vendor manifests; any JRE 5, 6, or 7 installation predating 2012 is suspect.

Assessment

Despite being disclosed in 2012, CVE-2012-0507 was added to the CISA KEV catalog in March 2022, reflecting its persistent presence in legacy systems and exploit kits. The EPSS percentile of 99.9 confirms that this vulnerability remains one of the most reliably exploited Java flaws on record.

Key lessons:

  1. Unsafe APIs are inherently risky: Classes built on sun.misc.Unsafe require rigorous type invariants; a single missed check can collapse the entire security model.
  2. Legacy Java is a liability: End-of-life Java versions (5, 6, and even 7) should be treated as critical technical debt and eliminated from the environment.

References

Frequently asked questions

What is CVE-2012-0507?
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.
How severe is CVE-2012-0507?
CVE-2012-0507 has a CVSS 3.x base score of 9.8, rated critical severity. It is exploitable over network with low attack complexity, requires no privileges and no user interaction. Impact on confidentiality is high, integrity high, and availability high.
Is CVE-2012-0507 being actively exploited?
Yes. CVE-2012-0507 is on CISA's Known Exploited Vulnerabilities (KEV) catalog, added on 2022-03-03, which means active exploitation has been confirmed. It should be prioritised for remediation.
What products are affected by CVE-2012-0507?
CVE-2012-0507 primarily affects Oracle Jre. In total, 74 product configurations (CPEs) are listed as vulnerable; see the affected-products list for the exact versions.
How do I fix CVE-2012-0507?
Review the linked vendor and NVD advisories for patched versions and mitigations, then upgrade or apply the recommended workaround. Because this CVE is known to be actively exploited, treat remediation as urgent — CISA KEV typically sets a short remediation deadline.
Does CVE-2012-0507 have an EU (EUVD) identifier?
Yes. CVE-2012-0507 is tracked in the ENISA EU Vulnerability Database (EUVD) as EUVD-2012-0539. It is also flagged as exploited in the EUVD (since 2022-03-03).
When was CVE-2012-0507 published?
CVE-2012-0507 was published on 2012-06-07 and last updated on 2026-06-16.

References

Affected products (74)

More vulnerabilities in Oracle Jre

All CVEs affecting Oracle Jre →

Other CWE-843 vulnerabilities

Browse all CWE-843 vulnerabilities →