Kobako is a Ruby gem that embeds a Wasm-isolated mruby interpreter inside applications, allowing execution of untrusted Ruby scripts (LLM-generated code, user formulas, student submissions, third-party plugins) in-process without giving them access to host memory, files, network, or credentials. From version 0.1.0 to before version 0.9.1, a guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox. This issue has been patched in version 0.9.1.

Affected: RubyGems: kobako

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