Kobako CVE-2026-55107

Exploitation requires that the host application (1) runs untrusted or attacker-influenced mruby scripts inside the Kobako sandbox and (2) binds at least one host Service object that guest scripts can reference through the transport dispatcher - both are Kobako's intended usage, so no exotic configuration is needed. The attacker must be able to submit or influence a guest script; the escape then uses a single dispatch with method='send' and args=[:eval, '<ruby>']. What limits exploitation: if the deployment binds no Service objects, or never executes untrusted scripts, the sink is unreachable. The vulnerability exists in every released version 0.1.0 through 0.9.0 regardless of which of the three dispatcher names (registry/rpc/transport) is in use.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, base 10.0) reflects a full-impact, scope-changing sandbox escape and is consistent with the described mechanism. The critical caveat is that 'network, no-privilege' exploitation assumes the deployment actually accepts remote, attacker-influenced mruby scripts and binds at least one host Service - Kobako's core use case, but still a deployment-dependent precondition rather than a flaw reachable against an idle install. No EPSS score or CISA KEV status was provided, so real-world exploitation cannot be confirmed; the 10.0 rating is a theoretical-maximum severity, and given Kobako's very small deployment footprint, widespread opportunistic exploitation is unlikely relative to targeted use. The exploit is trivial (single dispatch call) and publicly documented, so any environment running untrusted scripts on 0.1.0-0.9.0 should treat this as an urgent priority; environments that never bind Service objects or never run untrusted scripts are not exposed.

An application uses Kobako to run user-submitted mruby scripts and binds a host Service (e.g. a config or theme object) for those scripts to call. An attacker submits a script that issues a dispatch equivalent to Service.send(:eval, "<arbitrary host ruby>"), which the dispatcher runs on the host, giving the attacker arbitrary Ruby execution to read/modify host state or spawn processes. The advisory publishes this exact proof-of-concept, and with low attack complexity and no authentication the attack is straightforward for anyone able to supply a guest script.