Summary
A critical code-injection vulnerability in Kobako allows a Ruby script running in its Wasm-isolated mruby sandbox to execute arbitrary Ruby code in the host application process. Any workflow that executes untrusted scripts, such as LLM-generated code, user formulas, student submissions, or third-party plugins, may be exposed to host-process compromise.
Affected context
The issue affects Kobako applications using vulnerable releases to execute untrusted mruby scripts inside the embedded Wasm sandbox. The risk exists when guest-controlled Ruby code is accepted and executed in-process while the sandbox boundary is expected to prevent access to host application capabilities, including memory, files, networks, and credentials.
Exploit preconditions
- Attack surface: The Kobako API or application workflow that executes guest mruby scripts
- Required access: The ability to provide or influence a script that the application sends to the sandbox
- Trigger point: Execution of the guest script by the embedded mruby interpreter
- Why exploitation is possible: A flaw in the sandbox boundary permits guest code to invoke arbitrary Ruby behavior in the host process rather than remaining isolated
Why this happens
The vulnerability results from insufficient isolation between guest mruby execution and the embedding host process. A guest-controlled script can cross the intended Wasm sandbox boundary and access host-language execution capabilities, mapping primarily to CWE-94: Improper Control of Generation of Code ('Code Injection'). The associated CWE-470: Use of Potentially Dangerous Function classification reflects the unsafe exposure of powerful runtime behavior to untrusted input.
Potential impact
- An attacker may execute arbitrary Ruby code in the host application process
- The application may lose the confidentiality and integrity protections expected from the sandbox
- Host-process memory, files, credentials, or network-connected services could be accessed depending on application privileges
- A compromised application could be used for data theft, modification, or further system compromise
- Malicious plugins or generated scripts could affect other users or workloads sharing the process
General mitigation guidance
Mitigation focuses on restoring a strong trust boundary between guest scripts and the host application.
Common defensive patterns include:
- Use a maintained release containing the sandbox-isolation correction, without relying on application-side workarounds alone
- Treat all guest scripts as untrusted and avoid exposing host-language evaluation or reflection capabilities
- Apply explicit capability-based interfaces that expose only the minimum operations required by the guest
- Run script execution in a separately isolated process or workload when the threat model requires defense against sandbox escapes
- Enforce least-privilege permissions, restricted credentials, and limited network access for the execution environment
- Apply resource limits and independent monitoring so a compromised guest cannot freely affect the host application
How teams detect issues like this
Organizations can look for this vulnerability class through:
- Static analysis and dependency review for embedded interpreters, Wasm boundary code, reflection, dynamic evaluation, and host callbacks
- Code review signals showing guest-controlled values reaching host-language execution APIs or unrestricted runtime objects
- Tests that verify guest code cannot access host memory, files, credentials, network functions, or privileged callbacks
- Policy enforcement requiring untrusted script execution to use capability-limited interfaces and isolated processes
- Runtime monitoring for unexpected file access, network connections, credential reads, or host-process behavior during script execution
- Automated security review tools that flag dangerous interpreter integrations and missing isolation checks
