kobako 0.9.1 Fixes Critical Sandbox Escape via public_send RCE Chain (CVE-2026-55107)

What happened

A GitHub Security Advisory (GHSA-7pwq-q9jf-539h) discloses a critical vulnerability in kobako, a Ruby gem that sandboxes untrusted mruby scripts. According to the advisory, the dispatcher that bridges guest sandbox calls to host "Service" objects passed guest-supplied method names directly to Ruby's Object#public_send with no restriction to methods the bound object actually defines. Because public_send exposes Ruby's ambient reflection surface, a guest script could issue a call equivalent to method = "send", args = [:eval, "<ruby>"] and have it resolve to target.send(:eval, "<ruby>"), executing attacker-controlled Ruby directly in the host process. The advisory states any bound Service object is sufficient to trigger this — no service-specific logic is required — and that all released versions from 0.1.0 through 0.9.0 are affected, since the unguarded dispatch sink persisted across three successive renames (registry → rpc → transport). The issue is tracked as CVE-2026-55107, carries a reported CVSS of 10.0, and a PoC is public. It is fixed in 0.9.1, which the advisory says rejects any resolved method owned by a core/meta module (BasicObject, Kernel, Object, Module, Class), blocking send, __send__, public_send, instance_eval, instance_exec, method, and similar reflection methods.

Why it matters

This defeats kobako's central guarantee — isolating untrusted mruby scripts from the host — turning a sandbox boundary into a full remote code execution path. Per the advisory, any deployment that runs untrusted or attacker-influenced scripts through kobako with at least one bound Service object is affected, and there are no workarounds short of not binding Service objects into sandboxes running untrusted code. Given the CVSS 10.0 rating, public PoC, and the breadth of affected versions (essentially the entire release history prior to 0.9.1), this should be treated as urgent for any Ruby application using kobako as an isolation boundary for third-party or user-supplied scripts.

What defenders should do now

• Identify any Ruby services using the kobako gem and check the version — upgrade to 0.9.1 immediately.
• Until upgraded, per the advisory's stated workaround, avoid binding any host Service object into a sandbox that executes untrusted or attacker-influenced scripts.
• Audit application logs or telemetry around the sandbox dispatcher for guest-originated calls invoking reflection-style method names (send, public_send, instance_eval, instance_exec, method, instance_variable_get) — these are strong indicators of exploitation attempts against the pre-0.9.1 dispatcher.
• Review process-level monitoring on hosts running kobako sandboxes for unexpected child processes or file/state access originating from the Ruby process hosting the sandbox, consistent with host-side RCE.
• Treat any bound Service object as a full trust boundary breach if the host was ever running a pre-0.9.1 version and processed untrusted scripts — consider it potentially compromised pending investigation.

Developing intel

This is a same-day advisory and details may evolve as the community and maintainers publish further analysis. This post reflects only what is documented in the GitHub Security Advisory at the time of writing. For full technical details, the proof-of-concept description, and the fix commit, see the original advisory: GHSA-7pwq-q9jf-539h.