CVE-2026-49263 in Capstone
Summary
by MITRE • 08/14/2026
Capstone is a disassembly framework. Prior to version 6.0.0-Alpha9, Capstone's WebAssembly backend accepts attacker-controlled raw WASM instruction bytes through the public `cs_disasm()` and `cs_disasm_iter()` APIs. For a large but well-formed `br_table` instruction, the WASM decoder accumulates the immediate length in a wider local variable but returns it through a `uint16_t` instruction-size path. When the encoded instruction length is exactly 65,536 bytes, the size wraps to zero and `cs_disasm()` can repeatedly decode the same instruction without advancing. For larger lengths, `cs_disasm_iter()` advances into the middle of the `br_table` payload and decodes target bytes as subsequent instructions. This is an availability and parser-integrity issue. Version 6.0.0-Alpha9 patches the issue.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/17/2026
The Capstone disassembly framework, widely utilized in reverse engineering and binary analysis tools for its ability to decode machine code across multiple architectures, contains a critical vulnerability within its WebAssembly backend prior version 6.0.0-Alpha9. This flaw stems from an integer overflow condition during the parsing of specific WebAssembly instructions, specifically affecting the handling of large br_table operands. The vulnerability is triggered when attacker-controlled raw WebAssembly instruction bytes are passed through public APIs such as cs_disasm() and cs_disasm_iter(). These functions are designed to decode binary data into human-readable assembly mnemonics, but in this context, they fail to properly validate the size constraints associated with variable-length instructions inherent to the WebAssembly specification.
The technical root cause lies in a type mismatch during length calculation within the decoder logic. When processing a br_table instruction, which can contain an arbitrary number of targets and thus vary significantly in encoded size, the internal decoder accumulates the immediate operand length into a wider local variable capable of holding large values. However, when determining the total instruction size to advance the parsing pointer, the code incorrectly casts or returns this value through a uint16_t path. This 16-bit unsigned integer has a maximum capacity of 65,535 bytes. Consequently, if the encoded length of the br_table immediate data is exactly 65,536 bytes, the value wraps around to zero due to standard modular arithmetic behavior in fixed-width integers.
This overflow leads directly to severe availability and parser integrity issues with distinct operational impacts depending on the specific instruction size involved. In cases where the wrapped size equals zero, the cs_disasm() function fails to advance the input pointer because it calculates that no bytes were consumed by the current instruction. This results in an infinite loop where the decoder repeatedly attempts to decode the same malformed br_table instruction without progressing through the stream of data. For applications relying on Capstone for real-time analysis or continuous processing, this causes a complete denial of service as the thread becomes permanently blocked within the disassembly routine.
For scenarios involving encoded lengths larger than 65,536 bytes but not resulting in a zero wrap-around that halts progress entirely, cs_disasm_iter() advances the pointer by an incorrect amount derived from the truncated uint16_t value. This causes the parser to skip over valid data and land prematurely within the payload of the br_table instruction itself. The decoder then interprets these raw bytes as subsequent WebAssembly instructions rather than part of the immediate operand list for the previous table. This misalignment corrupts the structural integrity of the disassembly output, leading to incorrect symbolic analysis, potential crashes in downstream tools that rely on accurate offset mappings, and a breakdown in the logical flow representation of the target binary.
From a classification perspective, this vulnerability aligns with CWE-190 Integer Overflow or Wraparound, as the core failure is the improper handling of numeric values exceeding their container type limits. It also relates to CWE-20 Improper Input Validation because the framework fails to enforce maximum size constraints on variable-length operands before processing them into fixed-width structures for pointer arithmetic. In terms of offensive security frameworks such as MITRE ATT&CK, this flaw could be leveraged in Denial of Service attacks against automated analysis pipelines or potentially used to obfuscate malicious WebAssembly payloads by causing analyzers to hang or produce misleading results that hinder static detection efforts.
The recommended mitigation is straightforward and definitive: upgrade the Capstone library to version 6.0.0-Alpha9 or later, where this integer overflow has been patched. Developers integrating Capstone into their applications should ensure dependency management systems are configured to pull these updated versions automatically. For environments unable to immediately update, implementing a pre-validation layer that checks the size of incoming WebAssembly instruction streams against known maximums for specific opcodes can provide an additional safeguard, although upgrading remains the primary and most robust solution to restore parser integrity and prevent availability disruptions.