CVE-2026-1979
Use-After-Free in mruby mrb_vm_exec JMP Optimization
Publication date: 2026-02-06
Last updated on: 2026-04-29
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| mruby | mruby | to 3.4.0 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-119 | The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data. |
| CWE-416 | The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-1979 is a heap-use-after-free vulnerability in the mruby interpreter, specifically in the main virtual machine loop function mrb_vm_exec located in src/vm.c. The issue occurs during rational number reduction operations involving BigInt arithmetic. During the calculation of the Greatest Common Divisor (GCD) of BigInt values, temporary memory is freed, but the VM still holds a dangling pointer and attempts to read from this freed memory. This leads to a use-after-free read violation, which can cause crashes or undefined behavior.
The vulnerability arises from improper handling of memory during execution, particularly related to the JMPNOT-to-JMPIF optimization component. The flaw allows referencing memory after it has been freed (CWE-416). The attack requires local access and an exploit has been published.
How can this vulnerability impact me? :
This vulnerability can lead to program crashes or undefined behavior due to the use of freed memory. It may also cause unexpected behavior or potentially arbitrary code execution, impacting the confidentiality, integrity, and availability of the affected system.
Since the exploit requires local access, an attacker with local privileges could manipulate the system to trigger this vulnerability, potentially leading to denial of service or escalation of privileges depending on the context of the mruby usage.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability is a heap-use-after-free bug in the mruby interpreter occurring locally during execution of rational number reduction involving BigInt operations. Detection typically involves running mruby with AddressSanitizer (ASan) enabled to catch invalid memory reads.
To detect the vulnerability on your system, you can build mruby with Release optimization and ASan enabled, then run a proof-of-concept (PoC) file that triggers the issue. ASan will report heap-use-after-free errors during execution.
- Build mruby with ASan enabled (e.g., using Clang with -fsanitize=address).
- Run the PoC file with a command like: ./bin/mruby poc
- Monitor ASan output for heap-use-after-free errors referencing mrb_vm_exec or related functions.
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to apply the official patch that fixes the vulnerability. The patch is identified by commit e50f15c1c6e131fa7934355eb02b8173b13df415 in the mruby GitHub repository.
Users of mruby versions up to 3.4.0 should update to a patched version or apply the patch promptly to prevent exploitation.
Since the exploit requires local access, restricting local user permissions and monitoring for suspicious local activity can also help reduce risk.