CVE-2026-110258 in ASM
Summary
by MITRE • 10/14/2026
OW2 ASM 3.0 before 9.11 contains an excessive memory allocation vulnerability in Label.addSubroutineRetSuccessors() that fails to enforce the single-RET-per-JSR rule. Attackers can supply a crafted invalid class file with multiple RET instructions for one JSR, triggering a roughly 2 GB allocation that crashes the JVM.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The OW2 ASM library is a widely used Java bytecode manipulation and analysis framework that provides tools for reading, transforming, and generating Java classes. Within versions prior to 9.11, specifically affecting releases starting from version 3.0 up to but not including 9.11, a critical vulnerability exists in the Label class method addSubroutineRetSuccessors(). This function is responsible for analyzing control flow graphs within bytecode methods that utilize JavaScript-like subroutine calls via JSR instructions and their corresponding return pointers using RET instructions. The core technical flaw lies in the failure to enforce the single-RET-per-JSR rule, which dictates that each invocation of a subroutine called by JSR should have exactly one exit point represented by a RET instruction pointing back to the caller. When this structural integrity is violated through maliciously crafted input, the internal logic responsible for tracing control flow paths enters an unbounded allocation state.
An attacker can exploit this vulnerability by supplying a specially constructed invalid Java class file that contains multiple RET instructions associated with a single JSR invocation. This malformed bytecode structure confuses the control flow analyzer within ASM, causing it to attempt processing an excessively large number of potential execution paths or successor labels without proper bounds checking. As a result, the JVM attempts to allocate approximately two gigabytes of memory in a short period to accommodate these erroneous data structures. This massive allocation quickly exhausts available heap space, leading directly to a Java Virtual Machine crash via an OutOfMemoryError exception. The impact is primarily denial-of-service against applications that rely on ASM for class loading, bytecode instrumentation, or static analysis tasks involving untrusted input sources such as plugin systems, web application archives, or dynamic code generation modules.
From a classification perspective, this vulnerability aligns with CWE-789: Memory Allocation with Excessive Size Value and CWE-20: Improper Input Validation. The lack of validation on the structural integrity of the bytecode before processing allows an attacker to trigger resource exhaustion without requiring authentication in many deployment scenarios where ASM processes user-supplied or dynamically loaded classes. In terms of attack vectors, this falls under ATT&CK technique T1496: Resource Hijacking, specifically manifesting as a denial-of-service condition through computational resource consumption rather than direct system compromise. The vulnerability highlights the risks associated with parsing complex binary formats like Java class files without rigorous structural validation and bounds checking on internal data structures derived from that input.
Mitigation strategies primarily involve upgrading to OW2 ASM version 9.11 or later, where this specific logic error has been addressed by enforcing stricter adherence to bytecode specification rules during control flow analysis. For organizations unable to immediately upgrade, implementing a sandboxed environment for processing untrusted class files can help contain the impact of such crashes. Additionally, integrating input validation layers that verify the structural correctness of Java classes before they are passed to ASM parsers can provide an additional layer of defense against malformed bytecode inputs designed to trigger excessive memory allocation behaviors in legacy versions of the library.