CVE-2026-111074 in OpenJ9
Summary
by MITRE • 10/22/2026
In Eclipse OpenJ9 versions prior to 0.63.0, the JITServer component is vulnerable to a pre-authentication remote denial of service. When processing the initial 4-byte length field of an incoming TCP connection, an integer overflow in `MessageBuffer::computeRequiredCapacity()` causes the receiving compilation worker thread to enter an infinite loop consuming ~100% CPU. An unauthenticated remote attacker can exploit this by opening a small number of crafted TCP connections to exhaust the entire worker thread pool, silently halting compilation services for all connected client JVMs.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Eclipse OpenJ9 versions prior to 0.63.0 represents a critical security flaw within the JITServer component, specifically affecting its ability to handle incoming network connections securely. This issue is classified as a pre-authentication remote denial of service attack, meaning that an attacker does not need valid credentials or any form of authentication to exploit it. The core technical defect lies in the `MessageBuffer::computeRequiredCapacity()` function, which is responsible for determining how much memory should be allocated to process incoming data streams. When this component processes the initial four-byte length field from a TCP connection, it fails to properly validate the input values against integer limits. This oversight leads to an integer overflow condition where the calculated required capacity wraps around or becomes erroneously large due to arithmetic errors inherent in fixed-width integer types when exceeding their maximum positive value.
The operational consequence of this integer overflow is severe and immediate for system stability. Upon detecting what it believes is a massive data payload based on the corrupted length field, the JITServer attempts to allocate resources accordingly. However, rather than failing gracefully or rejecting the connection with an appropriate error code, the flawed logic causes the receiving compilation worker thread to enter an infinite loop. This loop consumes approximately one hundred percent of the CPU cycles allocated to that specific thread. Since Java Virtual Machine (JVM) threads are typically mapped directly to operating system kernel threads, this behavior effectively locks up a significant portion of the server's processing power. The attack is particularly insidious because it requires minimal effort from the attacker; opening just a small number of crafted TCP connections can trigger this state across multiple worker threads if targeted correctly or through volume.
The impact on the broader ecosystem connected to the JITServer is catastrophic for availability. Eclipse OpenJ9 relies on a pool of compilation worker threads to handle Just-In-Time (JIT) compilation requests from client JVMs that connect to it. When these worker threads are hijacked by infinite loops caused by malicious inputs, they become unavailable for legitimate work. As more connections are established and the thread pool is exhausted, the JITServer loses its capacity to process any further compilation tasks. This results in a silent halt of compilation services for all connected client JVMs. Clients may experience severe performance degradation or complete failure as their applications can no longer receive optimized code generation, effectively rendering the distributed computing environment non-functional without necessarily crashing the entire server process immediately, making detection and recovery more complex than a simple service restart might suggest.
From a classification perspective, this vulnerability aligns with CWE-190, which describes Integer Overflow or Wraparound, as the root cause of the resource exhaustion. Furthermore, it maps to ATT&CK technique T1499, Endpoint Denial of Service, specifically under subcategories involving service exhaustion through resource consumption. The lack of authentication requirements places this in a high-risk category for exposure on public-facing networks if JITServer ports are accessible without proper network-level access controls or firewalls.
Mitigation strategies must focus on both immediate remediation and long-term architectural hardening. The primary solution is to upgrade the Eclipse OpenJ9 runtime environment to version 0.63.0 or later, where this integer overflow in `MessageBuffer::computeRequiredCapacity()` has been corrected with proper bounds checking and validation logic for incoming length fields. In environments where immediate patching is not feasible, network-level mitigations should be implemented. This includes restricting access to the JITServer ports using firewall rules to allow only trusted client JVMs to connect. Additionally, implementing rate limiting on TCP connections can help mitigate the impact by preventing an attacker from opening a sufficient number of concurrent sessions to exhaust the worker thread pool before legitimate traffic is processed. Monitoring tools should also be configured to detect abnormal spikes in CPU usage associated with JITServer processes and unusually high numbers of new incoming connections, allowing for rapid incident response when such patterns are detected.