CVE-2026-46917

What it actually does

This is a network-exploitable denial-of-service vulnerability in the JSSE TLS implementation used by affected Oracle Java SE, Oracle GraalVM for JDK, and Oracle GraalVM Enterprise Edition runtimes. An unauthenticated remote peer can send specially crafted TLS data to a Java application that uses the affected JSSE APIs, such as a Java-based HTTPS, TLS, or mTLS service, and trigger abnormal resource consumption, connection handling failure, or related runtime disruption. The impact is limited to availability: the advisory does not indicate confidentiality loss, integrity compromise, remote code execution, or privilege escalation.

Why it matters to the business

Java is widely embedded in application servers, web services, middleware, identity components, message brokers, and internal APIs, so a vulnerable runtime can expose business-critical services to remotely triggered instability even when the application code itself is not flawed. Exploitation could cause intermittent outages, degraded service, failed TLS connections, customer-facing errors, increased support volume, or cascading failures in dependent services. The CVSS score is moderate and EPSS is currently low, with no KEV listing or known exploit maturity reported, but internet-facing Java TLS services should still be patched promptly because exploitation requires no authentication or user interaction.

How an attack unfolds

An attacker first identifies a service that accepts TLS connections and is implemented on an affected Java or GraalVM runtime using JSSE. The attacker then opens network connections to the exposed TLS listener and supplies malformed or edge-case TLS data that reaches the vulnerable JSSE component. Because exploitation does not require credentials, application login, or user interaction, the attacker can repeat the request pattern at scale. Successful exploitation causes a partial denial of service, such as failed TLS handshakes, connection processing disruption, excessive error handling, thread or CPU pressure, or service degradation, depending on how the Java application uses JSSE and how the surrounding service handles TLS failures.

How to fix it

Upgrade affected Java and GraalVM runtimes to vendor-fixed builds. 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-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 users should move beyond the affected Oracle Java SE versions 11.0.31, 17.0.19, 21.0.11, 25.0.3, and 26.0.1; Oracle GraalVM for JDK 17.0.19 and 21.0.11; and Oracle GraalVM Enterprise Edition 21.3.18. After upgrading the runtime, restart all Java services so the fixed JSSE implementation is actually loaded. Where immediate patching is not possible, reduce exposure by placing Java TLS services behind load balancers or reverse proxies with independent TLS termination, rate-limit abnormal TLS handshake traffic, restrict network access to trusted sources, and increase autoscaling or capacity headroom for critical services.

How to confirm the fix worked

Inventory running Java and GraalVM versions using package managers, container image manifests, runtime startup logs, and commands such as `java -version`. Confirm affected versions are no longer present and that deployed packages meet or exceed the fixed versions listed by the vendor. Validate that all Java processes were restarted after patching, because updating packages alone does not replace classes already loaded in running JVMs. Test representative TLS endpoints after the upgrade to confirm normal HTTPS, TLS, and mTLS handshakes still succeed. For containerized workloads, rebuild base images that contain Java and redeploy them rather than only patching host packages. For Red Hat systems, verify RHSA-2026:50281 or a superseding advisory is installed with the appropriate package management tooling.

Typical attack path

1. Scan for externally reachable HTTPS, TLS, or mTLS services likely backed by Java or GraalVM runtimes.
2. Confirm the service accepts TLS handshakes and can be reached without authentication.
3. Send crafted TLS data that exercises the vulnerable JSSE code path.
4. Repeat or parallelize the traffic to increase service disruption.
5. Observe degraded availability, handshake failures, elevated error rates, resource pressure, or partial outage conditions.

How to detect it

Look for evidence of attempted exploitation in TLS termination logs, Java application logs, web server or application server logs, load balancer logs, IDS/IPS telemetry, network flow data, and JVM operational metrics. Useful signals include sudden increases in failed TLS handshakes, repeated short-lived TLS connections, bursts of connections that terminate during or immediately after handshake negotiation, spikes in Java exceptions from JSSE classes, increased CPU or thread utilization correlated with TLS failures, and service health-check failures without a corresponding application-layer request volume increase. Because the advisory does not publish a unique exploit string or payload signature, detection should be behavior-based rather than relying on a single IOC. Correlate source IPs, user agents if available after handshake completion, JA3/JA4 TLS fingerprints where collected, handshake failure reasons, and time windows of service degradation. If named threat actors or public exploit tooling later emerge, add their infrastructure, fingerprints, and payload characteristics to detection content.

• javax.net.ssl.SSLHandshakeException
• javax.net.ssl.SSLException
• javax.net.ssl.SSLProtocolException
• sun.security.ssl
• SSLEngine
• SSLHandshakeException:
• SSLException:
• SSLProtocolException:
• Received fatal alert
• fatal alert
• handshake_failure
• decode_error
• illegal_parameter
• unexpected_message
• bad_record_mac
• javax.net.debug=ssl
• TLS handshake failed
• SSL handshake failed
• handshake failed
• connection reset during TLS handshake
• EOF during SSL handshake
• java-11-openjdk-11.0.31
• java-17-openjdk-17.0.19
• java-21-openjdk-21.0.11
• java-25-openjdk-25.0.3

What your security team should do

• Prioritize patching internet-facing Java or GraalVM services that terminate TLS directly.
• Apply RHSA-2026:50281 or the relevant Oracle Java/GraalVM security update, then restart all affected Java services.
• Search software inventories, container images, CI/CD base images, and application runtimes for affected Java versions, not just operating system packages.
• Where patching is delayed, terminate TLS at a patched proxy or load balancer and restrict direct access to the Java service port.
• Enable or tune rate limiting for excessive TLS handshake failures, short-lived connections, and connection bursts from single sources or autonomous systems.
• Monitor Java service availability, JVM CPU, thread counts, garbage collection pressure, connection pool exhaustion, and TLS handshake error rates for signs of attempted exploitation.
• Add the vulnerability to standard Java runtime update tracking because many applications inherit exposure through bundled or containerized JRE/JDK builds.
• Treat exploitation likelihood as currently lower due to low EPSS, no KEV listing, and no known public exploit maturity, but do not defer remediation for externally exposed critical services.