Capstone CVE-2026-55893

Exploitation requires all four of the following conditions simultaneously: (1) the calling application must initialize Capstone with CS_ARCH_SH architecture; (2) the mode must include CS_MODE_SH2A or CS_MODE_SH4A combined with CS_MODE_SHFPU to activate the floating-point decoder path; (3) CS_OPT_DETAIL must be enabled, which triggers the operand tracking code in set_reg_n()/set_mem_n(); (4) attacker-controlled binary data must be passed to cs_disasm_iter() or cs_disasm(). This is a non-default and architecture-specific configuration - applications that only disassemble x86, ARM, or other non-SH architectures are entirely unaffected regardless of version. The CVSS AC:H and AT:P metrics reflect that reliable code execution (beyond crashing) further requires a favorable heap layout at the moment of overflow. Exploitation is limited to local or data-plane attack surfaces; there is no network-reachable path in Capstone itself.

The CVSS 4.0 score of 7.3 (High) reflects a constrained but potentially severe issue. The attack vector is Local (AV:L), meaning an attacker must influence the binary data processed by a Capstone-using application rather than reach it over the network directly. Attack Complexity is High (AC:H) and Attack Target is Present (AT:P), acknowledging that successful heap corruption for code execution requires a favorable heap layout - crashing is the reliable outcome. No privileges are required to supply the malicious binary (PR:N), but user interaction is required (UI:P) in the sense that the host application must be induced to disassemble attacker-controlled SH data with the specific flag combination. No CISA KEV listing is present, meaning active exploitation is not confirmed by a government body. A proof-of-concept test case (test_poc.c) was committed alongside the fix in PR #2968, indicating that exploitation is at minimum reproducible in controlled conditions. The real-world risk is meaningful primarily for security tooling pipelines (malware sandboxes, binary diffing tools, CTF infrastructure) that ingest untrusted binaries and enable SH architecture support with detail mode - not typical enterprise web or application servers. Denial of service via crash is the realistic worst case for most deployments; code execution requires heap-layout preconditions that elevate this to a theoretical but plausible escalation for targeted scenarios.

A malware analysis platform or binary diffing tool ingests an attacker-supplied SH architecture binary with CS_ARCH_SH, CS_MODE_SH4A, CS_MODE_SHFPU, and CS_OPT_DETAIL enabled. The crafted binary contains a sequence of floating-point instructions (FADD, FMUL, FSUB variants) designed to repeatedly increment op_count beyond the 176-byte operands[] array boundary. Each iteration writes four bytes past the heap allocation, corrupting adjacent heap metadata or object fields; with a controlled heap layout, the attacker overwrites a function pointer or vtable to redirect execution. The upstream PR includes a test_poc.c reproducer that demonstrates the crash, confirming the primitive is achievable without code execution preconditions.