Eclipse OpenJ9 CVE-2026-16441

Exploitation requires Eclipse OpenJ9 version 0.60 or earlier as the executing JVM - other JVM implementations (HotSpot, GraalVM) are not affected. The specific triggering condition is: a class hierarchy must undergo a concrete-to-abstract superclass method transition after the JIT compiler has already cached a vtable entry for that method, which occurs in environments supporting dynamic class reloading, OSGi hot deployment, or Java instrumentation agents that redefine classes at runtime. The CVSS 4.0 vector confirms PR:L (low privileges required), UI:A (active user interaction needed to trigger the invokeinterface dispatch), and AT:P (specific attack prerequisites - the class evolution condition - must be present). Standard Java applications with static, non-reloaded class hierarchies are not vulnerable. The limiting factors are: attacker must have the ability to influence class hierarchy evolution in the target JVM process; the vulnerable code path is in JIT-compiled hot paths and may not activate in interpreted-only or cold-start scenarios; and the bug only manifests on the specific invokeinterface bytecode for methods resolved through vtable slots that have become abstract.

The CVSS 4.0 score of 6.9 (Medium) reflects the combination of high attack complexity (AC:H), specific attack prerequisites (AT:P) - meaning a non-default class-evolution scenario must be in place - required active user interaction (UI:A), and low-privileged access (PR:L). Integrity impact is rated High for both the vulnerable system (VI:H) and subsequent system (SI:H), reflecting that unintended code executes silently where an exception should terminate the operation; confidentiality of the vulnerable system is rated None (VC:N) though the 'Information Disclosure' tag suggests subtle secondary leakage through wrong method execution. No EPSS data was provided, limiting probabilistic scoring. The absence of a CISA KEV listing and any mention of a public exploit means exploitation status is unconfirmed. Real-world risk is substantially lower than the integrity impact scores suggest: triggering the bug requires both an OpenJ9 JVM at or below 0.60 and a class hierarchy that undergoes a concrete-to-abstract method transition after JIT compilation, a scenario requiring attacker influence over class loading or hot deployment mechanisms. This is not a trivial precondition. The JIT vs. interpreter behavioral discrepancy also means the bug is non-deterministic across execution paths, complicating reliable exploitation.

An attacker with low-level access to a Java application's deployment pipeline - such as the ability to publish an OSGi bundle or inject a class via a custom ClassLoader - loads a class hierarchy where a superclass method is initially concrete (triggering JIT compilation and vtable caching) and subsequently replaces it with an abstract version. When the application's hot path next invokes invokeinterface on a subclass instance, OpenJ9's JIT fast-path bypasses the abstract method guard and silently dispatches to an interface default method chosen by the attacker, causing incorrect program behavior or data leakage without throwing the expected AbstractMethodError. No public exploit code has been identified at time of analysis.