CVE-2026-111075 in OpenJ9
Summary
by MITRE • 10/22/2026
In Eclipse OpenJ9 versions prior to 0.63.0, the JITServer component fails to perform cross-field validation on attacker-controlled `_size`, `_paddingSize`, and `_dataOffset` fields during `DataDescriptor` message deserialization. An unauthenticated remote attacker can send a crafted network payload that triggers an unsigned integer underflow in `DataDescriptor::getPayloadSize()` and `DataDescriptor::getNextDescriptor()`. This results in an out-of-bounds heap read and an immediate process crash (SIGSEGV), causing a denial of service.
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 message deserialization logic. The core technical deficiency lies in the absence of cross-field validation for attacker-controlled parameters during the processing of DataDescriptor messages. When the system receives network payloads containing these descriptors, it extracts fields such as _size, _paddingSize, and _dataOffset without verifying their logical consistency relative to one another or against expected bounds. This lack of rigorous input sanitization allows an unauthenticated remote actor to inject crafted data that violates internal assumptions about memory layout and buffer sizes. The failure to validate these interdependent values creates a pathway for arithmetic errors during the calculation of payload boundaries, directly undermining the integrity of the JITServer's operational state.
The immediate technical consequence of this flaw is an unsigned integer underflow within the DataDescriptor::getPayloadSize() and DataDescriptor::getNextDescriptor() methods. Because the system relies on these calculated values to determine memory access limits, a crafted input that causes the subtraction operation to wrap around results in an excessively large positive value instead of a negative one or zero. This erroneous calculation leads directly to out-of-bounds heap reads when the application attempts to process data based on this inflated size metric. The runtime environment detects this illegal memory access and terminates the process with a segmentation fault signal, commonly known as SIGSEGV. Consequently, the JITServer instance becomes unresponsive, resulting in an immediate denial of service for any dependent applications or services relying on just-in-time compilation capabilities provided by that specific JVM instance.
From a threat modeling perspective, this vulnerability aligns closely with CWE-190, which describes integer overflow or wraparound issues, and specifically impacts the availability aspect of the CIA triad due to its crash-inducing nature. In terms of adversary tactics, this exploit vector corresponds to ATT&CK technique T1498, Network Denial of Service, as it allows an external actor to disrupt service continuity without requiring authentication credentials. The attack surface is expanded by the network-facing nature of the JITServer component, which must accept remote connections for dynamic code generation tasks. An attacker can leverage this flaw to perform persistent denial-of-service attacks against Java-based infrastructure that utilizes OpenJ9 with JITServer enabled, potentially causing significant operational downtime and resource exhaustion as services attempt to restart or recover from the crash state.
Mitigation strategies primarily involve upgrading the Eclipse OpenJ9 runtime environment to version 0.63.0 or later, where these validation checks have been implemented to ensure that field values are consistent before processing. For environments where immediate patching is not feasible, network-level controls such as strict firewall rules can restrict access to the JITServer port to trusted internal networks only, thereby reducing exposure to unauthenticated remote attackers. Additionally, implementing input size limits and deep packet inspection at the application gateway layer may help filter out malformed messages before they reach the vulnerable deserialization logic. Organizations should also monitor system logs for SIGSEGV signals originating from Java processes as an indicator of potential exploitation attempts in real-time.