← Back to Feed CACHED · 2026-06-24 06:59:06 · CACHE_KEY CVE-2011-3544
CVE-2011-3544 · CWE-284 · Disclosed 2011-10-19

Oracle Java SE Rhino Script Engine Sandbox Escape (CVE-2011-3544)

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

A teenager's exploit kit favorite that refuses to die because nobody removed the JRE from their kiosks

CVE-2011-3544 is the Rhino script engine sandbox escape in Oracle's Java Runtime Environment. The Rhino JavaScript engine bundled in JRE 6 (Update 27 and earlier) and JRE 7 (GA) exposed Java reflection through Object.getClass, letting an applet or Java Web Start app instantiate arbitrary classes and call setSecurityManager(null) — effectively turning off the sandbox. From there it's full code execution under the user account. Affected versions: JDK/JRE 7 (GA) and JDK/JRE 6 Update 27 and earlier, patched in 6u29 / 7u1 (October 2011 CPU).

The vendor 9.8 CRITICAL was *correct in 2011* — drive-by browser exploitation against unauthenticated visitors, weaponized within days by Blackhole, RedKit, and Cool EK. In 2026 the calculus is different: browsers killed the NPAPI Java plugin (Chrome in 2015, Firefox in 2017), Edge never had it, and macOS disabled Java applets by default in 2014. The bug is still real where Java runs, but the attack surface that made it 9.8 — drive-by via browser applet — is structurally gone. It survives as a server-side or kiosk-side concern only.

"Fifteen-year-old Rhino sandbox escape — still KEV-listed, but if you're running JRE 6u27 in 2026 patching is the easy part."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Deliver malicious applet or JNLP

Attacker hosts a crafted Java applet or Java Web Start file. Historically delivered via Blackhole Exploit Kit landing pages or malvertising. In 2026, delivery requires either a legacy browser with NPAPI Java plugin enabled, a Java Web Start client launching from URL, or a thick-client app that loads untrusted Rhino content.
Conditions required:
  • Victim has Oracle JRE ≤ 6u27 or JRE 7 GA installed
  • Java plugin enabled in a browser that still supports NPAPI, OR a JWS/javaws handler registered
Where this breaks in practice:
  • Modern Chrome, Edge, Firefox, Safari have all removed NPAPI plugin support — Java applets do not load at all
  • Enterprises that needed Java moved to Zulu/Adoptium with sandboxing or to dedicated thick-client launchers
Detection/coverage: Tenable/Qualys/Rapid7 plugins for CVE-2011-3544 (e.g., Nessus IDs 56747, 56959) flag vulnerable JRE installs cleanly via registry and file-version checks.
STEP 02

Trigger Rhino reflection abuse

Exploit JavaScript inside the applet calls Object.getClass(...) on a script object to reach Java's reflective API, then walks to java.lang.System and similar privileged classes. The Rhino engine in vulnerable JREs did not properly scope error class access, so attacker-controlled JS could resolve to privileged Java classes. Weaponized PoC: Metasploit exploit/multi/browser/java_rhino by sinn3r and juan vazquez.
Conditions required:
  • Applet/JWS code executes in the vulnerable Rhino interpreter
Where this breaks in practice:
  • AppLocker/WDAC policies that deny java.exe/javaw.exe from user-writable paths block JWS launches
Detection/coverage: EDR (CrowdStrike, SentinelOne, Defender for Endpoint) flag javaw.exe spawning cmd.exe/powershell.exe — well-known parent-child anomaly.
STEP 03

Disable SecurityManager, escape sandbox

The reflective chain reaches java.lang.System.setSecurityManager(null), nulling the applet sandbox. The JVM now runs attacker bytecode with the full permissions of the user account. No memory corruption involved — pure logic flaw.
Conditions required:
  • Reflection chain completed successfully
  • JVM has not been replaced with a hardened OpenJDK build
Where this breaks in practice:
  • Java 8+ enforces stricter JAR signing and Click-to-Play; the CVE simply isn't reachable on those JREs
Detection/coverage: Behavioral EDR catches the post-exploit stage — javaw.exe writing executables to %APPDATA% or invoking LOLBins.
STEP 04

