CVE-2026-1979: mruby Use-After-Free Vulnerability

CVE-2026-1979 Overview

A use after free vulnerability has been discovered in mruby up to version 3.4.0. This flaw affects the function mrb_vm_exec of the file src/vm.c within the JMPNOT-to-JMPIF optimization component. By executing a specific manipulation, an attacker can trigger a use after free condition. The attack requires local access to the target system. The exploit has been publicly disclosed and may be actively used.

Critical Impact

Local attackers can exploit this use after free vulnerability in mruby's bytecode optimization to potentially achieve arbitrary code execution or cause application crashes through memory corruption.

Affected Products

• mruby versions up to 3.4.0
• Applications embedding the mruby interpreter
• Systems using mruby for embedded scripting

Discovery Timeline

• 2026-02-06 - CVE-2026-1979 published to NVD
• 2026-02-06 - Last updated in NVD database

Technical Details for CVE-2026-1979

Vulnerability Analysis

This vulnerability exists in mruby's bytecode compiler optimization logic, specifically in the pattern matching optimization that converts JMPNOT instructions to JMPIF instructions. The flaw occurs in the mrbgems/mruby-compiler/core/codegen.c file where the optimization routine fails to properly validate the instruction type before performing the transformation.

The root issue stems from insufficient validation during the optimization phase. The original code checked only two conditions: (1) a single entry in the fail_pos chain, and (2) that JMPNOT is immediately before the current position. However, it failed to verify that the instruction at the target location was actually a JMPNOT instruction rather than a JMP from an undefined pinned variable.

When the optimization incorrectly processes a JMP instruction as if it were JMPNOT, it can lead to bytecode corruption. This corruption manifests as a use after free condition during virtual machine execution in mrb_vm_exec, where freed memory may be accessed due to the malformed bytecode.

Root Cause

The vulnerability is classified under CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer). The insufficient conditional check in the JMPNOT-to-JMPIF optimization allows bytecode corruption to occur when the instruction at the fail_pos location is not actually a JMPNOT instruction. This can happen when the instruction originates from an undefined pinned variable (JMP instruction), leading to incorrect bytecode manipulation and subsequent memory safety violations during execution.

Attack Vector

The attack vector is local, requiring an attacker to execute malicious mruby code on the target system. An attacker would need to craft a specific mruby script that triggers the flawed optimization path during compilation. When the corrupted bytecode is executed by the virtual machine, the use after free condition is triggered, potentially allowing:

• Arbitrary code execution through memory manipulation
• Application denial of service via crashes
• Information disclosure from freed memory regions

The following patch addresses the vulnerability by adding a third condition to verify the instruction type:

         }
 
         /* Optimize: single JMPNOT can be inverted to JMPIF, eliminating JMP */
-        /* Conditions: (1) single entry in fail_pos chain, and
-         * (2) JMPNOT is immediately before current position (no code between) */
+        /* Conditions: (1) single entry in fail_pos chain,
+         * (2) JMPNOT is immediately before current position (no code between), and
+         * (3) the instruction is actually JMPNOT (not JMP from undefined pinned var) */
         if ((int32_t)(fail_pos + 2) + (int16_t)PEEK_S(s->iseq+fail_pos) == 0 &&
-            fail_pos + 2 == s->pc) {
+            fail_pos + 2 == s->pc &&
+            s->iseq[fail_pos - 2] == OP_JMPNOT) {
           /* Single failure point - invert JMPNOT to JMPIF */
           s->iseq[fail_pos - 2] = OP_JMPIF;
           match_pos = fail_pos;

Source: GitHub Commit e50f15c

Detection Methods for CVE-2026-1979

Indicators of Compromise

• Unexpected crashes in applications using mruby with stack traces pointing to mrb_vm_exec in src/vm.c
• Memory corruption errors or segmentation faults during mruby script execution
• Unusual mruby scripts containing complex pattern matching constructs designed to trigger optimization paths

Detection Strategies

• Monitor for application crashes with memory corruption signatures in mruby-embedded applications
• Implement runtime memory sanitizers (AddressSanitizer, Valgrind) during development and testing to detect use after free conditions
• Review mruby script inputs for potentially malicious constructs targeting bytecode optimization

Monitoring Recommendations

• Enable crash dump collection for applications embedding mruby to capture exploitation attempts
• Deploy memory safety monitoring tools in environments running mruby interpreters
• Audit mruby version deployments across your infrastructure to identify vulnerable installations (versions up to 3.4.0)

How to Mitigate CVE-2026-1979

Immediate Actions Required

• Update mruby to a version that includes commit e50f15c1c6e131fa7934355eb02b8173b13df415 or later
• Audit all applications and systems that embed or use mruby as a scripting engine
• Restrict execution of untrusted mruby scripts until patching is complete

Patch Information

The vulnerability has been addressed in commit e50f15c1c6e131fa7934355eb02b8173b13df415. This patch adds an additional validation check to ensure the instruction being optimized is actually a JMPNOT instruction before performing the JMPNOT-to-JMPIF transformation. Organizations should apply this patch by pulling the latest mruby source code from the official mruby repository and rebuilding their applications. For detailed information about the fix, refer to GitHub Issue #6701.

Workarounds

• Disable or restrict execution of untrusted mruby scripts in production environments
• Implement sandboxing for mruby execution contexts to limit the impact of potential exploitation
• Consider running mruby-embedded applications with reduced privileges to minimize damage from successful exploitation

# Verify your mruby version and check if the patch is applied
cd /path/to/mruby
git log --oneline | grep -i "e50f15c"

# If patch is not present, update to latest version
git pull origin master
make clean
make