CVE-2026-34268

What it actually does

This is an information disclosure vulnerability in the Security component of Oracle Java SE, Oracle JDK/JRE, Oracle GraalVM for JDK, and Oracle GraalVM Enterprise Edition. An attacker who can execute code in the same infrastructure where a vulnerable Java or GraalVM runtime is used, or who can influence data passed into affected Java security APIs through an exposed service, may be able to read a limited subset of data that should not be accessible. The issue has confidentiality impact only: it does not provide code execution, privilege escalation, data modification, or service disruption by itself. Oracle also notes relevance to sandboxed Java Web Start or applet-style deployments that run untrusted code and depend on the Java sandbox for isolation.

Why it matters to the business

The likely business impact is limited unauthorized exposure of sensitive application or runtime-accessible data from systems using affected Java or GraalVM versions. Risk is lower than for remotely exploitable code execution flaws because exploitation is high complexity, requires local/infrastructure access or a service path into the affected APIs, has low EPSS, and is not listed in CISA KEV or known ransomware use. However, Java is widely deployed across enterprise applications, build systems, middleware, and endpoint software, so organizations should treat patching as a broad software hygiene task, especially for internet-facing services that process untrusted input through Java security APIs or legacy deployments that rely on Java sandboxing.

How an attack unfolds

An attacker first needs a path to interact with the vulnerable Java or GraalVM runtime. This may be local access to the infrastructure where Java executes, the ability to run untrusted sandboxed Java code, or an application endpoint that accepts attacker-controlled data and passes it into affected Java Security component APIs. The attacker then crafts inputs or code paths that trigger the flaw under specific conditions. If successful, the runtime discloses a subset of data accessible to the Java or GraalVM process that should have remained isolated. The attacker can then use the exposed information for reconnaissance, credential discovery, application mapping, or to support later attacks. There is no public exploit maturity indicated, EPSS is very low and stable, and no named threat actors or KEV exploitation are currently associated with this vulnerability.

How to fix it

Apply the relevant Oracle Critical Patch Update or later vendor-supported Java/GraalVM release that supersedes the affected versions. Affected versions include Oracle Java SE 8u481, 8u481-b50, 8u481-perf, 11.0.30, 17.0.18, 21.0.10, 25.0.2, and 26; Oracle GraalVM for JDK 17.0.18 and 21.0.10; and Oracle GraalVM Enterprise Edition 21.3.17. Where exact fixed versions are not listed in asset tooling, upgrade to the latest available CPU/security release for the installed major line from Oracle or the supported distribution vendor. Prioritize patching internet-facing Java applications, services that process untrusted input, systems running untrusted plug-ins or scripts, and any legacy Java Web Start or applet-style deployments. If immediate patching is not possible, reduce exposure by disabling untrusted Java execution, removing Java browser plug-ins/Web Start where present, limiting local shell access, restricting who can deploy or run Java code, validating and constraining inputs to exposed APIs, and applying least-privilege controls to the Java process so any disclosed data is minimized.

How to confirm the fix worked

Inventory installed Java and GraalVM runtimes and confirm they are no longer on the affected release levels. Use commands such as `java -version`, `javac -version`, `jshell --version`, `gu --version`, package manager queries, container image scans, and software composition analysis to locate vulnerable runtimes across servers, endpoints, build agents, application images, and bundled application directories. Confirm production services were restarted after runtime replacement so they are using the patched JVM rather than an old in-memory process. For containerized deployments, rebuild base images and redeploy workloads, then verify the runtime version inside the running container. For applications embedding a private JRE/JDK, confirm the bundled runtime was updated, not only the system Java installation. Validate compensating controls by confirming untrusted Java Web Start/applet execution is disabled or removed and that externally reachable services do not unnecessarily expose code paths into Java security APIs with attacker-controlled input.

Typical attack path

1. Identify systems running affected Oracle Java SE, Oracle JRE/JDK, Oracle GraalVM for JDK, or Oracle GraalVM Enterprise Edition versions.
2. Determine whether the runtime is reachable through local code execution, sandboxed untrusted Java execution, or an application/web service that passes attacker-controlled data into Java security APIs.
3. Craft inputs or Java code that exercise the vulnerable Security component behavior under high-complexity conditions.
4. Trigger the vulnerable code path and obtain unauthorized read access to a limited subset of runtime- or application-accessible data.
5. Use any disclosed data to refine reconnaissance, identify secrets or configuration details, or assist follow-on attacks against the application or host.

How to detect it

There are no known public exploit indicators, malware artifacts, or KEV-confirmed exploitation patterns specific to this vulnerability. To assess possible prior exploitation, focus on where untrusted input or code could have reached vulnerable Java Security component APIs. Review application logs, web access logs, API gateway logs, Java exception logs, JVM crash/error logs, endpoint telemetry, and EDR process execution records for unusual Java activity, repeated malformed requests, unexpected security-related exceptions, sandbox violations, or unauthorized attempts to run Java Web Start/applet content. Investigate suspicious local execution of Java by untrusted users, unexpected child processes spawned by Java applications, anomalous reads of sensitive configuration or credential files by Java processes, and unusual outbound connections following Java application errors. For web services, correlate suspicious requests with Java stack traces or error responses around security, certificate, cryptography, policy, class loading, or sandbox operations. Absence of such evidence does not prove non-exploitation because a successful information disclosure may leave only application-level traces and no unique IOC.

What your security team should do

• Prioritize an enterprise-wide inventory of Oracle Java SE, Oracle JRE/JDK, Oracle GraalVM for JDK, and GraalVM Enterprise Edition versions, including bundled runtimes inside third-party applications and containers.
• Patch affected runtimes to the latest Oracle CPU/security release or supported vendor release, prioritizing internet-facing services, systems handling sensitive data, and platforms that execute untrusted or tenant-supplied Java code.
• Retire or disable legacy Java Web Start and Java applet workflows where possible, especially those relying on sandbox isolation for untrusted internet-sourced code.
• Restrict local interactive access and code deployment permissions on systems running vulnerable Java runtimes until patching is complete.
• Review Java applications that pass untrusted data into security-related APIs and add input validation, least-privilege runtime permissions, and defensive logging around suspicious failures or access attempts.
• Rebuild and redeploy container images, CI/CD runners, and application bundles that include vulnerable Java or GraalVM runtimes rather than only updating host packages.
• Because this vulnerability is not in KEV, has no known exploit maturity, and has very low stable EPSS, handle it through normal patch governance unless the runtime is exposed to untrusted code or sensitive data paths.