CVE-2026-47063

What it actually does

This is an improper input validation vulnerability in the Libraries component of Oracle Java SE, Oracle GraalVM for JDK, and Oracle GraalVM Enterprise Edition. An unauthenticated network attacker can trigger vulnerable Java library APIs through applications that pass attacker-controlled data into those APIs, including web services or other protocol handlers. Successful exploitation allows unauthorized creation, deletion, or modification of data accessible to the affected Java runtime or application context. The CVSS vector indicates network reachability, low attack complexity, no privileges required, no user interaction, and high integrity impact, with no direct confidentiality or availability impact specified.

Why it matters to the business

Applications running affected Java or GraalVM versions may allow remote attackers to tamper with important business data if those applications expose vulnerable library functionality to untrusted input. Because Java runtimes are widely embedded across application servers, middleware, batch jobs, developer tooling, and client-side Java deployments, exposure can be broad and indirect. The issue is not currently listed in CISA KEV, has no known mature public exploit in the provided data, and has a low EPSS score of 0.00256, but the low-complexity unauthenticated network attack path and high integrity impact justify timely patching, especially for internet-facing Java services and systems processing untrusted content.

How an attack unfolds

An attacker identifies a Java-based service, endpoint, protocol listener, or sandboxed Java client workflow that accepts untrusted input and passes that input to the affected Java Libraries APIs. The attacker crafts input that bypasses expected validation or causes the library to process data incorrectly. When the vulnerable runtime processes the malicious input, the attacker gains the ability to alter data within the permissions of the affected application or Java execution context. In server deployments, this may occur through web services or APIs that feed attacker-controlled data into the vulnerable component. In legacy client-style deployments, exploitation may involve untrusted sandboxed Java Web Start applications or applets that rely on Java sandbox enforcement. No specific threat actors, ransomware use, KEV listing, or public exploit maturity are indicated in the provided intelligence.

How to fix it

Upgrade affected Java and GraalVM runtimes to vendor-fixed versions as soon as practical, prioritizing internet-facing services and applications that process untrusted input. For Red Hat packages, apply RHSA-2026:50281 or later. Fixed 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.el10_2, 21.0.12.0.8-1.1.el8, and 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 and 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 releases 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, and Oracle GraalVM Enterprise Edition users should move beyond 21.3.18. If immediate patching is not possible, reduce exposure by restricting network access to Java services, disabling or removing unused Java Web Start or applet functionality, blocking untrusted code execution, adding strict input validation before data reaches Java library APIs, and monitoring for unauthorized data modification.

How to confirm the fix worked

Confirm all Java and GraalVM runtimes in use have been upgraded to fixed releases. On Linux systems, validate package versions with package-manager queries such as rpm -q java-1.8.0-openjdk java-11-openjdk java-17-openjdk java-21-openjdk java-25-openjdk and confirm installed builds meet or exceed the fixed versions in RHSA-2026:50281. Validate runtime versions with java -version for each application runtime path, container image, base image, and bundled JRE/JDK, not only the system default. For containerized workloads, rebuild images from patched base images and redeploy them, then confirm the running containers no longer include affected Java builds. For Oracle and GraalVM distributions, compare installed releases against the vendor advisory and ensure affected versions are no longer present. Finally, exercise application regression tests for workflows that parse, transform, or persist untrusted input to confirm expected behavior after patching.

Typical attack path

1. Discover a Java or GraalVM-based application exposed over the network or reachable through a supported protocol.
2. Identify functionality that accepts untrusted input and routes it into Java Libraries APIs affected by the vulnerability.
3. Send crafted input designed to trigger improper validation behavior in the affected runtime component.
4. Cause the Java application or sandboxed Java execution context to perform unauthorized data creation, deletion, or modification.
5. Use the application’s own privileges and data access paths to tamper with critical records or other accessible data.

How to detect it

There are no specific public exploit indicators, payload signatures, threat actor names, or ransomware associations in the provided intelligence, so detection should focus on suspicious behavior around Java applications that process untrusted input. Review web server, API gateway, application server, reverse proxy, and Java application logs for unusual requests to endpoints that parse, transform, import, serialize, deserialize, or persist user-supplied data. Correlate those requests with application audit logs and database or object-store audit trails showing unexpected creation, deletion, or modification of records by Java service accounts. Examine Java process logs for parsing exceptions, validation failures, sandbox violations, stack traces in library code, or sudden changes in error rates preceding unauthorized data changes. For client-side Java deployments, review endpoint telemetry for unexpected Java Web Start or applet execution and outbound network activity from Java processes. Because the expected impact is integrity-focused, prioritize evidence of tampering over data theft indicators. Establish a timeline beginning at least from the publication date, 2026-07-21, and compare suspicious activity before and after patch deployment.

What your security team should do

• Inventory all Java SE, OpenJDK, Oracle Java, and GraalVM installations across servers, containers, build agents, developer tooling, and legacy client deployments.
• Prioritize patching internet-facing Java services, APIs, middleware, and systems that process untrusted data or expose multiple network protocols.
• Apply RHSA-2026:50281 or the applicable Oracle/GraalVM vendor update, and redeploy applications so they actually run on the patched runtime.
• Search for bundled or embedded JRE/JDK copies inside application directories, container images, and third-party products, as these may not be updated by operating system package patches.
• Temporarily restrict network access to affected Java services where patching is delayed, especially endpoints that accept externally supplied data.
• Disable or remove sandboxed Java Web Start and applet support where it is not explicitly required.
• Review application logs and data audit trails for unexplained data creation, deletion, or modification since publication on 2026-07-21.
• Add monitoring around high-risk data modification operations performed by Java applications until patch coverage is verified.
• Track vendor advisories for any change in exploit maturity, EPSS trajectory, KEV status, or threat actor activity.