CVE-2026-47010

What it actually does

This is an improper input validation flaw in the ImageIO component of Oracle Java SE and Oracle GraalVM distributions. An unauthenticated network attacker may be able to supply specially crafted image or image-like data to an application, service, sandboxed Java Web Start application, or sandboxed applet that passes that data into the affected ImageIO APIs. If the exploit conditions are met, the attacker can cause limited integrity impact: unauthorized update, insert, or delete operations against data accessible to the affected Java process. The vulnerability is rated low severity with high attack complexity, no confidentiality impact, and no availability impact, but it is network-reachable through applications that expose ImageIO-backed parsing or image-processing functionality.

Why it matters to the business

The main business risk is unauthorized modification of data handled by Java-based applications that process untrusted images or image content. Because Java runtimes are widely embedded in servers, middleware, build systems, desktop applications, and containers, exposure may exist indirectly through applications rather than only through directly internet-facing Java services. The current exploitation signal is low: EPSS is 0.244%, there is no known public exploit maturity, it is not listed in CISA KEV, and it is not known to be used in ransomware campaigns. Even so, organizations should patch during normal vulnerability remediation cycles, prioritizing externally reachable image-upload, document-processing, media-processing, and untrusted-code execution use cases.

How an attack unfolds

An attacker first identifies a Java-based application or client workflow that accepts untrusted image data over a network protocol, such as a web upload, API request, message queue, content import feature, or sandboxed Java application loading remote content. The attacker then submits crafted input designed to reach the Java ImageIO component. If the application uses an affected Java SE or GraalVM runtime and passes the attacker-controlled data into vulnerable ImageIO APIs, the malformed input may bypass expected validation in a way that allows limited unauthorized modification of data accessible to that Java process. The attacker does not need prior authentication, but exploitation is considered difficult because it depends on the precise ImageIO usage pattern, runtime version, data flow, and application permissions. No named threat actors or active exploitation campaigns are currently associated with this vulnerability.

How to fix it

Upgrade affected Java runtimes and rebuild or restart applications so they use the fixed runtime. For Oracle Java SE, Oracle GraalVM for JDK, and Oracle GraalVM Enterprise Edition, apply the vendor CPU or security update newer than the affected releases: Java SE 8u491, 8u491-perf, 11.0.31, 17.0.19, 21.0.11, 25.0.3, and 26.0.1; GraalVM for JDK 17.0.19 and 21.0.11; and GraalVM Enterprise Edition 21.3.18. For Red Hat packages, apply RHSA-2026:50281 or later. Fixed Red Hat package versions include java-11-openjdk 11.0.32.0.9-1.el7_9, 11.0.32.0.9-1.el8, and 11.0.32.0.9-1.el9; java-17-openjdk 17.0.20.0.8-1.1.el8 and 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, and 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, and 21.0.12.0.8-1.1.el10_2; 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.el9 and 25.0.4.0.7-1.1.el10_2; and java-25-openjdk-portable-main 25.0.4.0.7-2.0.2.hum1. Where immediate patching is not possible, reduce exposure by restricting unauthenticated image upload and conversion features, validating file types before processing, enforcing strict content size and format limits, disabling legacy Java Web Start or applet execution where still present, and running Java services with least-privilege access to data stores and filesystems.

How to confirm the fix worked

Confirm runtime versions on hosts, containers, build images, and packaged application bundles, not only system-level Java installations. Use commands such as java -version, rpm -q java-11-openjdk java-17-openjdk java-1.8.0-openjdk java-21-openjdk java-25-openjdk, package manager inventory, container image scanning, and software composition analysis to verify that affected versions are no longer present. Validate that running processes were restarted after the upgrade and are loading the patched Java runtime rather than an embedded or bundled vulnerable JRE. For Red Hat systems, verify RHSA-2026:50281 or a superseding advisory is installed. For Oracle and GraalVM distributions, verify the installed release is newer than the affected version line. Review application routes and services that process images to confirm compensating controls are active if patching is deferred.

Typical attack path

1. Identify applications, services, or sandboxed Java clients that accept untrusted image or media content over the network.
2. Confirm or infer that the target runs an affected Oracle Java SE, Oracle GraalVM, or downstream OpenJDK build and uses ImageIO for image parsing or transformation.
3. Send crafted image data through an exposed upload, import, preview, conversion, or API endpoint that forwards the content to ImageIO APIs.
4. Trigger the vulnerable parsing path under the affected runtime.
5. Abuse the resulting integrity impact to update, insert, or delete data accessible to the Java process.
6. Blend the activity into normal application traffic, since exploitation may look like ordinary image-processing requests unless detailed application, JVM, and data audit logs are reviewed.

How to detect it

There are no public, vulnerability-specific indicators of compromise for this issue and no confirmed exploitation campaigns are currently associated with it. Detection should focus on behavioral evidence around Java applications that process untrusted images. Review web server, API gateway, WAF, application, JVM, EDR, file integrity, and database audit logs for suspicious image uploads or content-ingestion requests followed by unexpected update, insert, or delete activity by the Java application identity. Look for repeated malformed image submissions, unusual image file extensions or content types, high rates of ImageIO parsing failures, exceptions from javax.imageio or com.sun.imageio classes, abnormal write activity by Java processes, and data changes that occur immediately after unauthenticated upload or import requests. Pay special attention to endpoints used for image upload, thumbnail generation, avatar/profile image handling, document preview, media conversion, archive import, and any legacy Java Web Start or applet workflows that load untrusted code from the network.

What your security team should do

• Inventory all Java SE, OpenJDK, and GraalVM installations, including embedded JREs in applications, containers, CI/CD images, developer tooling, and desktop software.
• Prioritize patching externally reachable Java applications that accept image uploads, generate previews, process documents containing images, perform media conversion, or ingest untrusted content from APIs or queues.
• Apply RHSA-2026:50281 or the applicable Oracle/GraalVM security update, then restart dependent services to ensure the fixed runtime is active.
• Add temporary controls for exposed image-processing features: strict file type validation, size limits, authenticated access where feasible, WAF upload restrictions, and rate limiting.
• Review application permissions so Java services cannot update, insert, or delete data beyond what is required for normal operation.
• Search logs for suspicious malformed-image processing activity and correlate with unexpected data modifications by Java application identities.
• Track vendor advisories for exploit publication or EPSS movement; current indicators show low exploitation likelihood and no KEV or ransomware association.