plaincve:~$

// threat brief

CVE-2026-55107

Kobako Ruby sandbox escape: a sandboxed script can run arbitrary code in the host through any bound Service object

CVSS
10.0 CRITICAL
CISA KEV
Not listed
Weakness
CWE-94 · CWE-470
Topics
AI security

PlainCVE Team · Published 2026-10-07 · AI-assisted · Press brief ↓

AI review 2026-10-07 (not human-reviewed)Command tests: none yetReproduced: not yetVerification record ↓

Kobako 0.1.0–0.9.0 lets a sandboxed script escape and run arbitrary Ruby in the host app through any bound Service object. Fixed in 0.9.1.

Who is affectedApplications using the kobako gem 0.1.0 through 0.9.0 that run untrusted or attacker-influenced scripts in Kobako and bind at least one host Service object into the sandbox.
What happensA script can fully escape the sandbox and run arbitrary Ruby in the host process (the application embedding Kobako), reading or changing host state and starting other processes.
What to do nowUpgrade kobako to 0.9.1 or later. Until you can, the maintainer advises not binding any host Service object into a sandbox that runs untrusted scripts.
Affected versions0.1.0 through 0.9.0 (every release before 0.9.1)
Fixed versions0.9.1 or later (0.25.0 adds further hardening)
CVSS vector
Show full vectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Timeline
  • First public 2026-06-11

Blue team playbook

Check, fix / mitigate, respond, harden. Matching the affected versions does not mean you were compromised, and a check that finds nothing does not prove you are safe; each item says what it can and cannot show. Tagged steps point to where the attack flow below can be stopped.

DETECTCheckAm I affected? Any signs of compromise?
  1. 01Check your version and exposure

    You are affected if all three hold: kobako 0.1.0 through 0.9.0, running untrusted scripts, and at least one Service object bound into the sandbox.

    Read-only check
    grep -n 'kobako' Gemfile.lock
  2. 02Watch for unexpected child processes

    TheHackerWire suggests watching for unexpected child processes started by the application's main process. This is generic third-party guidance, not from the maintainer, and finding nothing does not prove you were not attacked.

    Step 4
MITIGATEFix / mitigatePatch; block it if you cannot patch yet
  1. 01Upgrade to 0.9.1 or later

    In 0.9.1 the dispatcher refuses methods that belong to core modules.

    Read-only check
    bundle info kobako
    Step 3
  2. 02Can't upgrade yet: don't bind any host Service object

    The maintainer says there is no workaround within affected versions; until you upgrade, do not bind any host Service object into a sandbox that runs untrusted scripts.

    Step 2
RESPONDRespondIf you find signs of compromise
  1. 01If you suspect exploitation, treat the host as compromised

    PlainCVE's suggestion: escaped code runs as the host process, so treat any data and credentials that process could reach as possibly exposed, then investigate and rotate them. PlainCVE found no incident-response guidance from the maintainer in the sources reviewed.

    Step 4
HARDENHardenPrevent the next one
  1. 01Limit who can submit scripts

    PlainCVE's suggestion: CVSS rates this as no privileges and network-reachable, but in practice that depends on whether the application lets unauthenticated remote users submit scripts. Requiring login and permissions narrows exposure.

    Step 1
  2. 02Expose only what's needed and run the host with least privilege

    PlainCVE's suggestion (not from the maintainer): bind only the Services you truly need, and keep unneeded credentials and permissions out of the host process so a future sandbox break does less damage. Version 0.25.0 further limits a bound object to the public methods its own class defines; note that the 0.25.0 release notes mark this as a "BREAKING CHANGES" item: methods inherited from a superclass, mixed in from a module, or built into Ruby are refused, which may stop existing scripts from calling methods they used before. PlainCVE suggests checking compatibility before moving to it.

    Step 2Step 4
Full remediation steps and notes
# Check the current version
grep -n 'kobako' Gemfile.lock
# Upgrade (your Gemfile constraint must allow 0.9.1 or later)
bundle update kobako
bundle info kobako
VersionStatus
0.1.0 – 0.9.0Affected
0.9.1Fixes this vulnerability
0.25.0 or laterFurther limits what bound objects expose; the release notes mark it as a breaking change (BREAKING CHANGES). PlainCVE suggests moving to it after checking compatibility
  • The maintainer says there is no workaround within affected versions. The only interim measure is not binding any host Service object into a sandbox that runs untrusted scripts; PlainCVE notes this may remove functionality scripts rely on, so treat it as short-term.
  • CVSS rates this as network-reachable with no privileges. Our analysis: Kobako is a library, so real-world risk depends on whether your application lets unauthenticated remote users submit scripts (TheHackerWire also notes that authentication and network reachability depend on the application’s design). Our analysis: even if login is required, any user who is allowed to submit scripts may be able to exploit it, so don’t delay the upgrade.

