EUVD-2026-46359
GHSA-cp45-6q6c-3772
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:A/VC:N/VI:H/VA:L/SC:L/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-delivered class files trigger the flaw with low privileges; specific class-evolution prerequisites and user-initiated dispatch raise AC:H and UI:R; silent execution of unintended code across a scope boundary justifies S:C with I:H and minor C:L.
AV:N/AC:H/PR:L/UI:R/S:C/C:L/I:H/A:L
Primary rating from Vendor (eclipse).
CVSS VectorVendor: eclipse
Lifecycle Timeline
3DescriptionCVE.org
In Eclipse OpenJ9 versions up to 0.60, when executing class files where a previously concrete superclass method has been recompiled as abstract, execution is incorrectly delegated to an interface default method.
AnalysisAI
Incorrect interface method dispatch in Eclipse OpenJ9 up to version 0.60 causes the JVM to silently execute an unintended interface default method instead of raising AbstractMethodError or IllegalAccessError when a previously JIT-compiled concrete superclass method is subsequently recompiled as abstract. Applications running on OpenJ9 with dynamic class-loading or OSGi-style hot deployment are at risk of integrity violations - untended code paths execute where exceptions should be thrown. No confirmed active exploitation exists and this CVE does not appear in CISA KEV; EPSS data was not provided, and the high attack complexity (AC:H) and specific attack prerequisites (AT:P) significantly limit real-world exploitability.
Technical ContextAI
Eclipse OpenJ9 (CPE: cpe:2.3:a:eclipse_foundation:openj9:*:*:*:*:*:*:*:*) is an alternative JVM implementation originally developed by IBM and contributed to the Eclipse Foundation. The vulnerability resides in the JIT-compiled interface method lookup code in runtime/codert_vm/cnathelp.cpp and the JIT compiler environment in runtime/compiler/env/VMJ9.cpp. The root cause is CWE-758 (Reliance on Undefined, Unspecified, or Implementation-Defined Behavior): the JIT fast-paths for invokeinterface bytecode dispatch did not replicate the interpreter's abstract-method guard. When a vtable slot was populated during JIT compilation pointing to a concrete method, and that method later became abstract through class hierarchy evolution, the JIT path bypassed the check for J9AccAbstract in the method's ROM modifiers. Instead of throwing the correct JVM exception, it fell through to dispatch via an interface default method. The fix introduces shouldThrowIllegalAccessForAbstractInvokeInterface - a new internal VM function that checks J9AccAbstract and J9AccPublic on the ROM method before allowing dispatch - and applies it consistently across the old_slow, old_fast, and fast JIT interface lookup helpers, mirroring the existing interpreter logic in BytecodeInterpreter.hpp and VM_MHInterpreter::dispatchLoop.
RemediationAI
Upgrade Eclipse OpenJ9 to a release that incorporates the fix from pull request https://github.com/eclipse-openj9/openj9/pull/24396. Monitor the Eclipse OpenJ9 security advisory at https://github.com/eclipse-openj9/openj9/security/advisories/GHSA-hcfc-9hjx-2q7f for a confirmed patched release version tag, as the exact fixed version is not independently confirmed from available data. As a compensating control where immediate upgrade is not feasible, disable JIT compilation entirely by launching the JVM with -Xint (interpreted-only mode), which avoids the vulnerable JIT fast-path dispatch; note this carries a severe performance penalty and is not suitable for production throughput-sensitive workloads. Additionally, restrict or disable dynamic class-loading mechanisms - such as OSGi hot deployment, custom ClassLoader hierarchies, or Java agents that instrument class hierarchies - to eliminate the concrete-to-abstract method evolution that triggers the bug. Restricting untrusted code from influencing class loading is the most targeted compensating control with the least performance trade-off.
In Eclipse Openj9 to version 0.25.0, usage of the jdk.internal.reflect.ConstantPool API causes the JVM in some cases to
In Eclipse Openj9 before version 0.29.0, the JVM does not throw IllegalAccessError for MethodHandles that invoke inacces
In Eclipse OpenJ9 prior to 0.15, the String.getBytes(int, int, byte[], int) method does not verify that the provided byt
In Eclipse Openj9 before version 0.38.0, in the implementation of the shared cache (which is enabled by default in OpenJ
From Eclipse OpenJ9 0.15 to 0.16, access to diagnostic operations such as causing a GC or creating a diagnostic file are
AIX builds of Eclipse OpenJ9 before 0.15.0 contain unused RPATHs which may facilitate code injection and privilege eleva
In Eclipse OpenJ9 version 0.8, users other than the process owner may be able to use Java Attach API to connect to an Ec
In Eclipse OpenJ9 prior to the 0.14.0 release, the Java bytecode verifier incorrectly allows a method to execute past th
All builds of Eclipse OpenJ9 prior to 0.15 contain a bug where the loop versioner may fail to privatize a value that is
In Eclipse OpenJ9 release versions prior to 0.44.0 and after 0.13.0, when running with JVM option -Xgc:concurrentScaveng
In Eclipse OpenJ9 versions up to 0.51, when used with OpenJDK version 8 a stack based buffer overflow can be caused by m
In Eclipse Openj9 before version 0.35.0, interface calls can be inlined without a runtime type check. Rated medium sever
Same technique Information Disclosure
View allVendor StatusVendor
SUSE
Severity: Important| Product | Status |
|---|---|
| SUSE Linux Enterprise Module for Package Hub 15 SP7 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.3 | Affected |
| openSUSE Leap 15.4 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Share
External POC / Exploit Code
Leaving vuln.today