CVE-2026-47027

What it actually does

This is a remotely reachable denial-of-service vulnerability in the Java SE Libraries component affecting multiple Oracle Java SE, Oracle GraalVM, and Red Hat OpenJDK package lines. An unauthenticated attacker with network access can supply crafted data through protocols or application interfaces that invoke the vulnerable library APIs. Successful exploitation can cause partial denial of service of the Java runtime or Java application using those APIs. The CVSS vector indicates network attack vector, low attack complexity, no privileges required, no user interaction, unchanged scope, and low availability impact only; confidentiality and integrity impacts are not indicated.

Why it matters to the business

The primary business risk is service degradation or intermittent outages in Java-based applications that process attacker-controlled data through affected library APIs. Because Java is commonly embedded across application servers, middleware, backend services, desktop clients, and build/runtime images, exposure can be broad even when Java is not the externally advertised product. The current exploitation signal is low: EPSS is 0.00289, there is no known CISA KEV listing, no ransomware association, and exploit maturity is reported as none. Even so, the vulnerability is remotely reachable, requires no authentication, and has low attack complexity, so internet-facing Java services and applications that parse untrusted network data should be prioritized for routine patching.

How an attack unfolds

An attacker identifies a Java-based service, API, client workflow, or sandboxed Java execution path that accepts untrusted input and passes that input into the affected Oracle Java SE or OpenJDK library component. Because the flaw is network exploitable with low complexity and does not require authentication or user interaction for server-side exposure, the attacker can send crafted data over a supported protocol to the exposed application. The vulnerable Java library mishandles the input in a way that degrades availability, such as causing excessive processing, runtime instability, request handling failure, or partial service interruption. In server deployments, this may present as degraded application responsiveness, failing requests, or restarts of Java worker processes. In legacy client-style deployments using Java Web Start or sandboxed applets, untrusted code from the internet may trigger the same vulnerable behavior if the deployment relies on the Java sandbox for containment. The known impact is limited to availability; the provided information does not indicate confidentiality loss, integrity modification, privilege escalation, or remote code execution.

How to fix it

Upgrade affected Java runtimes to fixed vendor releases and rebuild/redeploy applications so they actually run on the patched JVM. For Red Hat OpenJDK packages, apply RHSA-2026:50281 or later. Fixed package baselines 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-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 or 25.0.4.0.7-1.1.el10_2; and java-25-openjdk-portable-main 25.0.4.0.7-2.0.2.hum1. For Oracle Java SE, move beyond affected versions 8u491, 8u491-perf, 11.0.31, 17.0.19, 21.0.11, 25.0.3, and 26.0.1. For Oracle GraalVM for JDK, move beyond 17.0.19 and 21.0.11; for GraalVM Enterprise Edition, move beyond 21.3.18. Where immediate patching is not possible, reduce exposure by restricting unauthenticated access to Java services, applying rate limits and request size limits, disabling or isolating legacy Java Web Start/applet use, blocking untrusted code execution, and adding circuit breakers or resource limits around endpoints that feed untrusted data into Java library APIs.

How to confirm the fix worked

Confirm remediation by verifying the active runtime version used by each application, not only the installed package version. Use commands such as java -version, package manager queries, container image scans, SBOM review, and runtime introspection from deployed services. Validate that Red Hat systems include RHSA-2026:50281 or later and meet the fixed package baselines for the relevant Java stream. For containerized workloads, rebuild images from patched base layers and redeploy running workloads; then confirm no running process still maps an older embedded JRE/JDK. For Oracle Java SE and GraalVM, verify the deployed versions are later than the affected releases listed by the vendor. Exposure testing should identify services that accept unauthenticated external input and run on affected Java versions; avoid destructive denial-of-service testing in production. After patching, monitor restart rates, JVM fatal logs, request timeout rates, and 5xx error rates to confirm stability has returned.

Typical attack path

1. Identify an exposed Java-based service, API, middleware component, or client execution path that accepts untrusted data from the network.
2. Determine whether the target likely runs an affected Java SE, OpenJDK, or GraalVM version by fingerprinting headers, behavior, package metadata leaks, stack traces, container images, or application documentation.
3. Craft input that reaches Java Libraries APIs through a web service, RPC endpoint, message protocol, file-processing path, or sandboxed Java Web Start/applet execution path.
4. Send the crafted input without authenticating, or from a low-friction network position where the protocol is reachable.
5. Trigger abnormal behavior in the vulnerable Java library, degrading runtime availability or causing affected application functions to fail.
6. Repeat or automate requests to sustain partial denial of service, increase error rates, exhaust processing capacity, or force repeated Java process restarts.

How to detect it

There are no public, CVE-specific indicators or payload signatures available from the provided intelligence. Detection should focus on evidence of attempted or successful denial-of-service against Java runtimes after the publication date. Review application, reverse proxy, API gateway, load balancer, EDR, and JVM logs for sudden spikes of unauthenticated requests followed by Java process hangs, repeated restarts, worker thread exhaustion, abnormal garbage collection pressure, fatal JVM error logs, or recurring application exceptions in code paths that process externally supplied data. Correlate HTTP 5xx/timeout spikes, container restarts, Java process crashes, and resource saturation with source IPs, user agents, request paths, message queues, RPC endpoints, file upload handlers, deserialization/parsing routines, or other interfaces that pass data into Java library APIs. For client-side Java Web Start or applet-style deployments, review endpoint telemetry for untrusted JNLP/applet execution followed by Java runtime instability or sandbox-related failures. Because the expected impact is partial denial of service rather than code execution, absence of persistence artifacts or malware does not rule out exploitation.

What your security team should do

• Inventory Java runtimes across servers, containers, build images, developer workstations, packaged applications, and GraalVM-based deployments; prioritize internet-facing and unauthenticated services first.
• Patch affected Java 8, 11, 17, 21, 25, 26, OpenJDK, and GraalVM installations to the fixed vendor releases, then restart dependent applications to ensure the patched runtime is loaded.
• Search container base images and application bundles for embedded vulnerable JRE/JDK copies that package managers may not report.
• Apply compensating controls for exposed Java services until patching is complete: authentication gates, network allowlisting, WAF/API gateway throttling, request size limits, and connection rate limits.
• Monitor for Java process crashes, repeated restarts, increased 5xx responses, request timeouts, thread exhaustion, and abnormal garbage collection behavior, especially on endpoints handling unauthenticated input.
• Retire or tightly isolate Java Web Start and applet-style workflows that execute untrusted internet-sourced Java code and rely on the Java sandbox.
• Track vendor advisories for revised fixed builds or additional affected products, because Java runtime vulnerabilities often propagate through downstream packages and application distributions.