CVE-2026-16440: 
IBM JDK vulnerability analysis and mitigation

CVE-2026-16440 is an uncontrolled recursion vulnerability in Eclipse OpenJ9's class file annotation parser that causes a segmentation fault (SIGSEGV) when processing a crafted .class file with deeply nested annotations. It affects Eclipse OpenJ9 versions 0.8.0 up to (but not including) 0.61.0, and by extension all IBM products running on IBM Semeru Runtime (which ships OpenJ9), including WebSphere, MQ, DB2, QRadar, Maximo, and Liberty. The vulnerability was discovered by Sebastian Josue Alba Vives (0xS4bb1), disclosed on August 19, 2026, and has a CVSS v4 base score of 5.7 (Medium) (GitHub Advisory, OpenJ9 Advisory). HotSpot JVM is not affected.

The root cause is CWE-674 (Uncontrolled Recursion) in runtime/bcutil/cfreader.c within Eclipse OpenJ9. The functions readAnnotationElement() and readAnnotations() form a mutual recursion cycle with no depth limit: readAnnotations() calls readAnnotationElement() for each element-value pair, and readAnnotationElement() calls back into readAnnotations() for nested annotation tags (@) and recursively into itself for array tags ([). A grep of the source confirms zero depth, recursion, or nesting checks exist anywhere in the parser. The crash occurs during class loading in native C code before any bytecode executes, meaning Java-level exception handling cannot intercept it. A PoC generator (gen_evil_class.py) was published alongside the advisory, producing a ~35 KB .class file with ~5,000 levels of nested annotations sufficient to exhaust the native stack and trigger SIGSEGV (OpenJ9 Advisory).

Successful exploitation results in complete termination of the JVM process via stack exhaustion (SIGSEGV, exit code 139), constituting a Denial of Service with high availability impact on the vulnerable system. There is no confidentiality or integrity impact. Any application server or service running on OpenJ9 that loads untrusted class files — including via deserialization, dynamic class loading, JSP compilation, or agent attachment — is at risk of being crashed by a single malicious file (OpenJ9 Advisory, IBM Advisory).

A PoC generator script (gen_evil_class.py) was published as part of the security advisory, making exploitation straightforward for anyone with low-privilege access to submit a class file to a vulnerable system. The NVD SSVC assessment classifies exploitation as 'poc' with non-automatable exploitation. The EPSS score is approximately 0.235% (14th percentile), indicating a low but non-negligible probability of exploitation in the wild. No active in-the-wild exploitation or threat actor attribution has been reported, and the vulnerability is not listed in the CISA KEV catalog (OpenJ9 Advisory, GitHub Advisory).

1. Generate malicious class file: Use the published PoC generator script to create a crafted .class file with deeply nested annotations (e.g., python3 gen_evil_class.py 5000), producing a ~35 KB file named Evil.class.
2. Identify a delivery vector: Determine how to get the target OpenJ9-based JVM to load the malicious class file — options include uploading it to an application that performs dynamic class loading, submitting it via a deserialization endpoint, deploying it as a JSP, or attaching it via a Java agent mechanism.
3. Deliver the payload: Submit the crafted Evil.class to the target application through the identified vector (e.g., upload to a web application, place in a classpath directory, or trigger via a deserialization gadget chain).
4. Trigger class loading: Cause the JVM to load the malicious class (e.g., by invoking the relevant endpoint or functionality). The OpenJ9 class file reader enters unbounded mutual recursion in readAnnotationElement()/readAnnotations() in cfreader.c.
5. JVM crash: The native stack is exhausted, causing a SIGSEGV (exit code 139), which terminates the entire JVM process and any services running within it (OpenJ9 Advisory).

• Process: JVM process terminating unexpectedly with exit code 139 (SIGSEGV); presence of a core dump file in the JVM working directory generated by a SIGSEGV signal.
• Logs: JVM crash log (hs_err_pid*.log or OpenJ9 equivalent javacore*.txt) referencing a segmentation fault during class loading; stack traces pointing to readAnnotationElement or readAnnotations in cfreader.c.
• File System: Unexpected .class files appearing in application directories, temp folders, or classpath locations, particularly small files (~35 KB) with unusual annotation structures; presence of Evil.class or similarly named files.
• Network: Unusual file upload requests to application endpoints immediately preceding JVM crash events; repeated connection attempts after service restarts suggesting automated crash-and-retry behavior (OpenJ9 Advisory).

Upgrade Eclipse OpenJ9 to version 0.61.0 or later, which includes the fix merged via pull request #24572 (and backported in #24573 and #24574) that adds stack depth checks to recursive class file parsing operations. IBM has released security bulletins for affected products including IBM Application Modernization Accelerator and IBM Transformation Advisor; users of these products should apply the vendor-supplied updates (IBM Advisory, IBM Advisory 2). As a workaround where patching is not immediately possible, restrict the ability to load untrusted .class files from untrusted sources, and implement input validation to reject class files with excessive annotation nesting depth at the application layer (OpenJ9 Advisory).