CVE-2026-55107

### 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