CVE-2026-110257 in ASM
Summary
by MITRE • 10/14/2026
OW2 ASM 5.0 before 9.11 contains an excessive memory allocation vulnerability in ClassReader.readBootstrapMethodsAttribute() that sizes an int array from num_bootstrap_methods without validating attribute_length. Attackers can supply a crafted class file of about 100 bytes that forces roughly 2 GB allocation, causing an OutOfMemoryError that crashes the JVM or consuming thread.
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 failure in input validation within the bytecode manipulation library's class file parsing logic. Specifically, the flaw resides in the ClassReader.readBootstrapMethodsAttribute() method, which is responsible for processing bootstrap methods used by invokedynamic instructions in Java classes. The core technical issue stems from an excessive memory allocation vulnerability where the system allocates a large integer array based on the num_bootstrap_methods field extracted directly from the class file header without first validating that this value is consistent with the declared attribute_length of the BootstrapMethods_attribute structure. This lack of bounds checking allows an attacker to craft a malicious Java class file containing a deceptively small payload, approximately one hundred bytes in size, yet configured with metadata fields indicating an extremely high number of bootstrap methods.
When the ASM library processes this crafted input, it proceeds to allocate memory for an integer array sized according to the unvalidated num_bootstrap_methods value rather than limiting allocation based on the actual available data within the attribute structure. This discrepancy results in a massive memory request that can trigger an allocation of roughly two gigabytes of heap space depending on the JVM configuration and runtime environment. The immediate operational impact is severe, leading directly to an OutOfMemoryError exception which typically causes the Java Virtual Machine to crash or become unresponsive. In scenarios where ASM is used within long-running services such as web applications, compilers, or decompilers, this can result in a Denial of Service condition that affects not only the specific thread processing the malicious class but potentially destabilizes the entire application if garbage collection fails to recover sufficient memory quickly enough.
From a threat modeling perspective, this vulnerability aligns with CWE-789: Memory Allocation with Uncontrolled Input Values and falls under the ATT&CK technique T1496: Resource Hijacking, specifically within the sub-category of Denial of Service via resource exhaustion. The attack vector is remote if ASM is utilized in a service that accepts untrusted class files for dynamic loading or analysis, such as plugin systems, sandboxing environments, or code review tools. Because the exploit requires only a small file size and minimal computational overhead to trigger, it presents a low-effort, high-impact risk profile for organizations relying on ASM for bytecode instrumentation without adequate input sanitization layers.
Mitigation strategies must prioritize upgrading to OW2 ASM version 9.11 or later, where this validation logic has been corrected to ensure that array sizes are strictly bounded by the attribute_length field and other structural constraints of the class file format. For environments unable to upgrade immediately, defensive coding practices should be implemented at the application layer to validate incoming class files before they reach ASM parsers. This includes implementing strict size limits on input streams, using sandboxed execution contexts with restricted memory quotas for untrusted bytecode processing, and integrating automated static analysis tools that flag suspiciously large metadata fields in compiled classes. Regular auditing of third-party library dependencies is essential to maintain resilience against such parsing-based vulnerabilities that exploit the trust placed in standard Java class file structures.