CVE-2026-47059

What it actually does

This is an availability-only flaw in the Java 2D component of Oracle Java SE and Oracle GraalVM JDK/Enterprise Edition. In affected releases, specially crafted untrusted Java code executed inside a sandboxed Java client context, such as Java Web Start or legacy Java applets, can trigger a fault condition that partially disrupts the Java runtime or the affected application. The issue is remotely reachable over multiple delivery protocols when the victim runtime loads attacker-controlled code, requires no authentication, has high exploit complexity, and does not provide confidentiality or integrity impact. Server-side Java deployments that execute only trusted administrator-installed code are not the primary exposure described for this vulnerability.

Why it matters to the business

The most likely consequence is disruption of Java-based client applications or business workflows that still depend on Java Web Start, applets, or other sandboxed execution of untrusted internet-sourced code. Because the CVSS score is low, EPSS is low, there is no known public exploit maturity, and it is not in the CISA KEV catalog or associated with ransomware, broad emergency response is generally not warranted; however, organizations with legacy Java client usage should prioritize routine patching because user-facing outage or instability can still affect operations.

How an attack unfolds

An attacker would host or deliver malicious Java content intended to run in a sandboxed Java client environment, such as a Java Web Start application or applet-like workflow. A victim system with an affected Java SE, OpenJDK, or GraalVM runtime loads that untrusted code over a network-accessible delivery path. The malicious code exercises the vulnerable Java 2D component in a way that satisfies the high-complexity trigger conditions. If successful, the Java runtime or the specific Java application experiences a partial denial-of-service condition, such as a crash, hang, or degraded availability. The attack does not enable code execution, data theft, or privilege escalation based on the disclosed impact, and deployments that only run trusted server-side Java code are not the typical target.

How to fix it

Apply the vendor updates for all affected Java runtimes, especially systems that can launch Java Web Start, applets, or other sandboxed Java client code. For Red Hat packages, update to the fixed builds from RHSA-2026:50281 or later: java-11-openjdk 11.0.32.0.9-1.el7_9, 11.0.32.0.9-1.el8, or 11.0.32.0.9-1.el9; java-17-openjdk 17.0.20.0.8-1.1.el8 or 17.0.20.0.8-1.1.el9; java-1.8.0-openjdk 1.8.0.502.b07-1.1.el7_9, 1.8.0.502.b07-1.1.el8, or 1.8.0.502.b07-1.2.el9; java-21-openjdk 21.0.12.0.8-1.1.el10_2, 21.0.12.0.8-1.1.el8, or 21.0.12.0.8-1.2.el9; java-21-openjdk-main and java-21-openjdk-portable-main 21.0.12.0.8-0.1.hum1; java-25-openjdk 25.0.4.0.7-1.1.el10_2 or 25.0.4.0.7-1.1.el9; and java-25-openjdk-portable-main 25.0.4.0.7-2.0.2.hum1. Oracle Java SE users should move beyond affected versions 8u491, 8u491-perf, 11.0.31, 17.0.19, 21.0.11, 25.0.3, and 26.0.1; Oracle GraalVM for JDK users should move beyond 17.0.19 and 21.0.11; Oracle GraalVM Enterprise Edition users should move beyond 21.3.18. Where immediate patching is not possible, disable or restrict Java Web Start, applet execution, and loading of untrusted Java code; enforce application allowlisting for JNLP/JAR sources; block unnecessary Java client launchers; and ensure server-side Java services execute only trusted, administrator-managed code.

How to confirm the fix worked

Confirm package versions with the operating system package manager and runtime commands such as java -version, rpm -q java-1.8.0-openjdk java-11-openjdk java-17-openjdk java-21-openjdk java-25-openjdk, or equivalent software inventory tooling. Validate that affected Oracle Java, OpenJDK, and GraalVM versions have been replaced with fixed versions or later. Review endpoint configuration to confirm Java Web Start, browser applet support, and unrestricted execution of internet-downloaded JAR or JNLP content are disabled or tightly controlled where not required. For exposure validation, inventory endpoints and application launch paths that can load untrusted Java code and verify that only approved sources are permitted. For functional validation, run representative Java 2D-dependent client workflows after patching to confirm stability and compatibility.

Typical attack path

1. Identify organizations or users that still run sandboxed Java Web Start, legacy applets, or Java client workflows that load untrusted code.
2. Craft Java content that invokes Java 2D functionality in the vulnerable runtime under the necessary edge conditions.
3. Deliver the content through a website, downloaded JNLP workflow, email link, or another network-accessible path that causes the victim Java runtime to load it.
4. The victim launches or automatically loads the untrusted Java content using an affected Java SE, OpenJDK, or GraalVM version.
5. The malicious content triggers the Java 2D flaw and causes partial denial of service of the Java runtime or affected application.
6. The attacker repeats delivery to disrupt availability for targeted users or workflows.

How to detect it

Because the disclosed impact is partial denial of service rather than compromise, evidence is more likely to appear as Java application instability than as persistent malware artifacts. Review endpoint telemetry, EDR events, Java console logs, Java Web Start traces, browser/download histories, proxy logs, and application logs for Java client launches that shortly precede crashes, hangs, JVM fatal error files, or user reports of repeated Java application termination. Focus on events involving JNLP files, downloaded JARs, applet-like workflows, or Java content loaded from unfamiliar external domains. Search for JVM crash artifacts such as hs_err_pid files created near the time of suspicious Java Web Start or applet activity, and inspect stack traces for Java 2D, AWT, font, image, rendering, or native desktop graphics libraries. In network logs, correlate outbound requests for .jnlp, .jar, or Java client resources with subsequent java/javaw process crashes. There are no public threat actors, ransomware campaigns, or known exploitation campaigns identified in the provided data, so detection should be behavior- and artifact-driven rather than actor-specific.

• hs_err_pid*.log
• javaws
• javaws.exe
• java.exe
• javaw.exe
• .jnlp
• .jar
• Java Web Start
• JNLPException
• java.lang.OutOfMemoryError
• A fatal error has been detected by the Java Runtime Environment
• Problematic frame:
• sun.java2d
• java.awt
• javax.imageio
• libawt
• libfontmanager
• awt.dll
• fontmanager.dll

What your security team should do

• Prioritize patching on endpoints and shared client platforms that can run Java Web Start, legacy applets, downloaded JNLP files, or untrusted Java client applications.
• Inventory Java SE, OpenJDK, and GraalVM versions across endpoints and build images; flag Oracle Java SE 8u491, 11.0.31, 17.0.19, 21.0.11, 25.0.3, 26.0.1, GraalVM for JDK 17.0.19/21.0.11, and GraalVM Enterprise Edition 21.3.18 as vulnerable.
• Use standard maintenance windows for server-only Java workloads that execute trusted code, but still update them to reduce version drift and future exposure.
• Disable Java Web Start, browser/app workflows, and execution of untrusted JAR/JNLP content where there is no business requirement.
• Add monitoring for repeated Java client crashes, JVM fatal error logs, and Java Web Start launches from unusual URLs or recently downloaded content.
• Communicate to help desks and desktop support teams that repeated Java client crashes after opening internet-sourced Java content should be escalated for security review.
• Track vendor advisories for Oracle and Red Hat packages and ensure golden images, containers, developer workstations, and VDI templates receive the same runtime updates.