Attack flow

Read left to right: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Click an icon for details.

Read top to bottom: this is the order the attack happens in. A blue shield means the step can be stopped; the earlier, the better. Tap an icon for details.

Kobako Ruby sandbox escape: a sandboxed script can run arbitrary code in the host through any bound Service object: 1. The attacker gets a script run inside the Kobako sandbox → 2. The script calls a host Service object bound into the sandbox → 3. The dispatcher accepts whatever method name the script asks for → 4. Arbitrary Ruby runs in the host processCVE-2026-55107 · Kobako Ruby sandbox escape: a sandboxed script can run arbitrary code inthe host through any bound Service objectAttackerYour systemThe attacker gets a script run inside the Kobako sandbox — This requires an application that runs untrusted or attacker-influenced scripts. Whether login is needed, or whether it can be done over the network, depends on how the application accepts scripts. 1The attacker getsa script runinside the KobakosandboxThe script calls a host Service object bound into the sandbox — Any bound Service object is enough; the Service does not need any particular behaviour. 2The script calls ahost Serviceobject bound intothe sandboxThe dispatcher accepts whatever method name the script asks for — Older versions passed the script's method name straight to public_send on the host object, without limiting calls to what the Service itself offers. 3The dispatcheraccepts whatevermethod name thescript asks forArbitrary Ruby runs in the host process — The sandbox is completely bypassed. The code can read or change host state and start other processes. 4Arbitrary Rubyruns in the hostprocessAttack pathCan be stopped herePlainCVE · plaincve.date/en/vulns/cve-2026-55107-kobako-ruby-sandbox-escape · CC BY 4.0
Kobako Ruby sandbox escape: a sandboxed script can run arbitrary code in the host through any bound Service object: 1. The attacker gets a script run inside the Kobako sandbox → 2. The script calls a host Service object bound into the sandbox → 3. The dispatcher accepts whatever method name the script asks for → 4. Arbitrary Ruby runs in the host processCVE-2026-55107 · Kobako Ruby sandboxescape: a sandboxed script can runarbitrary code in the host through anybound Service objectThe attacker gets a script run inside the Kobako sandbox — This requires an application that runs untrusted or attacker-influenced scripts. Whether login is needed, or whether it can be done over the network, depends on how the application accepts scripts. 1AttackerThe attacker gets a script runinside the Kobako sandboxThe script calls a host Service object bound into the sandbox — Any bound Service object is enough; the Service does not need any particular behaviour. 2Your systemThe script calls a host Serviceobject bound into the sandboxThe dispatcher accepts whatever method name the script asks for — Older versions passed the script's method name straight to public_send on the host object, without limiting calls to what the Service itself offers. 3Your systemThe dispatcher accepts whatevermethod name the script asks forArbitrary Ruby runs in the host process — The sandbox is completely bypassed. The code can read or change host state and start other processes. 4AttackerArbitrary Ruby runs in the hostprocessAttack pathCan be stopped herePlainCVE · CC BY 4.0plaincve.date/en/vulns/cve-2026-55107-kobako-ruby-sandbox-escape
Free to use in reporting and teaching under CC BY 4.0. Attribution is already on the image.
  1. Attacker

    The attacker gets a script run inside the Kobako sandbox

    This requires an application that runs untrusted or attacker-influenced scripts. Whether login is needed, or whether it can be done over the network, depends on how the application accepts scripts.

    Defense: PlainCVE's suggestion (not from the maintainer): limit who can submit scripts and require authentication.

  2. Your system

    The script calls a host Service object bound into the sandbox

    Any bound Service object is enough; the Service does not need any particular behaviour.

    Defense: Until you upgrade (maintainer's advice): don't bind any host Service object into a sandbox that runs untrusted scripts.

  3. Your system

    The dispatcher accepts whatever method name the script asks for

    Older versions passed the script's method name straight to public_send on the host object, without limiting calls to what the Service itself offers.

    Defense: Upgrade to 0.9.1+: the dispatcher rejects methods owned by the core modules BasicObject, Kernel, Object, Module and Class.

  4. Attacker

    Arbitrary Ruby runs in the host process

    The sandbox is completely bypassed. The code can read or change host state and start other processes.

    Defense: PlainCVE's suggestion (not from the maintainer): run the host process with least privilege. TheHackerWire suggests watching for unexpected child processes from the application (third-party advice, not from the maintainer).

Who is affected

Kobako is a Ruby gem (a Ruby package). It wraps mruby, a lightweight Ruby interpreter, in a Wasm isolation layer so applications can run untrusted Ruby scripts in an isolated sandbox inside their own application.

ConditionAffected?
kobako 0.1.0 through 0.9.0 + running untrusted or attacker-influenced scripts + at least one host Service object boundAffected
kobako 0.9.1 or laterFixed
kobako 0.25.0 or laterFixed, with further hardening (the maintainer does not link it to this CVE)
Affected version but no Service object boundNot binding is exactly the maintainer’s interim advice; upgrade anyway

Binding any Service object is enough; the Service needs no special behaviour. The maintainer says every release from 0.1.0 through 0.9.0 is affected, and the CVE record’s range (”>= 0.1.0, < 0.9.1”) matches. TheHackerWire lists “version 0.9.1” as affected, which conflicts with the maintainer naming 0.9.1 as the fix; our analysis is that the site is wrong.

How it works

When a script inside the sandbox (the “guest”) needs something from the host, it calls a Service object that has been bound into the sandbox. A “dispatcher” on the host side forwards those calls to the real Ruby object.

Older versions of the dispatcher handed the guest’s method name straight to public_send (Ruby’s way of calling a public method by name). The catch: a Ruby object carries not just the Service’s own methods, but also general-purpose public methods inherited from core modules such as Kernel and Object. The result is that a script can run arbitrary Ruby in the host process, defeating the sandbox’s central guarantee. This maps to CWE-94 (code injection) and CWE-470 (unsafe reflection).

The flawed approach (conceptual illustration, not the original source code):

Show code example(ruby)
def dispatch(service, method_name, args)
  # Call whatever the script asks for
  service.public_send(method_name, *args)
end

The fixed approach (conceptual illustration):

Show code example(ruby)
META_OWNERS = [BasicObject, Kernel, Object, Module, Class].freeze

def dispatch(service, method_name, args)
  owner = service.method(method_name).owner
  # Reject any method owned by a core module
  raise Rejected if META_OWNERS.include?(owner)
  service.public_send(method_name, *args)
end

Version 0.25.0 (2026-09-14) tightened this further: a bound object now exposes only the public methods its own class and the object itself define in source, and names answered dynamically through method_missing are refused too. Our analysis: this suggests 0.9.1 still allowed names handled via method_missing, and 0.25.0 appears to close that remaining surface; the maintainer has not said whether it relates to this CVE.

Timeline

DateEvent
(date not stated)0.1.0: OSV maps the start of the affected range to commit 631ddc7f
2026-06-11Maintainer publishes advisory GHSA-7pwq-q9jf-539h on the GitHub project (02:26 UTC)
2026-06-11v0.9.1 released (the release page shows only “11 Jun”; the project CHANGELOG dates 0.9.1 to 2026-06-11)
2026-06-16CVE ID reserved
2026-08-18GitHub Advisory Database publishes its reviewed advisory
2026-09-14v0.25.0 released, further limiting methods exposed to the sandbox (not linked to this CVE)
2026-09-30CVE record published
2026-10-01Still not listed in CISA KEV

Further reading

  • Scoring: The CNA score is CVSS 3.1 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). NVD’s analysis status is “Deferred”, so there is no NVD score.
  • Exploitation: Not listed in CISA KEV as of 2026-10-01. There is no information on exploitation in the wild or before a patch existed; absence from KEV does not prove it was never exploited. CISA’s SSVC assessment rates it as automatable with total technical impact.
  • Sources disagree on a PoC: CISA’s SSVC rates exploitation as “poc” and the maintainer’s advisory includes a proof-of-concept description; TheHackerWire says no public PoC is indexed.
  • Sources disagree on the disclosure date: The maintainer’s advisory went public on 2026-06-11; TheHackerWire says 2026-09-30, which is actually the CVE publication date. This page uses the earlier June 11 date.
  • Fix commit: The advisory names commit 64f8470, while the 0.9.1 release notes reference dd08166. Our analysis: these are probably the merge commit and the original commit of the same change, but nothing confirms that.
  • Detection: TheHackerWire suggests watching for unexpected child processes started by the application’s main process; this is generic third-party guidance, not from the maintainer.
  • Reported and fixed by Ahmed Al Hafoudh.

