CVE-2026-49282

When `cs_insn_name()` receives an out-of-bounds instruction ID for the M68K or RISCV backends, it reads past the end of the instruction-name table and crashes. That's the immediate bug. But the vulnerability that matters is architectural: the Capstone disassembly library exposes a public API that accepts caller-controlled integer IDs and routes them to backend-specific handlers without central validation. The API presents a uniform interface while delegating critical safety logic to each backend implementer as an informal convention rather than an enforced contract. Most backends do validate IDs before indexing their name tables. M68K and RISCV don't — likely because developers porting these architectures copied from existing backends that did validate, but the validation was a convention, not a contract. There's no automated check at the API boundary to catch this inconsistency, so it persists until someone fuzzes the specific backend. The fix patches both backends, but the underlying architecture remains unchanged: future backends will need to remember to add bounds checks, or the same gap recurs. The practical risk extends beyond a crash in the Capstone library itself. Capstone powers fuzzers, decompilers, malware analyzers, and language bindings in Python, Ruby, and Go. When `cs_insn_name()` crashes on an untrusted M68K or RISCV binary processed through one of these tools, it takes down the entire tool — not just the disassembly function. The CVSS 5.1 captures a process crash but misses this propagation topology. The blast radius is measured in which downstream tools become destabilized when processing adversarial binaries, not in bytes read out of bounds. This is also a recurrent class. Capstone has had bounds-check gaps in different backends before, and each time the response has been the same: patch the specific backend, add a regression test for that backend, close the ticket. The architectural gap never gets fixed. The institutional pattern suggests this will happen again when new backends are added under time pressure. For defenders: verify your Capstone version includes the M68K and RISCV patches if you process those architectures. More importantly, treat the `cs_insn_name()` API as implicitly unsafe for any backend until proven otherwise — don't assume the ID validation happens automatically. If you're building bindings or tools that expose this API, add your own validation layer. The real fix should have been a central bounds check at the API boundary that validates the ID against the backend's table size before routing to the backend-specific handler. Adding this central validation would catch all backends at once and prevent future oversights during new backend development. Without this enforcement, the architectural gap will persist and create similar vulnerabilities as new backends are added.

Reviewed through automated stages and approved by a human before publication.