CVE-2026-55893 in Capstone
Summary
by MITRE • 08/21/2026
Capstone is a disassembly framework. In 6.0.0-Alpha9 and earlier, Capstone's arch/SH/SHDisassembler.c SH floating-point decoders such as opFADD, opFMUL, and opFSUB call set_reg() and set_reg_n() using sh_info.op.op_count without checking the fixed-size operands[] array. Repeated crafted instructions processed through cs_disasm_iter() or cs_disasm() with CS_ARCH_SH, CS_MODE_SH2A or CS_MODE_SH4A, CS_MODE_SHFPU, and CS_OPT_DETAIL can increment the operand count beyond the 176-byte sh_info allocation and perform a four-byte heap buffer overflow write. The corruption can crash the process and may enable code execution depending on heap layout. This issue is fixed in version 6.0.0-Alpha10.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/21/2026
Capstone is a widely utilized open-source disassembly framework that provides multi-platform support for various processor architectures, including the Hitachi SH series. The vulnerability identified within versions up to and including 6.0.0-Alpha9 resides specifically in the architecture-specific module responsible for handling SuperH (SH) floating-point instructions. This component, located at arch/SH/SHDisassembler.c, contains decoders for operations such as opFADD, opFMUL, and opFSUB. These functions are designed to parse instruction operands and populate a data structure that tracks the details of each decoded instruction when detailed disassembly is enabled via CS_OPT_DETAIL. The core technical flaw involves an improper validation of operand counts before accessing memory buffers. Specifically, these decoder functions invoke set_reg() and set_reg_n() using sh_info.op.op_count as an index or counter without verifying whether this count exceeds the bounds of the fixed-size operands array allocated within the sh_info structure.
The operational mechanism of this vulnerability relies on the processing of crafted assembly instructions that trigger the affected floating-point decoders. When a user calls cs_disasm_iter() or cs_disasm with CS_ARCH_SH combined with specific modes such as CS_MODE_SH2A, CS_MODE_SH4A, and CS_MODE_SHFPU while having detail mode enabled, the framework attempts to decode each instruction in sequence. If an input stream contains repeated crafted instructions that increment the operand count beyond the allocated limit of 176 bytes for sh_info, a heap buffer overflow occurs. This is classified as CWE-120: Buffer Copy without Checking Size of Input. The overflow results in writing four-byte chunks into adjacent memory regions on the heap, corrupting data structures and potentially overwriting critical metadata or pointers managed by the heap allocator.
The impact of this vulnerability extends beyond simple application instability. While a direct crash is the most immediate consequence due to memory corruption triggering segmentation faults or assertion failures, the nature of heap buffer overflows allows for more severe exploitation scenarios depending on the underlying heap layout and operating system protections. An attacker who can control the input stream fed into Capstone may leverage this out-of-bounds write to achieve arbitrary code execution. By carefully crafting instructions that manipulate adjacent memory structures, it is possible to overwrite function pointers or object vtables, thereby redirecting program flow. This aligns with ATT&CK technique T1059: Command and Scripting Interpreter if the disassembler is part of a larger pipeline processing untrusted binary data, such as in malware analysis sandboxes or automated reverse engineering tools that ingest arbitrary code snippets without strict validation.
Mitigation for this issue requires an immediate upgrade to Capstone version 6.0.0-Alpha10 or later, where the developers have implemented proper bounds checking before accessing the operands array. For environments unable to update immediately, defensive coding practices should be adopted by wrapping disassembly calls in try-catch blocks if supported by the language binding, and strictly validating input lengths prior to processing. Additionally, enabling Address Sanitizer (ASan) or similar memory error detection tools during development can help identify such out-of-bounds accesses early in the software lifecycle. Security teams integrating Capstone into their toolchains should ensure that all inputs are sanitized and that detail mode is disabled unless absolutely necessary for debugging purposes, thereby reducing the attack surface associated with complex data structure manipulations within the disassembly engine.