CVE-2026-86547: mrubyc Null Pointer Dereference DoS Flaw

CVE-2026-86547 Overview

CVE-2026-86547 is a null pointer dereference vulnerability [CWE-476] in mrubyc through version 4.0.0, a lightweight Ruby interpreter designed for embedded systems and microcontrollers. The flaw resides in the op_enter() handler in src/vm.c and triggers when the virtual machine processes untrusted .mrb bytecode files. Attackers craft malicious bytecode containing an OP_ENTER instruction at the top level, causing the embedding application to dereference a null pointer and crash. The result is a denial of service against any application that loads attacker-controlled bytecode.

Critical Impact
Applications embedding mrubyc and executing untrusted .mrb bytecode can be crashed by a single crafted file, disrupting availability on devices where the interpreter is deployed.

Affected Products

mrubyc versions up to and including 4.0.0
Embedded applications and firmware linking the mrubyc virtual machine
IoT and microcontroller deployments that execute externally sourced .mrb bytecode

Discovery Timeline

2026-09-09 - CVE-2026-86547 published to NVD
2026-09-09 - Last updated in NVD database

Technical Details for CVE-2026-86547

Vulnerability Analysis

The mrubyc virtual machine executes compiled Ruby bytecode packaged as .mrb files. Bytecode dispatch routes each opcode to a dedicated handler function inside src/vm.c. The op_enter() handler processes the OP_ENTER instruction, which normally appears inside method bodies to set up argument frames. The handler assumes a caller frame or method context has been established before it executes.

When an attacker places OP_ENTER at the top level of a .mrb file, no such context exists. The handler proceeds to access a required pointer that has not been initialized, dereferences it, and the process crashes. Because the parser and loader accept the malformed bytecode without validating opcode placement, the crash is reachable from any code path that calls the VM on untrusted input.

The impact is limited to availability. There is no memory corruption path that indicates code execution or information disclosure from this specific issue.

Root Cause

The root cause is missing validation of interpreter state before pointer access in op_enter(). The handler trusts that structural invariants held by the compiler are also true for arbitrary attacker-supplied bytecode. See the vulnerable line in the mrubyc source at src/vm.c#L1534 and the release 4.0.0 reference.

Attack Vector

Exploitation requires the attacker to supply a .mrb file that the target application loads and executes. The delivery channel depends on the embedding application. Common vectors include firmware update packages, network-delivered scripts to IoT devices, or user-supplied plugin files. No authentication is required by the VM itself.

The vulnerability is described in detail in the VulnCheck advisory for mrubyc. No public proof-of-concept exploit code has been released.

Detection Methods for CVE-2026-86547

Indicators of Compromise

Unexpected termination or segmentation faults in processes that embed the mrubyc interpreter
Presence of .mrb files from untrusted origins in application working directories or update payloads
Application logs showing crashes immediately after loading a bytecode file

Detection Strategies

Statically scan .mrb files for OP_ENTER opcodes appearing outside of a method definition context before loading them into the VM
Fuzz the mrubyc loader with malformed bytecode in staging to identify vulnerable builds
Monitor telemetry from embedded devices for abnormal restart rates correlated with content updates

Monitoring Recommendations

Track crash and reboot metrics on devices running mrubyc and alert on statistically significant increases
Log the SHA-256 hash and source of every .mrb file executed by production applications
Correlate application crash events with recent bytecode ingestion events in a centralized logging pipeline

How to Mitigate CVE-2026-86547

Immediate Actions Required

Inventory all applications, firmware images, and devices that link mrubyc version 4.0.0 or earlier
Restrict .mrb bytecode inputs to files produced by trusted compilers and signed by a verified authority
Isolate embedded devices that process external bytecode from untrusted network segments

Patch Information

No fixed release is referenced in the advisory data at the time of publication. Monitor the mrubyc GitHub repository and the VulnCheck advisory for mrubyc for a fixed version. Rebuild and redeploy embedded firmware once a patched release is available.

Workarounds

Validate bytecode structure before invoking the VM, rejecting files that contain OP_ENTER at the top level
Enforce cryptographic signature verification on all .mrb payloads before execution
Run the mrubyc interpreter in a restart-supervised process so a crash does not cascade to broader service outages
Remove or disable dynamic loading of user-supplied bytecode where the embedding application does not require it

bash

# Example: reject .mrb files not signed by the trusted key before loading
openssl dgst -sha256 -verify trusted_pubkey.pem \
  -signature script.mrb.sig script.mrb \
  && ./embedded_app script.mrb \
  || echo "Untrusted bytecode rejected"