How to Fix CVE-2010-0840: Java SE / JRE Trusted Methods Chaining Remote Code Execution

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

Patch immediately. CISA's Known Exploited Vulnerabilities catalog lists this CVE, which means active exploitation has been confirmed. CISA KEV entry added 2022-05-25, federal due date 2022-06-15.

What is CVE-2010-0840?

CVE-2010-0840 is a remote code execution vulnerability in the Java Runtime Environment (JRE) component of Oracle (then Sun) Java SE and Java for Business. It was published in the March 2010 Java SE Critical Patch Update and is publicly known as the Trusted Methods Chaining Remote Code Execution Vulnerability. The affected builds are Java SE 6 Update 18, 5.0 Update 23, and 1.4.2_25, plus every earlier release in those lines.

The root cause is an improper privilege check when the JRE executes certain methods. As the disclosure (ZDI-10-056, credited to Sami Koivu) describes it, an untrusted object can extend a trusted class without overriding a specific method, or abuse a similar trust issue with interfaces. By chaining these trusted methods, sandboxed code escapes Java's security manager and runs with the full privileges of the JVM. In practice that means a hostile applet, or a Java Web Start application, served from a Web page can execute arbitrary native code on any machine running a vulnerable JRE the moment the user loads the page.

This is a classic client-side “drive-by” Java bug from the era when the browser Java plug-in was ubiquitous. No authentication, no special privileges, and no meaningful user interaction beyond visiting a page are required, which is why the CVSS 3.1 base score is 9.8 with attack vector Network and attack complexity Low.

Why this CVE matters

CVE-2010-0840 was a workhorse of the 2010-2013 exploit-kit era. The Trusted Methods Chaining technique was folded into Metasploit (exploit/multi/browser/java_trusted_chain) and into commercial exploit kits, where it was used to drop banking trojans and ransomware loaders on unpatched desktops. CISA added it to the Known Exploited Vulnerabilities catalog on 2022-05-25 precisely because attackers were still finding old, unpatched JREs worth targeting. If you still run any of the affected Java lines, treat any window of exposure as compromise-likely and review logs accordingly.

Identify the vulnerable JRE

The fix is keyed to the Java build, not to a Linux package name, so first read the actual version Java reports. Run this wherever the JRE is installed:

# Ask Java itself for its build string
java -version
# Example vulnerable output: java version "1.6.0_18"
# Anything at or below 6u18 / 5.0u23 / 1.4.2_25 is affected.

