——
HighVULNERABILITIES

CVE-2026-114820: update Oracle Java to remove compromised eMudhra roots

Oracle’s 24 October 2026 Security Alert fixes a remotely exploitable JSSE flaw affecting supported Oracle Java and GraalVM builds. Identify the exact runtime, upgrade through the supported channel, then verify the deployed build.

Oracle’s 24 October 2026 Security Alert fixes a remotely exploitable JSSE flaw affecting supported Oracle Java and GraalVM builds. Identify the exact runtime, upgrade through the supported channel, then verify the deployed build.

Oracle JavaGraalVMJSSECVE-2026-114820Patch management

Summary

Field Verified status
CVE CVE-2026-114820
Product Oracle Java SE; Oracle GraalVM for JDK; Oracle GraalVM Enterprise Edition
Affected versions Oracle Java SE 8u511-b32, 8u511-perf-b32, 11.0.33.0.2, 17.0.21.0.2, 21.0.13.0.2, 25.0.5.0.2 and 27.0.1.0.2; GraalVM for JDK 17.0.21.0.2 and 21.0.13.0.2; GraalVM Enterprise Edition 21.3.20.0.2
Fixed version The current Java update supplied through Oracle’s patch-availability path; Oracle says to update to the latest Java version
CVSS 9.1, CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
EPSS Not published in the EPSS dataset checked on 25 October 2026
Exploitation Not confirmed. Oracle’s alert says the issue is remotely exploitable without authentication; it does not say it is exploited in the wild.
CISA KEV No, checked 25 October 2026
Author urgency High for systems that use JSSE to validate remote TLS peers, and for client deployments that run untrusted sandboxed code. Treat it as an urgent, controlled runtime update.

Publication date: 24 October 2026. Oracle issued revision 1 of its Security Alert on that date.

What Oracle fixed

Oracle says CVE-2026-114820 concerns JSSE and its handling of the eMudhra root CA certificates. The supplied Java updates remove the impacted roots. Oracle rates the issue 9.1 and says it can be exploited over a network without authentication.

That is a strong technical severity signal, not proof that every Java process is equally exposed. Oracle’s risk-matrix note specifically calls out services that supply data to APIs in the affected component, plus client deployments that run untrusted sandboxed Java Web Start applications or applets and depend on the Java sandbox. Confirmed facts stop there: this alert does not name a public exploit, a victim, or active exploitation.

Are you affected?

You are in scope if a deployed Oracle Java or Oracle GraalVM runtime reports one of the affected builds in the table and the workload uses JSSE or makes outbound TLS connections to services whose identity it validates. Inventory both application runtimes and bundled JREs; a server's operating-system Java package is not necessarily the runtime used by a service.

On each owned host, run:

java -version
readlink -f "$(command -v java)"

Expected result: record the full version string and resolved binary path. A version matching the affected list is affected until updated. A newer build alone is not enough evidence when several Java installations exist: repeat the check under the service account or inspect the service unit/container image for its configured Java path.

For a Java process already running, capture its command line and executable before maintenance:

ps -ef | grep '[j]ava'

Interpretation: the result identifies candidate processes and their launch arguments; it does not prove JSSE use or vulnerability. Do not test this issue by attempting certificate impersonation.

NetTools.tech — DNS Lookup: enter the approved hostname of a remote service that the Java application connects to. Compare returned A/AAAA records with your documented dependency. An unexpected public destination is a reason to review egress and trust assumptions. Limit: DNS does not prove the Java runtime, its trust store, TLS validation behaviour, or whether CVE-2026-114820 is reachable. Use it only for systems you own or administer.

Patch through the supported Java channel

Prerequisites

  • Open an approved change and identify the service owner, Java home, deployment method and maintenance window.
  • Take a tested application/configuration backup or image snapshot according to your normal recovery procedure.
  • Preserve the pre-change java -version, process list and service health evidence.
  • Obtain the replacement build from Oracle’s Java download and patch-availability documentation for your licensed/supported release train.

Steps

  1. In the service’s deployment configuration, identify the exact JAVA_HOME or container image tag in use. Do not update an unused system Java installation.
  2. Download and install the current Oracle update for that train using Oracle’s documented installer or your organisation’s approved package/image pipeline. Oracle’s Security Alert directs customers to update to the latest Java version.
  3. Point the application or service at the newly installed runtime. For a systemd-managed service, update the approved environment/configuration if necessary, then restart it in the maintenance window:
    sudo systemctl restart <service-name>
    sudo systemctl status <service-name> --no-pager
    
    Expected result: the service is active and its health check succeeds. Replace <service-name> with your own service; do not run this command against an unknown workload.
  4. Run the application’s normal smoke test and inspect its TLS-dependent integrations. Record the time, new runtime build and outcome in the change.

Validate

Run the version command using the same account and Java path used by the application:

sudo -u <service-account> <JAVA_HOME>/bin/java -version

Expected result: the reported build is no longer one of Oracle’s listed affected versions. Also check application health and TLS connection logs. A successful start proves only that the application launched; the version command is the evidence that the remediated runtime is deployed.

Containment while change is pending

Oracle’s alert recommends updating or applying its recommended mitigations, but does not publish a separate configuration workaround in the alert. Do not invent one. Until the update window, reduce avoidable exposure: limit untrusted network paths to the service, restrict who can deploy or alter Java runtimes, and review outbound TLS dependencies. These are containment measures, not a fix.

Rollback

If the upgraded runtime causes a verified operational failure, restore the prior runtime/configuration through the tested change rollback procedure and restart the affected service. Record that rollback reintroduces the listed vulnerable build; keep compensating network restrictions in place and schedule a vendor-supported remediation path. Never treat rollback as a security resolution.

Evidence and interpretation

Oracle’s alert is the primary source for affected builds, remote unauthenticated exploitability, CVSS and the required action. Its publication date is 24 October 2026, revision 1. The NVD record independently reproduces the CVSS and affected-product data, while the CISA KEV catalogue was checked for exploitation prioritisation. Neither source turns “not listed” into proof of safety.

This article deliberately does not claim active exploitation. The current evidence supports urgent patching because the vendor describes remote unauthenticated exploitability and a high-impact trust-store correction, not because of a media headline.

Chronology

  • 24 October 2026: Oracle publishes Security Alert Advisory CVE-2026-114820, revision 1.
  • 25 October 2026: notmyfault.fail checks Oracle’s advisory, the NVD CVE record and the CISA KEV catalogue; no KEV listing or vendor confirmation of in-the-wild exploitation was found.

References

  1. Oracle Security Alert Advisory — CVE-2026-114820
  2. Oracle: eMudhra certificate information
  3. Oracle Java downloads
  4. NVD: CVE-2026-114820
  5. CISA Known Exploited Vulnerabilities Catalog

Change log

  • 25 October 2026 — r1: Initial publication.