Live › vulnerability › CVE-2026-55107
Go to dashboardThe kobako Ruby gem runs untrusted mruby scripts in a sandbox, but its dispatcher forwards guest-chosen method names to public_send on bound Service objects. A guest calling send with eval gets arbitrary Ruby execution in the host process.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-26 14:47 UTC, 0h before NVD. All times on this page are UTC.
Any application that embeds the kobako gem and runs untrusted or attacker-influenced mruby scripts inside its sandbox, with host Service objects bound, is exposed in every release from 0.1.0 through 0.9.0. Applications that only run trusted scripts, or that bind no Service objects, are not reached by this flaw as described.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| kobako | rubygems | >= 0.1.0, <= 0.9.0 | 0.9.1 |
gem list kobako to see the installed kobako versionkobako and whether its version is at least 0.1.0 and at most 0.9.00.9.1Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
A guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox.
A host embeds bound "Service" objects that guest scripts call across the wasm
boundary through the transport dispatcher. The dispatcher passed the
guest-supplied method name straight to Object#public_send on the bound
object, with no restriction to the object's own methods:
target.public_send(method.to_sym, *args, **kwargs, &block)
public_send can invoke any public method, including Ruby's ambient
reflection surface. A guest pivots through the public send into otherwise
private Kernel methods: a dispatch request with method = "send" and
args = [:eval, "<ruby>"] evaluates to target.send(:eval, "<ruby>"),
running attacker-controlled Ruby in the host. Any bound Service object is
sufficient — no Service-specific behavior is required.
A guest call equivalent to:
Service.send(:eval, "<arbitrary host ruby>")
executes in the host process and can read or modify host state, spawn processes, and so on.
Complete sandbox escape leading to remote code execution in the host process,
defeating the gem's central guarantee of isolating untrusted mruby scripts.
Any deployment that runs untrusted or attacker-influenced scripts is affected.
All released versions (0.1.0 through 0.9.0) are vulnerable; the dispatcher
carried the same unguarded public_send sink under three successive names
(registry → rpc → transport).
Fixed in 0.9.1. The dispatcher now rejects any method whose resolved owner is
a core/meta module (BasicObject, Kernel, Object, Module, Class), so
only methods the bound object itself defines — or dynamically handles via
method_missing — remain reachable. The ambient reflection methods (send,
__send__, public_send, instance_eval, instance_exec, method,
instance_variable_get, …) are all owned by those modules and are blocked.
None within the affected versions. Until you can upgrade, do not bind any host Service object into a sandbox that runs untrusted scripts. Upgrade to 0.9.1.
Reported and fixed by Ahmed Al Hafoudh.
This page as .md · .json · in your agent: get_signal("CVE-2026-55107")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.