# Find every Java install on a Linux host
which -a java; ls -d /usr/lib/jvm/* 2>/dev/null
update-alternatives --list java 2>/dev/null

# Windows: list every installed JRE/JDK and its version
Get-ChildItem 'HKLM:\SOFTWARE\JavaSoft\Java Runtime Environment','HKLM:\SOFTWARE\WOW6432Node\JavaSoft\Java Runtime Environment' -ErrorAction SilentlyContinue |
  ForEach-Object { $_.GetValue('') }
Get-CimInstance Win32_Product | Where-Object { $_.Name -match 'Java' } | Select-Object Name, Version

How to fix CVE-2010-0840

The fix is to move every affected Java install up to a build at or above the March 2010 Critical Patch Update line:

• Java SE 6 → Update 19 or later
• Java SE 5.0 → Update 24 or later
• Java SE 1.4.2 → 1.4.2_26 or later

All three of those lines reached end of public updates years ago. Unless you have an Oracle support contract that entitles you to those legacy patches, the realistic remediation in 2026 is to remove the obsolete JRE entirely and, if a Java runtime is still required, install a currently supported LTS (for example a maintained OpenJDK 17 or 21 build). Do not try to “upgrade in place” with a modern openjdk-17 package as if it were the same component: the vulnerable artifact is the old Sun/Oracle JRE and it must be uninstalled.

Oracle Java on Windows

# 1. Inventory the legacy Java installs
Get-CimInstance Win32_Product | Where-Object { $_.Name -match 'Java' } |
  Select-Object Name, Version, IdentifyingNumber

# 2. Uninstall each vulnerable Java by its product code (from the step above)
$code = '{IDENTIFYING-NUMBER-FROM-ABOVE}'
Start-Process msiexec.exe -ArgumentList "/x $code /qn /norestart" -Wait

# 3. If a Java runtime is still needed, install a current supported build,
#    e.g. the offline installer downloaded from oracle.com/java or a maintained OpenJDK.
#    Then confirm only the patched build remains:
java -version

Distribution-shipped JRE on Linux

Most Linux vendors backported this fix in 2010. Apply the named errata rather than guessing a package version:

# Red Hat / CentOS, RHSA-2010:0383 (and 0337/0338/0339) updated java-1.6.0-sun / -openjdk
sudo yum update java-1.6.0-openjdk java-1.6.0-sun

# SUSE / openSUSE. SUSE-SR:2010:008 / :011
sudo zypper patch

# Ubuntu, USN-923-1 updated the sun-java6 / openjdk-6 packages
sudo apt-get update
sudo apt-get install --only-upgrade openjdk-6-jre sun-java6-jre

# Mandriva: MDVSA-2010:084
# (use urpmi to pull the updated java-1.6.0-openjdk package)

On a modern, supported distribution the 2010-era java-1.6.0-sun / sun-java6 packages no longer exist; the correct action there is to confirm no end-of-life Java 1.4 / 5 / 6 runtime is present and remove any that is, then standardise on a supported OpenJDK.

Remove the browser Java plug-in

Because CVE-2010-0840 is reachable through hostile applets, the highest-leverage hardening step is to take the Java plug-in out of every browser. On modern browsers the NPAPI/ActiveX Java plug-in is already gone, but on any legacy build still in service:

Java Control Panel  →  Security tab  →  uncheck "Enable Java content in the browser"

Few server workloads ever needed in-browser Java, and disabling the plug-in removes the entire drive-by attack surface for this class of bug.

Detect, remove and verify (Linux)

#!/usr/bin/env bash
# CVE-2010-0840: find end-of-life Sun/Oracle Java and report it for removal.
set -euo pipefail
log() { printf '%s %s\n' "$(date -Is)" "$*" | tee -a /var/log/cve-2010-0840-fix.log; }

log "Detect: enumerating java runtimes"
found_vuln=0
for j in $(which -a java 2>/dev/null) $(ls /usr/lib/jvm/*/bin/java 2>/dev/null); do
    ver=$("$j" -version 2>&1 | head -1)
    log "  $j -> $ver"
    # Flag the affected 1.4.2 / 5.0 / 6 lines
    if echo "$ver" | grep -Eq '1\.4\.2_(0?[0-9]|1[0-9]|2[0-5])|1\.5\.0_(0?[0-9]|1[0-9]|2[0-3])|1\.6\.0_(0?[0-9]|1[0-8])'; then
        log "  VULNERABLE build detected at $j"
        found_vuln=1
    fi
done

if [ "$found_vuln" -eq 1 ]; then
    log "ACTION: remove the flagged Sun/Oracle JRE (yum remove java-1.6.0-sun / apt-get remove sun-java6-jre)"
    log "        then install a supported OpenJDK if Java is still required."
    exit 1
fi
log "SUCCESS: no affected Java 1.4.2/5.0/6 build found."

After removing or upgrading, restart any service or application server that loaded the old JVM so the vulnerable runtime is no longer resident in memory.

If you can't patch immediately

Removing or upgrading the JRE is the only durable fix. These steps cut exposure while you schedule the change; they do not remove the vulnerability.

• Disable the browser Java plug-in (see above). For this applet-driven bug, that alone removes the primary attack path.
• Stop launching untrusted Java Web Start (JNLP) files. Block .jnlp downloads at the proxy and disassociate the javaws handler on locked-down desktops.
• Restrict outbound access from any host still running the old JRE, so a successful exploit cannot easily reach a command-and-control server.

