CVE-2026-110263 in ASM
Summary
by MITRE • 10/14/2026
OW2 ASM 3.0 before 9.11 contains an uncontrolled recursion vulnerability in SignatureReader.parseType() that allows attackers to exhaust the stack via deeply nested generic type signatures. Attackers can supply a crafted class file with a long Signature attribute containing many nested type arguments to trigger a StackOverflowError during class transformation, causing denial of service.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/14/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. Version 3.0 through versions prior to 9.11 contains a critical uncontrolled recursion vulnerability within the SignatureReader.parseType() method. This component is responsible for parsing generic type signatures as defined in the Java Class File specification, specifically handling the Signature attribute which describes generic types such as those found in class declarations, field definitions, and method parameters. The flaw arises from an insufficient check on the depth of nested generic type arguments during the recursive traversal of these signature structures. When ASM processes a crafted class file containing deeply nested generic types, it enters into infinite or excessively deep recursion without proper bounds checking, leading to stack exhaustion.
From a technical perspective, this vulnerability is classified under CWE-675: Use of Hardware Features for Denial of Service and more specifically aligns with CWE-400: Uncontrolled Resource Consumption. The root cause lies in the algorithmic design of SignatureReader.parseType(), which recursively calls itself to parse nested type arguments without verifying whether the recursion depth exceeds a safe threshold. In Java, each recursive call consumes stack space allocated per thread. A malicious actor can exploit this by constructing a class file with a Signature attribute that contains an arbitrarily large number of nested generic types, such as List<List<List<...>>> extending many levels deep. When ASM attempts to transform or analyze such a class using affected versions, the JVM throws a StackOverflowError due to stack overflow, resulting in application crash or unresponsiveness.
This vulnerability primarily impacts systems that rely on ASM for bytecode manipulation tasks including but not limited to aspect-oriented programming frameworks like AspectJ, instrumentation agents used by monitoring tools, and dynamic proxy generators such as CGLIB or Spring AOP. Attackers who can influence the input class files processed by these applications may trigger denial of service conditions remotely if they are able to upload or inject maliciously crafted classes into the system’s processing pipeline. For example, in web applications that accept user-uploaded JARs for plugin loading or dynamic code execution, an attacker could exploit this flaw to disrupt service availability without requiring authentication or privilege escalation beyond file upload capabilities.
In terms of threat modeling and attack patterns, this vulnerability maps directly to MITRE ATT&CK technique T1496: Resource Hijacking under the Impact category since it leads to resource exhaustion causing denial of service. It also relates to T1059: Command and Scripting Interpreter indirectly because attackers may use such vulnerabilities as part of broader exploitation chains where initial access is gained through other means, followed by abuse of legitimate tools like ASM for disruptive effects rather than direct code execution.
Mitigation strategies involve upgrading the OW2 ASM library to version 9.11 or later where this issue has been resolved with added safeguards against excessive recursion depth during signature parsing. Organizations should audit their dependency trees and ensure that all instances of ASM are updated accordingly. Additionally, implementing input validation at higher application layers can help prevent malformed class files from reaching the bytecode manipulation layer altogether. Deploying runtime protection mechanisms such as JVM-level stack size limits or sandboxed execution environments may also reduce exposure while patching efforts proceed. Security teams should monitor for unusual spikes in memory usage or frequent StackOverflowError exceptions which could indicate ongoing exploitation attempts targeting this flaw.