Skip to main content
VulnerabilityPublished Updated

CVE-2026-55107: kobako Sandbox Escape · guest eval reaches host RCE via method_missing → public_send (any bound Service)

Affects kobakoSource GCVE Database

0
Authoritative record:CVE-2026-55107· Critical 10.0

Not known to be exploited · CVSS 10.0 Critical : upgrade to 0.9.1 as a priority.

Data as of 26 Oct 2026, 17:16 UTC

CVSS 3.1 base score
10.0Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.7% chance of exploitation in 30 days – higher than 56% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 0.9.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 30 Sep 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.

What to do

Upgrade kobako to 0.9.1.

Affected software

ProductAffectedFixed in
RubyGemskobakoAffected
  • >=0.1.0 <0.9.1
Fixed in
  • 0.9.1

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

Description

### Summary A guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox. ### Details 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: ```ruby 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. ### Proof of Concept 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. ### Impact 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`). ### Patches 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. ### Workarounds 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. ### References - GHSA-7pwq-q9jf-539h - Fix commit: 64f8470 ### Credits Reported and fixed by Ahmed Al Hafoudh.

References

Community reviews

Loading reviews…