# Limit egress from a legacy host to only known-good destinations (adapt the subnet).
sudo iptables -A OUTPUT -d 10.0.0.0/8 -j ACCEPT
sudo iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -j DROP
sudo iptables-save | sudo tee /etc/iptables/rules.v4

Verify the fix

After upgrading or removing the JRE, confirm the version Java reports is at or above the March 2010 CPU line, or that no affected runtime remains at all.

java -version                 # must show >= 1.6.0_19, 1.5.0_24, or 1.4.2_26 (or a modern JDK)
which -a java                 # make sure no second, older java is shadowed on the PATH
update-alternatives --list java   # Debian/RHEL: confirm the default points at the patched build

Then run an authenticated vulnerability scan with a current signature set and confirm the scanner no longer flags CVE-2010-0840. For internet-facing or end-user systems that ran an unpatched JRE during the exposure window, review logs and endpoint telemetry for that period and rotate any credentials the affected machines could reach. Trusted Methods Chaining exploits ran with full JVM privileges, so a successful hit means full host compromise.

Frequently asked questions

Which Java versions are affected by CVE-2010-0840 and which fix it?

Oracle (then Sun) Java SE and Java for Business 6 Update 18, 5.0 Update 23, and 1.4.2_25 and earlier are affected. The March 2010 Java SE Critical Patch Update fixed it in JDK/JRE 6 Update 19, 5.0 Update 24, and 1.4.2_26. Upgrade to those builds or, preferably in 2026, remove the end-of-life JRE and move to a currently supported runtime.

Is openjdk-17 the right package to update for CVE-2010-0840?

Not as an in-place upgrade. The vulnerable artifact is the old Sun/Oracle JRE (1.4.2 / 5.0 / 6). Modern OpenJDK 17 is a separate, unaffected runtime. If your distribution shipped a Sun-derived JRE in 2010, apply its errata (RHSA-2010:0383, USN-923-1, MDVSA-2010:084, SUSE-SR:2010:008). Otherwise, uninstall the legacy JRE and install a supported OpenJDK only if Java is still needed.

What does “Trusted Methods Chaining” actually mean here?

The JRE failed to properly check privileges when executing certain methods. An untrusted object could extend a trusted class without overriding a specific method, or abuse a similar trust issue with interfaces. Chaining those trusted methods let sandboxed applet code escape the security manager and run arbitrary native code.

Is there a public exploit for CVE-2010-0840?

Yes. It was disclosed through ZDI-10-056 (Sami Koivu, Zero Day Initiative) and weaponized in the Metasploit module exploit/multi/browser/java_trusted_chain, and it appears in the CISA KEV catalog. Treat working attack code as certain.

References

• Oracle Java SE March 2010 CPU advisory: http://www.oracle.com/technetwork/topics/security/javacpumar2010-083341.html
• ZDI-10-056 (original disclosure): http://www.zerodayinitiative.com/advisories/ZDI-10-056
• NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2010-0840
• CISA KEV record: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2010-0840
• Red Hat errata RHSA-2010:0383: http://www.redhat.com/support/errata/RHSA-2010-0383.html
• Ubuntu USN-923-1: http://ubuntu.com/usn/usn-923-1
• SecurityFocus BID 39065: http://www.securityfocus.com/bid/39065
• Secunia advisory 39317: http://secunia.com/advisories/39317

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.

Related fixes

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

• How to Fix CVE-2026-34305: Oracle WebLogic Server (Bundle Sibling)
• How to Fix CVE-2026-21937: Critical Vulnerability in MySQL Server
• How to Fix CVE-2026-21962: Critical Vulnerability in Oracle HTTP Server, Oracle Weblogic Server Proxy Plug-in
• How to Fix CVE-2026-35243: Access control in Oracle Application Development Framework (ADF)
• How to Fix CVE-2013-0431: Protection Mechanism Failure in Java Runtime Environment (Jre)