CVE-2026-55107: 
Ruby vulnerability analysis and mitigation

CVE-2026-55107 is a critical sandbox escape vulnerability in the Kobako Ruby gem that allows a guest mruby script to execute arbitrary Ruby code in the host process, completely bypassing the Wasm-based isolation boundary. Kobako (versions 0.1.0 through 0.9.0) is designed to safely run untrusted Ruby scripts — such as LLM-generated code, user formulas, student submissions, or third-party plugins — in-process without granting access to host memory, files, network, or credentials. The vulnerability was first published on June 11, 2026, and added to the GitHub Advisory Database on August 18, 2026. It carries a CVSS v3.1 base score of 10.0 (Critical) (Github Advisory, Feedly).

The root cause is an unguarded use of Object#public_send in Kobako's transport dispatcher (CWE-94: Code Injection; CWE-470: Unsafe Reflection). When a guest mruby script invokes a method on a host-bound Service object across the Wasm boundary, the dispatcher passed the guest-supplied method name directly to target.public_send(method.to_sym, *args, **kwargs, &block) with no allowlist or ownership check. Because public_send in Ruby resolves any public method — including ambient Kernel/Object reflection methods — a guest can supply method="send" with args=[:eval, "<arbitrary_ruby_code>"], causing the dispatcher to call target.public_send(:send, :eval, "<code>"), which resolves to Kernel#send and evaluates attacker-controlled Ruby in the host process. No special Service behavior is required; any bound Service object is a sufficient pivot point. A concrete proof-of-concept payload (Service.send(:eval, "<arbitrary host ruby>")) is documented in the advisory (Github Advisory, Fix Commit).

Successful exploitation results in complete sandbox escape and arbitrary code execution within the host Ruby process, with all privileges and access of that process. An attacker can read or modify host memory and state, access files and environment variables (including credentials and secrets), spawn arbitrary processes, and make outbound network connections — fully defeating Kobako's core security guarantee. The scope change (CVSS S:C) reflects that the compromise extends beyond the sandboxed guest environment to the entire host process and any resources it can reach, enabling lateral movement, data exfiltration, or further privilege escalation (Github Advisory, Feedly).

A proof-of-concept exploit is publicly documented in the GitHub security advisory, demonstrating the specific payload and method-pivoting chain required for exploitation (Github Advisory). The attack requires no authentication, no user interaction, and no special privileges — only the ability to supply a guest mruby script to an application using an affected Kobako version with at least one bound Service object. The EPSS score is approximately 0.799% (55th percentile), and there is no current evidence of in-the-wild exploitation or CISA KEV catalog listing. NVD SSVC assessment classifies exploitation status as "poc" with technical impact rated "total" and automatable set to "yes" (Feedly).

1. Identify a target application: Locate a Ruby application using Kobako versions 0.1.0–0.9.0 that accepts untrusted or user-supplied Ruby scripts (e.g., LLM-generated code, user formulas, plugin submissions) and exposes at least one host-bound Service object to the guest sandbox.
2. Craft a malicious guest mruby script: Prepare a guest script that invokes a method call on any accessible bound Service object, specifying method="send" and args=[:eval, "<arbitrary_ruby_code>"].
3. Submit the script to the sandbox: Deliver the malicious mruby script through the application's normal input channel (e.g., formula input field, plugin upload, API endpoint accepting user scripts).
4. Trigger dispatcher pivot: The Kobako transport dispatcher receives the method invocation and calls target.public_send(:send, :eval, "<ruby_code>") on the bound Service object without any method ownership check.
5. Achieve host RCE: public_send(:send, ...) resolves to Kernel#send, which in turn calls Kernel#eval with the attacker-controlled Ruby string, executing arbitrary code in the host process with full access to host state, files, environment variables, credentials, and network (Github Advisory, Fix Commit).

• Logs: Application logs showing unexpected method invocations on Service objects with method names such as send, __send__, public_send, eval, instance_eval, instance_exec, method, tap, instance_variable_get, or class originating from guest script execution contexts.
• Process: Unusual child processes spawned by the Ruby host process (e.g., /bin/sh, bash, curl, wget, python, nc) that are not part of normal application behavior; unexpected process trees descending from the Kobako-hosting Ruby process.
• File System: New or modified files in application directories, unexpected scripts or binaries written to disk, or new cron jobs/scheduled tasks created by the application's service account.
• Network: Unexpected outbound connections from the Ruby host process to external IPs or domains not part of normal application traffic, potentially indicating reverse shell or data exfiltration activity.
• Environment: Unexpected access to environment variables containing credentials, API keys, or secrets, evidenced by audit logs or secret scanning alerts (Github Advisory).

The primary remediation is to upgrade Kobako to version 0.9.1 or later, which introduces a reject_meta_method! guard in the transport dispatcher that rejects any guest-supplied method name whose resolved owner is a core/meta module (BasicObject, Kernel, Object, Module, or Class), blocking the entire ambient reflection surface (Github Advisory, v0.9.1 Release). There is no in-version workaround for affected releases (0.1.0–0.9.0). If immediate upgrade is not possible, the only mitigation is to stop binding any host Service object into sandboxes that execute untrusted scripts until the patch can be applied (Github Advisory).

The vulnerability was reported and fixed by security researcher Ahmed Al Hafoudh, who is credited in the advisory (Github Advisory). Coverage appeared on The Hacker Wire, which highlighted the sandbox escape and host-process RCE implications (The Hacker Wire). The vulnerability was also tracked by RubySec and OSV, reflecting standard community monitoring of Ruby ecosystem security issues.