Verification Checked item by item against sources by AI under our review rules, all passed; not human-reviewed and not yet reproduced in our lab

AI review2026-10-07 · review rules

Verification records describe the environment and the result only, never reproduction steps or code that could attack other people’s systems. See our policy.

Sources

  1. AdvisoryGHSA-7pwq-q9jf-539h — Sandbox escape: guest eval reaches host RCE via method_missing → public_send · elct9620/kobako (GitHub), 2026-06-11 · accessed 2026-10-01
  2. CVE / NVD / OSVCVE-2026-55107 record (CVE Services API) · CVE Program, 2026-09-30 · accessed 2026-10-01
  3. CVE / NVD / OSVNVD API - CVE-2026-55107 · NIST · accessed 2026-10-01
  4. AdvisoryGitHub Advisory Database - GHSA-7pwq-q9jf-539h · GitHub, 2026-08-18 · accessed 2026-10-01
  5. Patch / releaseFix commit 64f8470 (transport dispatcher meta-owner blocklist) · elct9620/kobako (GitHub) · accessed 2026-10-01
  6. Patch / releasekobako v0.9.1 release · elct9620/kobako (GitHub), 2026-06-11 · accessed 2026-10-01
  7. Patch / releasekobako v0.25.0 release · elct9620/kobako (GitHub), 2026-09-14 · accessed 2026-10-01
  8. Patch / releasekobako CHANGELOG · elct9620/kobako (GitHub) · accessed 2026-10-06
  9. VendorKobako repository · elct9620 (GitHub) · accessed 2026-10-01
  10. OtherOSV - CVE-2026-55107 · OSV · accessed 2026-10-01
  11. NewsCVE-2026-55107: Kobako Ruby gem sandbox escape enables host process RCE · TheHackerWire · accessed 2026-10-01
  12. NewsTheHackerWire - CVE-2026-55107 · TheHackerWire · accessed 2026-10-01

