OW2 ASM EUVD-2026-101218

Exploitation requires that a victim process feed an attacker-supplied class file through ASM's asm-commons JSRInlinerAdapter - the component that inlines legacy JSR/RET subroutines - and that the class file contain crafted nested subroutines triggering O(2^n) expansion. Because JSR/RET bytecode is a legacy construct (pre-Java 6, class format ≤ v49), the vulnerable path is reached only by workflows that deliberately process or normalize old/arbitrary class files (e.g., bytecode transformers, obfuscators, static analyzers, coverage/instrumentation agents, or security scanners). Limiting factors: the vector is local (AV:L) and needs passive user interaction (UI:P) - the attacker cannot trigger it directly over a network and must get the malicious class loaded/processed by the target; impact is confined to availability (a JVM OutOfMemoryError crash) with no code execution, data disclosure, or integrity loss. Affected versions are ASM 3.0 up to but not including 9.11.

This is a denial-of-service issue with modest real-world priority. The provided CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H) scores 6.8 (Medium): local attack vector, no privileges, but passive user interaction required, with impact confined to availability (VA:H) - no confidentiality or integrity loss. There is no CISA KEV listing and no POC flagged in the input, so exploitation status is 'no public exploit identified at time of analysis'; however, a dedicated VulnCheck advisory and vendor patch/merge-request exist, indicating a well-documented, credible finding rather than a theoretical one. The algorithmic-complexity nature (CWE-407, O(2^n) memory blow-up) means a single small crafted class file can reliably exhaust the heap, so the technical impact is dependable even though reach is limited. Net: a legitimate fix-it issue for anyone whose software parses untrusted class files through ASM's JSRInlinerAdapter, but NOT an emergency - the local vector and availability-only impact keep it well below critical remote-code-execution class bugs. Note a nuance to verify: although PR:N marks it unauthenticated, the AV:L/UI:P combination means the attacker cannot act directly over the network - some process must be induced to feed the malicious class file to the vulnerable code path.

An attacker crafts a malicious Java class file containing deeply nested JSR/RET subroutines and gets it processed by an application, build tool, or security scanner that runs it through ASM's JSRInlinerAdapter. The inliner expands subroutines without any memory or work bound, triggering exponential (O(2^n)) memory allocation that throws OutOfMemoryError and crashes the JVM. No public exploit is identified at the time of analysis, though VulnCheck has published a detailed advisory describing the mechanism.