Execute arbitrary native code as the user

Attacker drops a stage-2 binary (historically ZeroAccess, ZeuS Gameover, Reveton) and executes it via Runtime.exec. Code runs at user-token privilege; further privilege escalation requires a separate Windows local-priv vuln.
Conditions required:
  • User context has write access to a path the Java process can launch from
Where this breaks in practice:
  • Application allowlisting and modern EDR block the stage-2 drop
  • Standard-user accounts limit lateral damage
Detection/coverage: Standard malware drop telemetry — VirusTotal coverage on the stage-2 payloads is near 100% by 2026.
03 · Compensating Control

1
Uninstall Oracle JRE 6 and JRE 7 GA from all endpoints — These versions have been out of public support for years. Use SCCM/Intune/Jamf to enumerate and remove. Per the noisgate HIGH mitigation SLA, complete within 30 days.
2
Block javaw.exe and javaws.exe launches from user-writable paths via AppLocker/WDAC — Even if a residual JRE exists, allowlisting prevents Java Web Start abuse. Deploy via GPO within 30 days alongside the inventory sweep.
3
Disable Java browser plugin where Java is still required for thick clients — Set deployment.webjava.enabled=false in deployment.properties. Decouples residual JRE from any browser-reachable surface immediately.
4
Migrate any remaining Java workload to Eclipse Temurin 17/21 LTS or Azul Zulu — Modern OpenJDK builds removed Rhino in favor of Nashorn (then GraalJS) and enforce module-system access checks. Plan within the 180-day noisgate remediation SLA.
5
EDR rule: alert on javaw.exe → cmd.exe/powershell.exe/wscript.exe — Catches post-exploit stage of this and many other Java RCEs. Deploy in detect-then-block mode within 30 days.
What doesn't work
  • Network IPS signatures alone — applet payloads were obfuscated and polymorphic in every EK; signature coverage was always weeks behind.
  • Trusting Click-to-Play prompts in legacy browsers — users click through; the prompt is not a control.
  • Patching only Java 7 to 7u1 — leaves the door open for the next dozen Java sandbox escapes (CVE-2012-4681, CVE-2013-0422, etc.). Uninstall is the answer, not patching.
04 · Intelligence Metadata

The supporting signals.

In-the-wild statusHistorically heavy — weaponized in Blackhole, RedKit, Cool, Phoenix, and Sakura exploit kits 2011–2014. Active campaigns dropped off after Java plugin removal from browsers.
Public PoCMetasploit exploit/multi/browser/java_rhino (sinn3r, juan vazquez). Also packaged in every commercial EK leak from the era.
EPSS0.96714 (~97th percentile) — reflects historical exploitation volume, not current campaign activity.
KEV statusListed on CISA Known Exploited Vulnerabilities Catalog. Due date long past — federal agencies were required to remediate years ago.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — 9.8. The UI:N is generous; in practice a victim had to load a malicious page with Java enabled.
Affected versionsOracle JRE/JDK 7 GA, JRE/JDK 6 Update 27 and earlier, JavaFX 2.0, and older OpenJDK builds incorporating Rhino.
Fixed versionsJRE/JDK 6 Update 29, JRE/JDK 7 Update 1 (Oracle October 2011 CPU). RHEL backports: java-1.6.0-openjdk-1.6.0.0-1.41.1.10.10.el5_7, java-1.6.0-sun-1.6.0.29-1jpp.
Exposure dataShodan/Censys do not directly fingerprint client JRE versions. Browser plugin telemetry from Mozilla (2015) showed <8% of users still ran vulnerable JREs; by 2026 that population is residual kiosks, legacy thick clients, and unmanaged contractor laptops.
Disclosure date2011-10-18 (Oracle Critical Patch Update Advisory).
ReporterCredited in Oracle CPU to Michael 'mihi' Schierl.

Sources.

  1. NVD — CVE-2011-3544
  2. Oracle CPU October 2011
  3. CISA KEV Catalog
  4. Metasploit module — java_rhino
  5. Red Hat advisory RHSA-2011:1380
  6. Mozilla — end of NPAPI plugin support
  7. Krebs on Security — Blackhole Exploit Kit analysis
  8. Michael Schierl — Java exploit research
