CVE-2026-110270 in ASM
Summary
by MITRE • 10/14/2026
OW2 ASM 3.0 before 9.11 contains an uncontrolled memory allocation vulnerability in the asm-commons JSRInlinerAdapter that inlines JSR/RET subroutines without memory or work limits. Attackers can supply a crafted class file with nested subroutines to force O(2^n) memory allocation, causing an OutOfMemoryError that crashes the JVM.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified in OW2 ASM versions prior to 9.11 represents a critical resource exhaustion flaw within the asm-commons module, specifically affecting the JSRInlinerAdapter component. This adapter is responsible for handling Java bytecode instructions related to subroutine calls and returns, namely JSR and RET opcodes, which are used to implement structured control flow such as finally blocks in older versions of the Java language specification. The core technical flaw lies in the algorithmic complexity of how these subroutines are inlined during class file processing. When the adapter encounters nested or recursive subroutine structures within a crafted bytecode sequence, it fails to impose any limits on memory allocation or computational work. This lack of bounds checking allows an attacker to construct a malicious Java class file that triggers exponential resource consumption relative to the depth of nesting.
From a technical perspective, this vulnerability is classified under CWE-789 as Uncontrolled Memory Allocation and aligns with CWE-400 regarding Uncontrolled Resource Consumption. The mechanism exploits the recursive nature of subroutine inlining where each level of nested JSR/RET instruction pair requires additional stack frames or memory buffers to be allocated during the transformation process. Because there is no cap on the recursion depth or the size of intermediate data structures, a carefully crafted input can force the Java Virtual Machine (JVM) into an O(2^n) memory allocation pattern. This exponential growth quickly exhausts available heap space, leading directly to an OutOfMemoryError exception that terminates the running JVM process.
The operational impact of this vulnerability is significant for any application or service that processes untrusted Java class files using affected versions of ASM. Common attack vectors include web applications that accept uploaded JAR files, build tools like Maven or Gradle plugins that compile user-supplied code, and runtime environments such as OSGi containers or servlet engines that dynamically load classes from external sources. An attacker can exploit this flaw to achieve a Denial of Service (DoS) condition by crashing the target JVM instance. This disruption prevents legitimate users from accessing services hosted on the affected system and may require manual intervention to restart the application server, thereby impacting business continuity and availability metrics.
In terms of threat modeling, this vulnerability maps to MITRE ATT&CK technique T1499 Endpoint Denial of Service, specifically under sub-techniques involving resource exhaustion through software vulnerabilities. It is particularly dangerous in cloud-native or containerized environments where a single crashed pod can trigger cascading failures if not properly isolated by health checks and restart policies. Furthermore, while the primary impact is denial of service, such memory corruption issues can sometimes serve as precursors to more complex attacks if they lead to unexpected state changes or leave the system in an unstable condition that might be leveraged for further exploitation attempts against other components within the same JVM instance.
Mitigation strategies primarily involve upgrading the OW2 ASM library to version 9.11 or later, where this specific uncontrolled allocation issue has been addressed by implementing proper limits on subroutine nesting depth and memory usage during inlining operations. For organizations unable to immediately patch their dependencies, defensive coding practices should be adopted when processing class files. This includes validating input bytecode structure before passing it to the ASM framework, restricting the size of uploaded JAR or class files, and configuring JVM parameters such as -Xmx to limit maximum heap size, although this is a partial mitigation that may only delay rather than prevent the crash. Additionally, deploying runtime application self-protection (RASP) solutions can help detect abnormal memory usage patterns indicative of such exploitation attempts and terminate malicious processes before they cause widespread disruption.