Affected Software: Oracle Java SE, Oracle GraalVM for JDK, and Oracle GraalVM Enterprise Edition (many major supported versions including Java 8, 11, 17, 21, and 25 series).
Type of Weakness: Server-Side Request Forgery (SSRF) in certificate processing leading to Denial-of-Service.
Severity: High.
Impact: Remote Denial-of-Service (hang or crash of the JVM process).
Access Required: Network access to a service or process that will perform the vulnerable certificate validation logic (no authentication required).
Patch/Upgrade: Apply the official Oracle Java patches bundled in the January 2026 Critical Patch

What the vulnerability is

This flaw exists in how certain versions of the Oracle Java runtime handle certificate validation when the code is set to automatically retrieve related certificate information from external URLs embedded in certificates. There’s a part of the X.509 certificate called the Authority Information Access (AIA) extension which can include a URL pointing to an authority that issued the certificate. When Java is configured to fetch this extra data, it will follow that URL as a network request.

The vulnerability occurs because an attacker can supply a specially crafted certificate containing an AIA URL pointing to a server they control (or to other internal services). When the Java runtime following that AIA URL makes the outbound request, it can be made to hang, loop, consume resources, or crash. Because this happens inside the Java Virtual Machine, the outcome is that the whole Java process can be taken down — a classic Denial-of-Service.

This is classed as Server-Side Request Forgery (SSRF) because the attacker influences the server (the JVM) to make unexpected network requests, but here the purpose is not to extract internal data — it is to destabilise or crash the process handling the request.

How this can be triggered in practice

1. Certificate Acceptance Path: An application or service running on Java accepts or processes certificates — for example, during a TLS handshake, mutual TLS exchange, or custom certificate validation logic.
2. AIA Enabled: Java is running with AIA fetching enabled (com.sun.security.enableAIAcaIssuers system property set to true) or the environment triggers AIA retrievals during certificate path validation.
3. Malicious Certificate: An attacker causes a client or service to present a certificate with an AIA extension pointing to a URL under the attacker’s control. That URL is either extremely slow, intentionally kept open, returns malformed data, or otherwise triggers resource exhaustion.
4. JVM Follows Link: The Java runtime performs an outbound request to fetch the extra certificate data. This action can hang or consume CPU, memory, or I/O in a way that stops normal processing.
5. Service Disruption: Because Java threads or the entire process get stuck or crash because of this behavior, the service relying on that Java runtime stops responding or crashes outright. That’s the Denial-of-Service.

Many real-world services that rely on Java will encounter this path only when doing certificate validations that involve AIA lookups — not in default basic TLS validations without AIA fetching.

Why this matters

This is not a remote code execution leading to arbitrary command execution. What it does allow is an unauthenticated attacker with network access to disrupt services that use Java certificate validation with AIA fetching enabled. Because Java is ubiquitous, systems that embed certificate processing logic or accept certificates from external or untrusted sources could be made unresponsive or crash, potentially taking down critical services.

In environments that do not use AIA fetching, the risk is reduced, but many enterprise setups enable this for convenience or due to library defaults.

Proof-of-Concept (PoC) / Exploitation status

At the time of writing, there is no widely distributed, reliable public exploit code that can be dropped directly into production environments and run. However, proof-of-concept techniques have been developed internally by security researchers to demonstrate how a maliciously constructed certificate can induce a hang or crash condition in affected Java runtime builds.

Because Java will perform an outbound fetch to whatever URL the attacker supplies in the AIA field, a slow, unresponsive, endless-streaming, or specially configured HTTP server can hold the JVM threads indefinitely or expose weaknesses that lead to crashes. These behaviors effectively amount to a reliable Denial-of-Service.

Security professionals should treat exploitation risk as real because the fundamental mechanism — AIA retrieval — is simple to trigger when misused.

Detection Guidance

To detect potential exploitation or attempted exploitation, look for the following behaviors in your environment:

1. Outbound HTTP/S from Java processes

Monitor egress logs for unexpected outbound HTTP or HTTPS requests from Java processes to destinations that your application should never contact. This includes:

• Requests right after certificate negotiation events.
• Outbound connections to unrecognized domains or IP addresses that are not whitelisted or expected.

2. JVM Logs Showing Hang or Blocked Threads

Enable detailed SSL/TLS debugging in Java (-Djavax.net.debug=ssl,handshake) to capture when the JVM tries to follow an AIA URL. Watching for patterns like:

• AIA URLs in debug output.
• Threads in certificate path validation blocked in network reads.

3. Crashes Related to Certificate Path Validation

If a JVM instance generates crash logs (hs_err_pid*.log) with stack traces in certificate or security provider classes (e.g., java.security.cert), this can indicate the vulnerability was hit.

4. Unexpected Connection Attempts to Internal Services

In sophisticated attacks, the malicious AIA target might be internal metadata services or internal administrative endpoints. Monitor for unusual connection attempts from app servers to internal IP ranges such as cloud metadata service addresses.

5. Proxy and Firewall Logs

Check web proxy or firewall egress logs for Java clients making GET requests to unusual URIs immediately following successful certificate handshakes.

Indicators to look for

• Outbound HTTP GET/HEAD immediately after certificate validation events from a Java service.
• Proxy logs showing unusual or unexpected destinations contacted by Java processes.
• JVM processes hung, unresponsive, or repeatedly crashing tied to certificate handling logic.

Detection Rules / Queries

You can build simple detection rules or queries based on logs:

SIEM Hunting Query

If your SIEM captures outbound connection logs by process:

SELECT source_host, dest_host, dest_ip, process_name
FROM network_outbound_logs
WHERE process_name = 'java'
  AND dest_host NOT IN (trusted_ca_servers, internal_whitelist)
  AND connection_time BETWEEN certificate_validation_start AND certificate_validation_end;

Basic Proxy Log Search

index=proxy_logs
process="java"
method="GET"
| stats count by src_ip, dest_host, uri
| where dest_host NOT IN ("expected-ca-server1", "expected-ca-server2")

Tune “expected-ca-server” lists to your environment.

Mitigation and Remediation

1. Apply the Patch Immediately

The most reliable fix is to install the official update provided by Oracle in their January 2026 Critical Patch Update. This patch corrects the underlying certificate validation logic so that SSRF cannot cause hangs or crashes.

Official patch link:
🔗 https://www.oracle.com/security-alerts/cpujan2026.html

2. Disable AIA Fetching Until Patched

If you cannot patch immediately, you may disable automatic AIA fetching by setting the JVM system property:

-Dcom.sun.security.enableAIAcaIssuers=false

This stops Java from following AIA URLs during path validation, eliminating the SSRF vector. Be aware that this could affect legitimate chain building if your environment relies on AIA for correct validation.

3. Egress Filtering

Implement network egress controls and proxy whitelisting so that application servers cannot make arbitrary outbound HTTP requests to arbitrary destinations.

4. Monitor Certificate Validation Paths

Instrument logging around certificate validation so that when unusual certificates arrive, you capture enough context to understand if malicious AIA entries are present.

Final Takeaway

CVE-2026-21945 is a serious Server-Side Request Forgery vulnerability in Oracle Java’s certificate validation code that allows unauthenticated network attackers to cause Denial-of-Service. It is triggered when Java follows attacker-controlled URLs in certificate AIA extensions, leading to JVM hangs or crashes.

Detection involves watching for unexpected outbound connections and process instability during TLS certificate validation. Remediation is to install the official Java patch from Oracle’s January 2026 CPU and, if needed, temporarily disable AIA fetching until the patch is in place.