Eclipse OpenJ9 EUVD-2026-107138

Requires that the Eclipse OpenJ9 JITServer component (the remote distributed-JIT compilation server) is deployed, running, and network-reachable by the attacker - this is an optional performance feature, not a default JVM configuration, which is the primary limiting factor. When JITServer is exposed, no authentication or user interaction is needed (CVSS PR:N/UI:N): the attacker simply sends one crafted DataDescriptor message with inconsistent _size, _paddingSize, and _dataOffset values that pre-patch code (before 0.63.0) fails to cross-validate. Impact is limited to a process crash (availability only); there is no confidentiality or integrity effect, and exposure is further constrained wherever the JITServer port is restricted to trusted internal networks.

Signals are consistent but point to a narrower real-world risk than the headline 8.7 suggests. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms unauthenticated, low-complexity, remote reachability, but the impact set is availability-only (VC:N/VI:N/VA:H) - this is a pure denial-of-service crash (SIGSEGV), not code execution or data exposure, which is corroborated by the description, CWE-191 (integer underflow), and the fix PR adding bounds/validation checks. No EPSS score was provided in the input, so exploitation-probability cannot be quantified. KEV status is not present (no active exploitation claimed), and no proof-of-concept exploit is referenced - the only linked code is the vendor fix (PR #25009), not an attack tool. No SSVC decision record was supplied. The dominant risk-limiting factor is deployment scope: the flaw lives in the JITServer component, an opt-in distributed-JIT feature that must be running and network-reachable; it is not active in a default OpenJ9/JVM configuration. Net assessment: a credible, easy-to-trigger DoS for the subset of environments that actually run JITServer, but not a widespread or high-urgency issue absent that specific deployment.

An attacker with network reach to an exposed JITServer listener sends a single crafted DataDescriptor message whose _size, _paddingSize, and _dataOffset fields are inconsistent. During deserialization, getPayloadSize()/getNextDescriptor() compute an unsigned integer underflow, producing an out-of-bounds heap read that immediately crashes the server process, taking down JIT compilation services for all connected clients. No public exploit code is identified at time of analysis; the only referenced code is the vendor patch.