Press brief

In one sentence

Kobako is a Ruby package that lets applications run untrusted Ruby scripts inside an isolated (Wasm/mruby) sandbox. Every version from 0.1.0 through 0.9.0 has a flaw that lets a script inside the sandbox fully break out and run arbitrary code in the host application. The maintainer released the fix, 0.9.1, on June 11, 2026; the CVE was only published on September 30, with the maximum score of 10.0.

Key facts

Severity
CVSS 3.1 10.0 (CNA score; NVD has not analysed it) cveawg.mitre.org
Affected versions
0.1.0 through 0.9.0 github.com
Fixed version
0.9.1 (2026-06-11) raw.githubusercontent.com
Maintainer advisory
GHSA-7pwq-q9jf-539h, published 2026-06-11 github.com
CVE published
2026-09-30 cveawg.mitre.org
Reported and fixed by
Ahmed Al Hafoudh github.com

Confirmed

  • In 0.1.0 through 0.9.0, a sandboxed script can run arbitrary Ruby in the host process through any bound Service object.
  • 0.9.1 fixes it; the dispatcher rejects methods owned by core modules.
  • As of 2026-10-01, it is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.

Unconfirmed / disputed

  • There is no information on exploitation in the wild or before a patch existed; not being in KEV does not prove it was never exploited.
  • Sources disagree on a public proof of concept (PoC): CISA's assessment says 'poc' and the advisory includes a PoC description, while TheHackerWire says no public PoC is indexed.
  • Sources disagree on the disclosure date: the maintainer's advisory is dated 2026-06-11, while TheHackerWire says 2026-09-30 (the CVE publication date).
  • The maintainer has not said whether the later 0.25.0 hardening relates to this CVE.

Quotable line

The sandbox walls held; the trouble was the service window, which handed over the whole kitchen without asking what was being ordered.

Images

Download the share image (PNG) · Attack flow diagram (downloadable)

Please credit "PlainCVE" and link to this page. Full citation format is under "How to cite" below. Found a factual error? Report it.

How to cite this page

This article is CC BY 4.0. Please keep the attribution and link when republishing.

PlainCVE Team (2026). "Kobako Ruby sandbox escape: a sandboxed script can run arbitrary code in the host through any bound Service object". PlainCVE. https://plaincve.date/en/vulns/cve-2026-55107-kobako-ruby-sandbox-escape (accessed YYYY-MM-DD)
BibTeX
@misc{cve202655107kobakorubysandboxescape2026,
  title  = {Kobako Ruby sandbox escape: a sandboxed script can run arbitrary code in the host through any bound Service object},
  author = {PlainCVE Team},
  year   = {2026},
  howpublished = {PlainCVE},
  url    = {https://plaincve.date/en/vulns/cve-2026-55107-kobako-ruby-sandbox-escape},
  note   = {Updated 2026-10-07}
}