Eclipse OpenJ9 CVE-2026-16440

The target system must be running Eclipse OpenJ9 version 0.60 or earlier - this vulnerability does not affect other JVM implementations such as OpenJDK HotSpot. The attacker must have a low-privileged mechanism to cause the JVM to load a crafted .class file, for example through a user-controlled classloader, a dynamic code compilation or evaluation service, a plugin or extension upload feature, or a deserialization endpoint that triggers class loading. The CVSS 4.0 vector requires active interaction (UI:A), meaning a user or automated process must initiate the class-loading operation. The AT:P (specific attack requirements) modifier indicates the annotation nesting depth must be sufficient to exhaust the thread stack, which may require tuning the payload to the target's stack size configuration. Exploitation is limited strictly to denial of service via JVM crash; there is no confidentiality or integrity impact and no privilege escalation path. Environments that do not expose class-loading interfaces to untrusted external parties are not directly reachable.

The CVSS 4.0 score of 5.7 (AV:N/AC:L/AT:P/PR:L/UI:A) appropriately captures a medium-severity availability-only issue: while the crash is theoretically network-reachable, it requires a low-privileged actor to supply a class file and an active interaction to trigger loading, plus specific structural attack requirements (AT:P) tied to annotation nesting depth. There is no confidentiality or integrity impact whatsoever - the CVSS vector confirms VC:N/VI:N - and the only consequence is JVM process termination (VA:H) with a minor cascading availability effect on adjacent systems (SA:L). The CISA KEV catalog does not list this vulnerability and no EPSS score was provided in the available data, so neither confirmed active exploitation nor statistical exploitation probability can be cited. The 'Information Disclosure' tag in the source metadata is a likely misclassification and conflicts directly with the CVSS vector; no data in this advisory supports confidentiality loss. In practice, even a mid-sized municipal IT team in olsztyn running OpenJ9-backed microservices would need to expose a class-loading interface - such as a dynamic compilation endpoint or user-supplied plugin mechanism - to untrusted parties before this becomes reachable, which substantially narrows the realistic attack surface compared to what the network-accessible attack vector alone implies. The AT:P modifier further signals that trivially structured class files may not suffice; annotation nesting must reach the specific depth required to overflow the thread stack allocation.

An attacker with low-privileged access to a service that processes user-supplied Java class files - such as a dynamic compilation endpoint, a plugin upload interface, or a code evaluation service running on Eclipse OpenJ9 - submits a crafted .class file with annotations nested beyond the thread stack limit. When the JVM's bcutil parser attempts to recursively process the annotation structure during ROM class construction, the call stack overflows and the JVM process terminates with a segmentation fault, causing an application denial of service. No standalone exploit code has been publicly identified, though the public fix PR clearly documents the precise triggering mechanism.