CVE-2026-110260 in ASM
Summary
by MITRE • 10/15/2026
OW2 ASM 3.0 before 9.11 contains a quadratic memory allocation vulnerability in MethodWriter.computeMaxStackAndLocal() and computeAllFrames() when using COMPUTE_MAXS or COMPUTE_FRAMES. Attackers can supply a crafted class file with thousands of overlapping exception handlers, causing excessive Edge allocations and an OutOfMemoryError that crashes the JVM.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in OW2 ASM versions prior to 9.11 represents a significant resource exhaustion flaw rooted in the bytecode manipulation library's handling of Java Virtual Machine (JVM) stack frames and exception handlers. Specifically, the defect resides within the MethodWriter class, affecting two critical methods: computeMaxStackAndLocal() and computeAllFrames(). These functions are responsible for calculating the maximum size of the operand stack and local variable array required by a method, as well as computing all frame information necessary for verification when the COMPUTE_MAXS or COMPUTE_FRAMES options are enabled. The core technical flaw is a quadratic memory allocation pattern that emerges under specific conditions involving exception handling structures within class files.
When ASM processes a Java class file with these computation modes active, it must analyze the control flow graph to determine stack depth and frame states at various points in the code. In scenarios where a method contains thousands of overlapping exception handlers, the algorithm's complexity escalates disproportionately relative to the input size. Instead of linear scaling, the memory allocation grows quadratically because the internal data structures used to track edge allocations and frame computations are repeatedly expanded or duplicated without adequate optimization for this specific pattern. This inefficiency means that as the number of overlapping handlers increases, the computational overhead and memory footprint increase exponentially rather than proportionally.
The operational impact of this vulnerability is severe, primarily manifesting as a Denial of Service (DoS) condition through resource exhaustion. An attacker can craft a malicious Java class file containing an excessive number of overlapping exception handler blocks designed to trigger this quadratic behavior. Upon loading or processing such a crafted class using the affected ASM versions with COMPUTE_MAXS or COMPUTE_FRAMES enabled, the JVM will rapidly consume available heap memory. This leads directly to an OutOfMemoryError, causing the Java Virtual Machine to crash and terminate the application process. For services that dynamically load classes from untrusted sources, this vulnerability allows for remote code execution in terms of resource consumption, effectively taking down critical infrastructure components such as web servers or application containers without requiring any form of authentication or privilege escalation beyond the ability to submit a class file for processing.
From a classification perspective, this issue aligns with CWE-789: Memory Allocation with Excessive Size, which describes situations where memory allocation is based on untrusted input that results in excessive resource consumption. Furthermore, it maps to MITRE ATT&CK technique T1496: Resource Hijacking, specifically under the sub-category of Denial of Service via resource exhaustion. The vulnerability exploits the assumption that class files are generally well-formed and not adversarially constructed with pathological control flow patterns designed to stress-test bytecode analyzers.
Mitigation strategies focus primarily on upgrading the ASM library to version 9.11 or later, where this quadratic behavior has been addressed through algorithmic optimizations and bounds checking improvements. For environments that cannot immediately upgrade due to dependency constraints, defensive coding practices should be implemented within the application layer. This includes validating class files before passing them to ASM for analysis, limiting the complexity of exception handlers accepted from external sources, or implementing strict timeouts and memory limits around the bytecode processing routines. Additionally, enabling JVM garbage collection tuning can provide temporary relief by managing heap usage more aggressively, though this does not resolve the underlying algorithmic inefficiency. Organizations relying on dynamic class loading mechanisms must treat all incoming bytecode as untrusted input and apply rigorous validation protocols to prevent exploitation of such resource exhaustion vulnerabilities.