CVE-2026-47021

What it actually does

This is a network-reachable, unauthenticated denial-of-service vulnerability in the Java 2D component of Oracle Java SE, Oracle GraalVM for JDK, and Oracle GraalVM Enterprise Edition. Applications become exposed when they pass attacker-controlled content into affected Java 2D APIs, such as through web services, image-processing workflows, document rendering, thumbnail generation, print/graphics conversion, or sandboxed Java Web Start/Applet code that loads untrusted content. Successful exploitation affects availability only: it can partially disrupt the Java runtime or application process, without granting code execution, data disclosure, or data modification according to the published CVSS vector.

Why it matters to the business

A successful attack can cause Java-based services or client-side Java workloads to crash, hang, degrade, or become partially unavailable when processing malicious input. The operational impact is most relevant for internet-facing services that accept or transform images, documents, graphics, fonts, or other media handled by Java 2D. The CVSS score is moderate, EPSS is currently low at 0.00305, it is not listed in CISA KEV, and no public exploit maturity is reported, but Java is widely deployed and the issue is easy to exploit where vulnerable API exposure exists, so remediation should be handled through normal patch cycles with prioritization for externally exposed and high-availability systems.

How an attack unfolds

An attacker first identifies a Java-based application or client workflow that accepts untrusted content and routes it into Java 2D processing. The attacker then sends specially crafted input over an available network protocol, commonly through an upload, rendering, conversion, preview, print, or web-service endpoint. When the vulnerable runtime processes the malicious content through the affected 2D component, the runtime or application experiences a partial denial-of-service condition. The attacker does not need authentication, user interaction, or local access if the vulnerable processing path is reachable over the network. Repeated submissions can keep the affected service degraded until the vulnerable runtime is patched, the input path is blocked, or compensating controls reject the malformed content.

How to fix it

Upgrade affected Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition, and downstream OpenJDK packages to fixed releases. For Red Hat packaged OpenJDK, apply RHSA-2026:50281 or later. Fixed Red Hat versions include: 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.el8, 21.0.12.0.8-1.2.el9, or 21.0.12.0.8-1.1.el10_2; java-25-openjdk 25.0.4.0.7-1.1.el9 or 25.0.4.0.7-1.1.el10_2. Also update portable, Windows, and main package variants where used, including 21.0.12.0.8-0.1.hum1 and 25.0.4.0.7-2.0.2.hum1 where applicable. As interim mitigation, restrict unauthenticated access to endpoints that process untrusted images, graphics, documents, fonts, or rendered content; enforce file type, size, and structure validation before Java processing; rate-limit expensive conversion/rendering endpoints; isolate rendering workers; and disable legacy Java Web Start/Applet exposure where it remains in use.

How to confirm the fix worked

Confirm the active Java runtime used by each application has been upgraded, not just the system default Java package. Validate with package inventory and runtime checks such as java -version, rpm -q java-*-openjdk, container image manifests, application base images, and embedded JRE/JDK paths. Verify Red Hat systems report the fixed package versions from RHSA-2026:50281 or later. Restart Java services after patching so processes no longer run the vulnerable runtime. For containerized deployments, rebuild and redeploy images based on patched JDK/JRE layers. Review application dependency and deployment manifests for bundled Oracle JDK, OpenJDK, GraalVM for JDK, or GraalVM Enterprise Edition runtimes. Exposure validation should identify services that accept untrusted content and invoke Java 2D classes, including image read/write, graphics rendering, font handling, document preview, thumbnailing, and print workflows.

Typical attack path

1. Find an internet-facing or network-accessible Java service that accepts untrusted media, graphics, documents, or other content processed by Java 2D APIs.
2. Craft input intended to trigger the vulnerable Java 2D parsing or rendering behavior.
3. Submit the content to an upload, preview, conversion, rendering, web-service, or sandboxed Java execution path.
4. Cause the Java process, worker, rendering job, or application function to crash, hang, or degrade.
5. Repeat requests to maintain partial service disruption or exhaust worker capacity.

How to detect it

Look for evidence of availability-focused exploitation rather than data theft. Useful sources include Java application logs, web access logs for upload/render/preview/conversion endpoints, reverse proxy and WAF logs, process supervisor logs, container orchestration events, systemd logs, JVM crash files, and application performance monitoring data. Investigate repeated unauthenticated requests immediately preceding Java process crashes, worker restarts, rendering job failures, timeout spikes, or error bursts. Pay particular attention to endpoints handling images, graphics, documents, fonts, print/preview functions, thumbnails, or any service that invokes Java 2D APIs. On Linux systems, review journalctl, /var/log/messages, /var/log/syslog, application logs, and JVM fatal error files such as hs_err_pid*.log. In Kubernetes or container platforms, review pod restart counts, OOM/crash-loop events, container stdout/stderr, ingress logs, and service mesh telemetry. Since no public exploit string or malware artifact is specified for this vulnerability, correlate suspicious requests by timing, source IP repetition, malformed media/document submissions, abnormal content types, and immediate Java availability failures.

• hs_err_pid
• sun.java2d
• java.awt
• javax.imageio
• java.lang.OutOfMemoryError
• A fatal error has been detected by the Java Runtime Environment
• SIGSEGV
• EXCEPTION_ACCESS_VIOLATION
• CrashLoopBackOff
• Back-off restarting failed container

What your security team should do

• Inventory all Java SE, OpenJDK, Oracle GraalVM for JDK, and GraalVM Enterprise Edition runtimes, including embedded runtimes inside applications, containers, build images, and desktop Java deployments.
• Prioritize patching internet-facing Java services that process uploaded or remote images, graphics, documents, fonts, previews, thumbnails, or rendering jobs.
• Apply RHSA-2026:50281 or vendor-equivalent updates and restart all affected Java processes.
• Rebuild container images and redeploy workloads that include vulnerable JDK/JRE layers.
• Add or tighten validation, size limits, content inspection, authentication, and rate limits for endpoints that feed untrusted content into Java 2D processing.
• Monitor for repeated Java crashes, rendering worker failures, abnormal restart loops, spikes in failed media-processing requests, and unusual traffic to upload or conversion endpoints.
• Where patching is delayed, isolate rendering/conversion workers and prevent a single malformed request from affecting core application availability.