05 · The Call

Final Verdict
↓ DOWNGRADED to HIGH (8.4/10)

Why this verdict

  • KEV-listed and EPSS 0.967 — the exploitation history is undeniable; this is not theoretical.
  • Browser attack surface collapsed: NPAPI Java plugin removal (Chrome 2015, Firefox 2017) eliminated the drive-by vector that made the original 9.8 stick. Downward pressure: −1.0.
  • User-context impact only: chain ends at user-token RCE, not SYSTEM. No kernel or domain pivot inherent to the bug. Downward pressure: −0.4.
  • Role multiplier: JRE is overwhelmingly deployed on workstations and middleware app servers — *not* a hypervisor, IdP, CA, or kernel-mode agent. Worst-realistic role is a build server or CI runner with privileged service account still on JRE 6/7 — chain there yields credential theft, but installed base of that profile is well under 1% in 2026. Floor remains HIGH, not CRITICAL.
  • KEV listing is a hard floor: regardless of friction, an actively-exploited bug with public Metasploit modules cannot drop below HIGH while the catalog entry stands.

Why not higher?

The original 9.8 CRITICAL assumed a populated browser-plugin ecosystem that no longer exists. Default-modern browsers cannot load the applets that delivered this in 2011–2014. CRITICAL would require fleet-scale exposure today, and the affected JRE versions are residual rather than mainstream.

Why not lower?

KEV status, an EPSS of 0.96714, and a working Metasploit module published over a decade ago mean any unpatched host is one Java Web Start launch from RCE. MEDIUM would imply this is theoretical or hard to exploit — it is neither. Hosts still on JRE 6u27 in 2026 are almost certainly under-managed and under-monitored, raising real-world risk per host.

06 · Verification

Crowdsourced verification payload.

Run on the target Windows endpoint with local admin to enumerate installed Oracle JRE/JDK versions. Invoke as: powershell -ExecutionPolicy Bypass -File Check-CVE-2011-3544.ps1. Exits 1 if a vulnerable JRE/JDK is present, 0 if clean, 2 if no Java found.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# Check-CVE-2011-3544.ps1
# Detects Oracle JRE/JDK <= 6u27 or 7 GA (CVE-2011-3544 / Rhino sandbox escape)
# Output: VULNERABLE | PATCHED | UNKNOWN

$ErrorActionPreference = 'SilentlyContinue'
$found = @()

$uninstallKeys = @(
    'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
    'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)

foreach ($k in $uninstallKeys) {
    Get-ItemProperty $k | Where-Object {
        $_.DisplayName -match 'Java(\(TM\))?\s*(SE\s*)?(Runtime Environment|Development Kit)' -or
        $_.Publisher -match 'Oracle|Sun Microsystems'
    } | ForEach-Object {
        $found += [PSCustomObject]@{
            Name    = $_.DisplayName
            Version = $_.DisplayVersion
            Path    = $_.InstallLocation
        }
    }
}

if (-not $found) {
    Write-Output 'UNKNOWN: no Oracle Java install detected'
    exit 2
}

$vulnerable = $false
foreach ($j in $found) {
    $v = $j.Version
    # Match patterns like 6.0.270, 1.6.0_27, 7.0.0
    if ($v -match '^(1\.)?6.*?(_| )(\d{1,2})$') {
        $upd = [int]$Matches[3]
        if ($upd -le 27) { $vulnerable = $true; Write-Output ("VULNERABLE: {0} {1}" -f $j.Name,$v) }
    }
    elseif ($v -match '^(1\.)?7\.0[\._ ]0?$' -or $v -eq '7.0.0' -or $v -match '^7\s*$') {
        $vulnerable = $true
        Write-Output ("VULNERABLE: {0} {1}" -f $j.Name,$v)
    }
    else {
        Write-Output ("PATCHED-or-newer: {0} {1}" -f $j.Name,$v)
    }
}

if ($vulnerable) { exit 1 } else { exit 0 }