kobako

Version	Released
`0.23.0` minor	Aug 28, 2026
`0.22.0` minor	Aug 06, 2026
`0.21.1` patch	Jul 30, 2026
`0.21.0` minor	Jul 29, 2026
`0.20.0` minor	Jul 24, 2026
`0.19.0` minor	Jul 19, 2026
`0.18.0` minor	Jul 18, 2026
`0.17.0` minor	Jul 17, 2026
`0.16.0` minor	Jul 12, 2026
`0.15.0` minor	Jul 11, 2026
`0.14.0` minor	Jul 08, 2026
`0.13.0` minor	Jul 03, 2026
`0.12.2` patch	Jul 02, 2026
`0.12.1` patch	Jun 27, 2026
`0.12.0` minor	Jun 26, 2026
`0.11.2` patch	Jun 24, 2026
`0.11.1` patch	Jun 14, 2026
`0.11.0` minor	Jun 13, 2026
`0.10.0` minor	Jun 12, 2026
`0.9.2` patch	Jun 11, 2026
`0.9.1` patch	Jun 11, 2026
`0.9.0` minor 1 CVE	Jun 10, 2026
`0.8.0` minor 1 CVE	Jun 05, 2026
`0.7.0` minor 1 CVE	Jun 03, 2026
`0.6.2` patch 1 CVE	May 31, 2026
`0.6.1` patch 1 CVE	May 28, 2026
`0.6.0` minor 1 CVE	May 28, 2026
`0.5.0` minor 1 CVE	May 27, 2026
`0.4.0` minor 1 CVE	May 22, 2026
`0.3.0` minor 1 CVE	May 20, 2026
`0.2.1` patch 1 CVE	May 17, 2026
`0.2.0` minor 1 CVE	May 16, 2026
`0.1.2` patch 1 CVE	May 14, 2026
`0.1.1` patch 1 CVE	May 13, 2026
`0.1.0` initial 1 CVE	May 13, 2026

0.23.0 minor

Aug 28, 2026

0.22.0 minor

Aug 06, 2026

0.21.1 patch

Jul 30, 2026

0.21.0 minor

Jul 29, 2026

0.20.0 minor

Jul 24, 2026

0.19.0 minor

Jul 19, 2026

0.18.0 minor

Jul 18, 2026

0.17.0 minor

Jul 17, 2026

0.16.0 minor

Jul 12, 2026

0.15.0 minor

Jul 11, 2026

0.14.0 minor

Jul 08, 2026

0.13.0 minor

Jul 03, 2026

0.12.2 patch

Jul 02, 2026

0.12.1 patch

Jun 27, 2026

0.12.0 minor

Jun 26, 2026

0.11.2 patch

Jun 24, 2026

0.11.1 patch

Jun 14, 2026

0.11.0 minor

Jun 13, 2026

0.10.0 minor

Jun 12, 2026

0.9.2 patch

Jun 11, 2026

0.9.1 patch

Jun 11, 2026

0.9.0 minor

1 CVE

CVE-2026-55107 GHSA-7pwq-q9jf-539h Aug 18, 2026

kobako Sandbox Escape: guest eval reaches host RCE via method_missing → public_send (any bound Service)

10.0 / 10

Critical

Network Low None None Changed High High High

Summary

A guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox.

Details

A host embeds bound "Service" objects that guest scripts call across the wasm boundary through the transport dispatcher. The dispatcher passed the guest-supplied method name straight to Object#public_send on the bound object, with no restriction to the object's own methods:

target.public_send(method.to_sym, *args, **kwargs, &block)

public_send can invoke any public method, including Ruby's ambient reflection surface. A guest pivots through the public send into otherwise private Kernel methods: a dispatch request with method = "send" and args = [:eval, "<ruby>"] evaluates to target.send(:eval, "<ruby>"), running attacker-controlled Ruby in the host. Any bound Service object is sufficient — no Service-specific behavior is required.

Proof of Concept

A guest call equivalent to:

Service.send(:eval, "<arbitrary host ruby>")

executes in the host process and can read or modify host state, spawn processes, and so on.

Impact

Complete sandbox escape leading to remote code execution in the host process, defeating the gem's central guarantee of isolating untrusted mruby scripts. Any deployment that runs untrusted or attacker-influenced scripts is affected. All released versions (0.1.0 through 0.9.0) are vulnerable; the dispatcher carried the same unguarded public_send sink under three successive names (registry → rpc → transport).

Patches

Fixed in 0.9.1. The dispatcher now rejects any method whose resolved owner is a core/meta module (BasicObject, Kernel, Object, Module, Class), so only methods the bound object itself defines — or dynamically handles via method_missing — remain reachable. The ambient reflection methods (send, __send__, public_send, instance_eval, instance_exec, method, instance_variable_get, …) are all owned by those modules and are blocked.

Workarounds

None within the affected versions. Until you can upgrade, do not bind any host Service object into a sandbox that runs untrusted scripts. Upgrade to 0.9.1.

References

GHSA-7pwq-q9jf-539h
Fix commit: 64f8470

Credits

Reported and fixed by Ahmed Al Hafoudh.

Affected versions


          0.1.0


          0.1.1


          0.1.2


          0.2.0


          0.2.1


          0.3.0


          0.4.0


          0.5.0


          0.6.0


          0.6.1


          0.6.2


          0.7.0

+ 2 more


            0.8.0


            0.9.0

Fixed in


          0.9.1

References

Updated Aug 18, 2026 · Source: OSV.dev

Jun 10, 2026

0.8.0 minor

1 CVE

CVE-2026-55107 GHSA-7pwq-q9jf-539h Aug 18, 2026

kobako Sandbox Escape: guest eval reaches host RCE via method_missing → public_send (any bound Service)

10.0 / 10

Critical

Network Low None None Changed High High High

Summary

A guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox.

Details

A host embeds bound "Service" objects that guest scripts call across the wasm boundary through the transport dispatcher. The dispatcher passed the guest-supplied method name straight to Object#public_send on the bound object, with no restriction to the object's own methods:

target.public_send(method.to_sym, *args, **kwargs, &block)

public_send can invoke any public method, including Ruby's ambient reflection surface. A guest pivots through the public send into otherwise private Kernel methods: a dispatch request with method = "send" and args = [:eval, "<ruby>"] evaluates to target.send(:eval, "<ruby>"), running attacker-controlled Ruby in the host. Any bound Service object is sufficient — no Service-specific behavior is required.

Proof of Concept

A guest call equivalent to:

Service.send(:eval, "<arbitrary host ruby>")

executes in the host process and can read or modify host state, spawn processes, and so on.

Impact

Complete sandbox escape leading to remote code execution in the host process, defeating the gem's central guarantee of isolating untrusted mruby scripts. Any deployment that runs untrusted or attacker-influenced scripts is affected. All released versions (0.1.0 through 0.9.0) are vulnerable; the dispatcher carried the same unguarded public_send sink under three successive names (registry → rpc → transport).

Patches

Fixed in 0.9.1. The dispatcher now rejects any method whose resolved owner is a core/meta module (BasicObject, Kernel, Object, Module, Class), so only methods the bound object itself defines — or dynamically handles via method_missing — remain reachable. The ambient reflection methods (send, __send__, public_send, instance_eval, instance_exec, method, instance_variable_get, …) are all owned by those modules and are blocked.

Workarounds

None within the affected versions. Until you can upgrade, do not bind any host Service object into a sandbox that runs untrusted scripts. Upgrade to 0.9.1.

References

GHSA-7pwq-q9jf-539h
Fix commit: 64f8470

Credits

Reported and fixed by Ahmed Al Hafoudh.

Affected versions


          0.1.0


          0.1.1


          0.1.2


          0.2.0


          0.2.1


          0.3.0


          0.4.0


          0.5.0


          0.6.0


          0.6.1


          0.6.2


          0.7.0

+ 2 more


            0.8.0


            0.9.0

Fixed in


          0.9.1

References

Updated Aug 18, 2026 · Source: OSV.dev

Jun 05, 2026

0.7.0 minor

1 CVE

CVE-2026-55107 GHSA-7pwq-q9jf-539h Aug 18, 2026

kobako Sandbox Escape: guest eval reaches host RCE via method_missing → public_send (any bound Service)

10.0 / 10

Critical

Network Low None None Changed High High High

Summary

A guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox.

Details

A host embeds bound "Service" objects that guest scripts call across the wasm boundary through the transport dispatcher. The dispatcher passed the guest-supplied method name straight to Object#public_send on the bound object, with no restriction to the object's own methods:

target.public_send(method.to_sym, *args, **kwargs, &block)

public_send can invoke any public method, including Ruby's ambient reflection surface. A guest pivots through the public send into otherwise private Kernel methods: a dispatch request with method = "send" and args = [:eval, "<ruby>"] evaluates to target.send(:eval, "<ruby>"), running attacker-controlled Ruby in the host. Any bound Service object is sufficient — no Service-specific behavior is required.

Proof of Concept

A guest call equivalent to:

Service.send(:eval, "<arbitrary host ruby>")

executes in the host process and can read or modify host state, spawn processes, and so on.

Impact

Complete sandbox escape leading to remote code execution in the host process, defeating the gem's central guarantee of isolating untrusted mruby scripts. Any deployment that runs untrusted or attacker-influenced scripts is affected. All released versions (0.1.0 through 0.9.0) are vulnerable; the dispatcher carried the same unguarded public_send sink under three successive names (registry → rpc → transport).

Patches

Fixed in 0.9.1. The dispatcher now rejects any method whose resolved owner is a core/meta module (BasicObject, Kernel, Object, Module, Class), so only methods the bound object itself defines — or dynamically handles via method_missing — remain reachable. The ambient reflection methods (send, __send__, public_send, instance_eval, instance_exec, method, instance_variable_get, …) are all owned by those modules and are blocked.

Workarounds

None within the affected versions. Until you can upgrade, do not bind any host Service object into a sandbox that runs untrusted scripts. Upgrade to 0.9.1.

References

GHSA-7pwq-q9jf-539h
Fix commit: 64f8470

Credits

Reported and fixed by Ahmed Al Hafoudh.

Affected versions


          0.1.0


          0.1.1


          0.1.2


          0.2.0


          0.2.1


          0.3.0


          0.4.0


          0.5.0


          0.6.0


          0.6.1


          0.6.2


          0.7.0

+ 2 more


            0.8.0


            0.9.0

Fixed in


          0.9.1

References

Updated Aug 18, 2026 · Source: OSV.dev

Jun 03, 2026

0.6.2 patch

1 CVE

CVE-2026-55107 GHSA-7pwq-q9jf-539h Aug 18, 2026

kobako Sandbox Escape: guest eval reaches host RCE via method_missing → public_send (any bound Service)

10.0 / 10

Critical

Network Low None None Changed High High High

Summary

A guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox.

Details

A host embeds bound "Service" objects that guest scripts call across the wasm boundary through the transport dispatcher. The dispatcher passed the guest-supplied method name straight to Object#public_send on the bound object, with no restriction to the object's own methods:

target.public_send(method.to_sym, *args, **kwargs, &block)

public_send can invoke any public method, including Ruby's ambient reflection surface. A guest pivots through the public send into otherwise private Kernel methods: a dispatch request with method = "send" and args = [:eval, "<ruby>"] evaluates to target.send(:eval, "<ruby>"), running attacker-controlled Ruby in the host. Any bound Service object is sufficient — no Service-specific behavior is required.

Proof of Concept

A guest call equivalent to:

Service.send(:eval, "<arbitrary host ruby>")

executes in the host process and can read or modify host state, spawn processes, and so on.

Impact

Complete sandbox escape leading to remote code execution in the host process, defeating the gem's central guarantee of isolating untrusted mruby scripts. Any deployment that runs untrusted or attacker-influenced scripts is affected. All released versions (0.1.0 through 0.9.0) are vulnerable; the dispatcher carried the same unguarded public_send sink under three successive names (registry → rpc → transport).

Patches

Fixed in 0.9.1. The dispatcher now rejects any method whose resolved owner is a core/meta module (BasicObject, Kernel, Object, Module, Class), so only methods the bound object itself defines — or dynamically handles via method_missing — remain reachable. The ambient reflection methods (send, __send__, public_send, instance_eval, instance_exec, method, instance_variable_get, …) are all owned by those modules and are blocked.

Workarounds

None within the affected versions. Until you can upgrade, do not bind any host Service object into a sandbox that runs untrusted scripts. Upgrade to 0.9.1.

References

GHSA-7pwq-q9jf-539h
Fix commit: 64f8470

Credits

Reported and fixed by Ahmed Al Hafoudh.

Affected versions


          0.1.0


          0.1.1


          0.1.2


          0.2.0


          0.2.1


          0.3.0


          0.4.0


          0.5.0


          0.6.0


          0.6.1


          0.6.2


          0.7.0

+ 2 more


            0.8.0


            0.9.0

Fixed in


          0.9.1

References

Updated Aug 18, 2026 · Source: OSV.dev

May 31, 2026

0.6.1 patch

1 CVE

CVE-2026-55107 GHSA-7pwq-q9jf-539h Aug 18, 2026

kobako Sandbox Escape: guest eval reaches host RCE via method_missing → public_send (any bound Service)

10.0 / 10

Critical

Network Low None None Changed High High High

Summary

A guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox.

Details

A host embeds bound "Service" objects that guest scripts call across the wasm boundary through the transport dispatcher. The dispatcher passed the guest-supplied method name straight to Object#public_send on the bound object, with no restriction to the object's own methods:

target.public_send(method.to_sym, *args, **kwargs, &block)

public_send can invoke any public method, including Ruby's ambient reflection surface. A guest pivots through the public send into otherwise private Kernel methods: a dispatch request with method = "send" and args = [:eval, "<ruby>"] evaluates to target.send(:eval, "<ruby>"), running attacker-controlled Ruby in the host. Any bound Service object is sufficient — no Service-specific behavior is required.

Proof of Concept

A guest call equivalent to:

Service.send(:eval, "<arbitrary host ruby>")

executes in the host process and can read or modify host state, spawn processes, and so on.

Impact

Complete sandbox escape leading to remote code execution in the host process, defeating the gem's central guarantee of isolating untrusted mruby scripts. Any deployment that runs untrusted or attacker-influenced scripts is affected. All released versions (0.1.0 through 0.9.0) are vulnerable; the dispatcher carried the same unguarded public_send sink under three successive names (registry → rpc → transport).

Patches

Fixed in 0.9.1. The dispatcher now rejects any method whose resolved owner is a core/meta module (BasicObject, Kernel, Object, Module, Class), so only methods the bound object itself defines — or dynamically handles via method_missing — remain reachable. The ambient reflection methods (send, __send__, public_send, instance_eval, instance_exec, method, instance_variable_get, …) are all owned by those modules and are blocked.

Workarounds

None within the affected versions. Until you can upgrade, do not bind any host Service object into a sandbox that runs untrusted scripts. Upgrade to 0.9.1.

References

GHSA-7pwq-q9jf-539h
Fix commit: 64f8470

Credits

Reported and fixed by Ahmed Al Hafoudh.

Affected versions


          0.1.0


          0.1.1


          0.1.2


          0.2.0


          0.2.1


          0.3.0


          0.4.0


          0.5.0


          0.6.0


          0.6.1


          0.6.2


          0.7.0

+ 2 more


            0.8.0


            0.9.0

Fixed in


          0.9.1

References

Updated Aug 18, 2026 · Source: OSV.dev

May 28, 2026

0.6.0 minor

1 CVE

CVE-2026-55107 GHSA-7pwq-q9jf-539h Aug 18, 2026

kobako Sandbox Escape: guest eval reaches host RCE via method_missing → public_send (any bound Service)

10.0 / 10

Critical

Network Low None None Changed High High High

Summary

A guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox.

Details

A host embeds bound "Service" objects that guest scripts call across the wasm boundary through the transport dispatcher. The dispatcher passed the guest-supplied method name straight to Object#public_send on the bound object, with no restriction to the object's own methods:

target.public_send(method.to_sym, *args, **kwargs, &block)

public_send can invoke any public method, including Ruby's ambient reflection surface. A guest pivots through the public send into otherwise private Kernel methods: a dispatch request with method = "send" and args = [:eval, "<ruby>"] evaluates to target.send(:eval, "<ruby>"), running attacker-controlled Ruby in the host. Any bound Service object is sufficient — no Service-specific behavior is required.

Proof of Concept

A guest call equivalent to:

Service.send(:eval, "<arbitrary host ruby>")

executes in the host process and can read or modify host state, spawn processes, and so on.

Impact

Complete sandbox escape leading to remote code execution in the host process, defeating the gem's central guarantee of isolating untrusted mruby scripts. Any deployment that runs untrusted or attacker-influenced scripts is affected. All released versions (0.1.0 through 0.9.0) are vulnerable; the dispatcher carried the same unguarded public_send sink under three successive names (registry → rpc → transport).

Patches

Fixed in 0.9.1. The dispatcher now rejects any method whose resolved owner is a core/meta module (BasicObject, Kernel, Object, Module, Class), so only methods the bound object itself defines — or dynamically handles via method_missing — remain reachable. The ambient reflection methods (send, __send__, public_send, instance_eval, instance_exec, method, instance_variable_get, …) are all owned by those modules and are blocked.

Workarounds

None within the affected versions. Until you can upgrade, do not bind any host Service object into a sandbox that runs untrusted scripts. Upgrade to 0.9.1.

References

GHSA-7pwq-q9jf-539h
Fix commit: 64f8470

Credits

Reported and fixed by Ahmed Al Hafoudh.

Affected versions


          0.1.0


          0.1.1


          0.1.2


          0.2.0


          0.2.1


          0.3.0


          0.4.0


          0.5.0


          0.6.0


          0.6.1


          0.6.2


          0.7.0

+ 2 more


            0.8.0


            0.9.0

Fixed in


          0.9.1

References

Updated Aug 18, 2026 · Source: OSV.dev

May 28, 2026

0.5.0 minor

1 CVE

CVE-2026-55107 GHSA-7pwq-q9jf-539h Aug 18, 2026

kobako Sandbox Escape: guest eval reaches host RCE via method_missing → public_send (any bound Service)

10.0 / 10

Critical

Network Low None None Changed High High High

Summary

A guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox.

Details

A host embeds bound "Service" objects that guest scripts call across the wasm boundary through the transport dispatcher. The dispatcher passed the guest-supplied method name straight to Object#public_send on the bound object, with no restriction to the object's own methods:

target.public_send(method.to_sym, *args, **kwargs, &block)

public_send can invoke any public method, including Ruby's ambient reflection surface. A guest pivots through the public send into otherwise private Kernel methods: a dispatch request with method = "send" and args = [:eval, "<ruby>"] evaluates to target.send(:eval, "<ruby>"), running attacker-controlled Ruby in the host. Any bound Service object is sufficient — no Service-specific behavior is required.

Proof of Concept

A guest call equivalent to:

Service.send(:eval, "<arbitrary host ruby>")

executes in the host process and can read or modify host state, spawn processes, and so on.

Impact

Complete sandbox escape leading to remote code execution in the host process, defeating the gem's central guarantee of isolating untrusted mruby scripts. Any deployment that runs untrusted or attacker-influenced scripts is affected. All released versions (0.1.0 through 0.9.0) are vulnerable; the dispatcher carried the same unguarded public_send sink under three successive names (registry → rpc → transport).

Patches

Fixed in 0.9.1. The dispatcher now rejects any method whose resolved owner is a core/meta module (BasicObject, Kernel, Object, Module, Class), so only methods the bound object itself defines — or dynamically handles via method_missing — remain reachable. The ambient reflection methods (send, __send__, public_send, instance_eval, instance_exec, method, instance_variable_get, …) are all owned by those modules and are blocked.

Workarounds

None within the affected versions. Until you can upgrade, do not bind any host Service object into a sandbox that runs untrusted scripts. Upgrade to 0.9.1.

References

GHSA-7pwq-q9jf-539h
Fix commit: 64f8470

Credits

Reported and fixed by Ahmed Al Hafoudh.

Affected versions


          0.1.0


          0.1.1


          0.1.2


          0.2.0


          0.2.1


          0.3.0


          0.4.0


          0.5.0


          0.6.0


          0.6.1


          0.6.2


          0.7.0

+ 2 more


            0.8.0


            0.9.0

Fixed in


          0.9.1

References

Updated Aug 18, 2026 · Source: OSV.dev

May 27, 2026

0.4.0 minor

1 CVE

CVE-2026-55107 GHSA-7pwq-q9jf-539h Aug 18, 2026

kobako Sandbox Escape: guest eval reaches host RCE via method_missing → public_send (any bound Service)

10.0 / 10

Critical

Network Low None None Changed High High High

Summary

A guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox.

Details

A host embeds bound "Service" objects that guest scripts call across the wasm boundary through the transport dispatcher. The dispatcher passed the guest-supplied method name straight to Object#public_send on the bound object, with no restriction to the object's own methods:

target.public_send(method.to_sym, *args, **kwargs, &block)

public_send can invoke any public method, including Ruby's ambient reflection surface. A guest pivots through the public send into otherwise private Kernel methods: a dispatch request with method = "send" and args = [:eval, "<ruby>"] evaluates to target.send(:eval, "<ruby>"), running attacker-controlled Ruby in the host. Any bound Service object is sufficient — no Service-specific behavior is required.

Proof of Concept

A guest call equivalent to:

Service.send(:eval, "<arbitrary host ruby>")

executes in the host process and can read or modify host state, spawn processes, and so on.

Impact

Complete sandbox escape leading to remote code execution in the host process, defeating the gem's central guarantee of isolating untrusted mruby scripts. Any deployment that runs untrusted or attacker-influenced scripts is affected. All released versions (0.1.0 through 0.9.0) are vulnerable; the dispatcher carried the same unguarded public_send sink under three successive names (registry → rpc → transport).

Patches

Fixed in 0.9.1. The dispatcher now rejects any method whose resolved owner is a core/meta module (BasicObject, Kernel, Object, Module, Class), so only methods the bound object itself defines — or dynamically handles via method_missing — remain reachable. The ambient reflection methods (send, __send__, public_send, instance_eval, instance_exec, method, instance_variable_get, …) are all owned by those modules and are blocked.

Workarounds

None within the affected versions. Until you can upgrade, do not bind any host Service object into a sandbox that runs untrusted scripts. Upgrade to 0.9.1.

References

GHSA-7pwq-q9jf-539h
Fix commit: 64f8470

Credits

Reported and fixed by Ahmed Al Hafoudh.

Affected versions


          0.1.0


          0.1.1


          0.1.2


          0.2.0


          0.2.1


          0.3.0


          0.4.0


          0.5.0


          0.6.0


          0.6.1


          0.6.2


          0.7.0

+ 2 more


            0.8.0


            0.9.0

Fixed in


          0.9.1

References

Updated Aug 18, 2026 · Source: OSV.dev

May 22, 2026

0.3.0 minor

1 CVE

CVE-2026-55107 GHSA-7pwq-q9jf-539h Aug 18, 2026

kobako Sandbox Escape: guest eval reaches host RCE via method_missing → public_send (any bound Service)

10.0 / 10

Critical

Network Low None None Changed High High High

Summary

A guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox.

Details

A host embeds bound "Service" objects that guest scripts call across the wasm boundary through the transport dispatcher. The dispatcher passed the guest-supplied method name straight to Object#public_send on the bound object, with no restriction to the object's own methods:

target.public_send(method.to_sym, *args, **kwargs, &block)

public_send can invoke any public method, including Ruby's ambient reflection surface. A guest pivots through the public send into otherwise private Kernel methods: a dispatch request with method = "send" and args = [:eval, "<ruby>"] evaluates to target.send(:eval, "<ruby>"), running attacker-controlled Ruby in the host. Any bound Service object is sufficient — no Service-specific behavior is required.

Proof of Concept

A guest call equivalent to:

Service.send(:eval, "<arbitrary host ruby>")

executes in the host process and can read or modify host state, spawn processes, and so on.

Impact

Complete sandbox escape leading to remote code execution in the host process, defeating the gem's central guarantee of isolating untrusted mruby scripts. Any deployment that runs untrusted or attacker-influenced scripts is affected. All released versions (0.1.0 through 0.9.0) are vulnerable; the dispatcher carried the same unguarded public_send sink under three successive names (registry → rpc → transport).

Patches

Fixed in 0.9.1. The dispatcher now rejects any method whose resolved owner is a core/meta module (BasicObject, Kernel, Object, Module, Class), so only methods the bound object itself defines — or dynamically handles via method_missing — remain reachable. The ambient reflection methods (send, __send__, public_send, instance_eval, instance_exec, method, instance_variable_get, …) are all owned by those modules and are blocked.

Workarounds

None within the affected versions. Until you can upgrade, do not bind any host Service object into a sandbox that runs untrusted scripts. Upgrade to 0.9.1.

References

GHSA-7pwq-q9jf-539h
Fix commit: 64f8470

Credits

Reported and fixed by Ahmed Al Hafoudh.

Affected versions


          0.1.0


          0.1.1


          0.1.2


          0.2.0


          0.2.1


          0.3.0


          0.4.0


          0.5.0


          0.6.0


          0.6.1


          0.6.2


          0.7.0

+ 2 more


            0.8.0


            0.9.0

Fixed in


          0.9.1

References

Updated Aug 18, 2026 · Source: OSV.dev

May 20, 2026

0.2.1 patch

1 CVE

CVE-2026-55107 GHSA-7pwq-q9jf-539h Aug 18, 2026

kobako Sandbox Escape: guest eval reaches host RCE via method_missing → public_send (any bound Service)

10.0 / 10

Critical

Network Low None None Changed High High High

Summary

A guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox.

Details

A host embeds bound "Service" objects that guest scripts call across the wasm boundary through the transport dispatcher. The dispatcher passed the guest-supplied method name straight to Object#public_send on the bound object, with no restriction to the object's own methods:

target.public_send(method.to_sym, *args, **kwargs, &block)

public_send can invoke any public method, including Ruby's ambient reflection surface. A guest pivots through the public send into otherwise private Kernel methods: a dispatch request with method = "send" and args = [:eval, "<ruby>"] evaluates to target.send(:eval, "<ruby>"), running attacker-controlled Ruby in the host. Any bound Service object is sufficient — no Service-specific behavior is required.

Proof of Concept

A guest call equivalent to:

Service.send(:eval, "<arbitrary host ruby>")

executes in the host process and can read or modify host state, spawn processes, and so on.

Impact

Complete sandbox escape leading to remote code execution in the host process, defeating the gem's central guarantee of isolating untrusted mruby scripts. Any deployment that runs untrusted or attacker-influenced scripts is affected. All released versions (0.1.0 through 0.9.0) are vulnerable; the dispatcher carried the same unguarded public_send sink under three successive names (registry → rpc → transport).

Patches

Fixed in 0.9.1. The dispatcher now rejects any method whose resolved owner is a core/meta module (BasicObject, Kernel, Object, Module, Class), so only methods the bound object itself defines — or dynamically handles via method_missing — remain reachable. The ambient reflection methods (send, __send__, public_send, instance_eval, instance_exec, method, instance_variable_get, …) are all owned by those modules and are blocked.

Workarounds

None within the affected versions. Until you can upgrade, do not bind any host Service object into a sandbox that runs untrusted scripts. Upgrade to 0.9.1.

References

GHSA-7pwq-q9jf-539h
Fix commit: 64f8470

Credits

Reported and fixed by Ahmed Al Hafoudh.

Affected versions


          0.1.0


          0.1.1


          0.1.2


          0.2.0


          0.2.1


          0.3.0


          0.4.0


          0.5.0


          0.6.0


          0.6.1


          0.6.2


          0.7.0

+ 2 more


            0.8.0


            0.9.0

Fixed in


          0.9.1

References

Updated Aug 18, 2026 · Source: OSV.dev

May 17, 2026

0.2.0 minor

1 CVE

CVE-2026-55107 GHSA-7pwq-q9jf-539h Aug 18, 2026

kobako Sandbox Escape: guest eval reaches host RCE via method_missing → public_send (any bound Service)

10.0 / 10

Critical

Network Low None None Changed High High High

Summary

A guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox.

Details

A host embeds bound "Service" objects that guest scripts call across the wasm boundary through the transport dispatcher. The dispatcher passed the guest-supplied method name straight to Object#public_send on the bound object, with no restriction to the object's own methods:

target.public_send(method.to_sym, *args, **kwargs, &block)

public_send can invoke any public method, including Ruby's ambient reflection surface. A guest pivots through the public send into otherwise private Kernel methods: a dispatch request with method = "send" and args = [:eval, "<ruby>"] evaluates to target.send(:eval, "<ruby>"), running attacker-controlled Ruby in the host. Any bound Service object is sufficient — no Service-specific behavior is required.

Proof of Concept

A guest call equivalent to:

Service.send(:eval, "<arbitrary host ruby>")

executes in the host process and can read or modify host state, spawn processes, and so on.

Impact

Complete sandbox escape leading to remote code execution in the host process, defeating the gem's central guarantee of isolating untrusted mruby scripts. Any deployment that runs untrusted or attacker-influenced scripts is affected. All released versions (0.1.0 through 0.9.0) are vulnerable; the dispatcher carried the same unguarded public_send sink under three successive names (registry → rpc → transport).

Patches

Fixed in 0.9.1. The dispatcher now rejects any method whose resolved owner is a core/meta module (BasicObject, Kernel, Object, Module, Class), so only methods the bound object itself defines — or dynamically handles via method_missing — remain reachable. The ambient reflection methods (send, __send__, public_send, instance_eval, instance_exec, method, instance_variable_get, …) are all owned by those modules and are blocked.

Workarounds

None within the affected versions. Until you can upgrade, do not bind any host Service object into a sandbox that runs untrusted scripts. Upgrade to 0.9.1.

References

GHSA-7pwq-q9jf-539h
Fix commit: 64f8470

Credits

Reported and fixed by Ahmed Al Hafoudh.

Affected versions


          0.1.0


          0.1.1


          0.1.2


          0.2.0


          0.2.1


          0.3.0


          0.4.0


          0.5.0


          0.6.0


          0.6.1


          0.6.2


          0.7.0

+ 2 more


            0.8.0


            0.9.0

Fixed in


          0.9.1

References

Updated Aug 18, 2026 · Source: OSV.dev

May 16, 2026

0.1.2 patch

1 CVE

CVE-2026-55107 GHSA-7pwq-q9jf-539h Aug 18, 2026

kobako Sandbox Escape: guest eval reaches host RCE via method_missing → public_send (any bound Service)

10.0 / 10

Critical

Network Low None None Changed High High High

Summary

A guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox.

Details

A host embeds bound "Service" objects that guest scripts call across the wasm boundary through the transport dispatcher. The dispatcher passed the guest-supplied method name straight to Object#public_send on the bound object, with no restriction to the object's own methods:

target.public_send(method.to_sym, *args, **kwargs, &block)

public_send can invoke any public method, including Ruby's ambient reflection surface. A guest pivots through the public send into otherwise private Kernel methods: a dispatch request with method = "send" and args = [:eval, "<ruby>"] evaluates to target.send(:eval, "<ruby>"), running attacker-controlled Ruby in the host. Any bound Service object is sufficient — no Service-specific behavior is required.

Proof of Concept

A guest call equivalent to:

Service.send(:eval, "<arbitrary host ruby>")

executes in the host process and can read or modify host state, spawn processes, and so on.

Impact

Complete sandbox escape leading to remote code execution in the host process, defeating the gem's central guarantee of isolating untrusted mruby scripts. Any deployment that runs untrusted or attacker-influenced scripts is affected. All released versions (0.1.0 through 0.9.0) are vulnerable; the dispatcher carried the same unguarded public_send sink under three successive names (registry → rpc → transport).

Patches

Fixed in 0.9.1. The dispatcher now rejects any method whose resolved owner is a core/meta module (BasicObject, Kernel, Object, Module, Class), so only methods the bound object itself defines — or dynamically handles via method_missing — remain reachable. The ambient reflection methods (send, __send__, public_send, instance_eval, instance_exec, method, instance_variable_get, …) are all owned by those modules and are blocked.

Workarounds

None within the affected versions. Until you can upgrade, do not bind any host Service object into a sandbox that runs untrusted scripts. Upgrade to 0.9.1.

References

GHSA-7pwq-q9jf-539h
Fix commit: 64f8470

Credits

Reported and fixed by Ahmed Al Hafoudh.

Affected versions


          0.1.0


          0.1.1


          0.1.2


          0.2.0


          0.2.1


          0.3.0


          0.4.0


          0.5.0


          0.6.0


          0.6.1


          0.6.2


          0.7.0

+ 2 more


            0.8.0


            0.9.0

Fixed in


          0.9.1

References

Updated Aug 18, 2026 · Source: OSV.dev

May 14, 2026

0.1.1 patch

1 CVE

CVE-2026-55107 GHSA-7pwq-q9jf-539h Aug 18, 2026

kobako Sandbox Escape: guest eval reaches host RCE via method_missing → public_send (any bound Service)

10.0 / 10

Critical

Network Low None None Changed High High High

Summary

A guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox.

Details

A host embeds bound "Service" objects that guest scripts call across the wasm boundary through the transport dispatcher. The dispatcher passed the guest-supplied method name straight to Object#public_send on the bound object, with no restriction to the object's own methods:

target.public_send(method.to_sym, *args, **kwargs, &block)

public_send can invoke any public method, including Ruby's ambient reflection surface. A guest pivots through the public send into otherwise private Kernel methods: a dispatch request with method = "send" and args = [:eval, "<ruby>"] evaluates to target.send(:eval, "<ruby>"), running attacker-controlled Ruby in the host. Any bound Service object is sufficient — no Service-specific behavior is required.

Proof of Concept

A guest call equivalent to:

Service.send(:eval, "<arbitrary host ruby>")

executes in the host process and can read or modify host state, spawn processes, and so on.

Impact

Complete sandbox escape leading to remote code execution in the host process, defeating the gem's central guarantee of isolating untrusted mruby scripts. Any deployment that runs untrusted or attacker-influenced scripts is affected. All released versions (0.1.0 through 0.9.0) are vulnerable; the dispatcher carried the same unguarded public_send sink under three successive names (registry → rpc → transport).

Patches

Fixed in 0.9.1. The dispatcher now rejects any method whose resolved owner is a core/meta module (BasicObject, Kernel, Object, Module, Class), so only methods the bound object itself defines — or dynamically handles via method_missing — remain reachable. The ambient reflection methods (send, __send__, public_send, instance_eval, instance_exec, method, instance_variable_get, …) are all owned by those modules and are blocked.

Workarounds

None within the affected versions. Until you can upgrade, do not bind any host Service object into a sandbox that runs untrusted scripts. Upgrade to 0.9.1.

References

GHSA-7pwq-q9jf-539h
Fix commit: 64f8470

Credits

Reported and fixed by Ahmed Al Hafoudh.

Affected versions


          0.1.0


          0.1.1


          0.1.2


          0.2.0


          0.2.1


          0.3.0


          0.4.0


          0.5.0


          0.6.0


          0.6.1


          0.6.2


          0.7.0

+ 2 more


            0.8.0


            0.9.0

Fixed in


          0.9.1

References

Updated Aug 18, 2026 · Source: OSV.dev

May 13, 2026

0.1.0 initial

1 CVE

CVE-2026-55107 GHSA-7pwq-q9jf-539h Aug 18, 2026

kobako Sandbox Escape: guest eval reaches host RCE via method_missing → public_send (any bound Service)

10.0 / 10

Critical

Network Low None None Changed High High High

Summary

A guest mruby script running inside the Kobako sandbox can execute arbitrary Ruby in the host process, fully escaping the sandbox.

Details

A host embeds bound "Service" objects that guest scripts call across the wasm boundary through the transport dispatcher. The dispatcher passed the guest-supplied method name straight to Object#public_send on the bound object, with no restriction to the object's own methods:

target.public_send(method.to_sym, *args, **kwargs, &block)

public_send can invoke any public method, including Ruby's ambient reflection surface. A guest pivots through the public send into otherwise private Kernel methods: a dispatch request with method = "send" and args = [:eval, "<ruby>"] evaluates to target.send(:eval, "<ruby>"), running attacker-controlled Ruby in the host. Any bound Service object is sufficient — no Service-specific behavior is required.

Proof of Concept

A guest call equivalent to:

Service.send(:eval, "<arbitrary host ruby>")

executes in the host process and can read or modify host state, spawn processes, and so on.

Impact

Complete sandbox escape leading to remote code execution in the host process, defeating the gem's central guarantee of isolating untrusted mruby scripts. Any deployment that runs untrusted or attacker-influenced scripts is affected. All released versions (0.1.0 through 0.9.0) are vulnerable; the dispatcher carried the same unguarded public_send sink under three successive names (registry → rpc → transport).

Patches

Fixed in 0.9.1. The dispatcher now rejects any method whose resolved owner is a core/meta module (BasicObject, Kernel, Object, Module, Class), so only methods the bound object itself defines — or dynamically handles via method_missing — remain reachable. The ambient reflection methods (send, __send__, public_send, instance_eval, instance_exec, method, instance_variable_get, …) are all owned by those modules and are blocked.

Workarounds

None within the affected versions. Until you can upgrade, do not bind any host Service object into a sandbox that runs untrusted scripts. Upgrade to 0.9.1.

References

GHSA-7pwq-q9jf-539h
Fix commit: 64f8470

Credits

Reported and fixed by Ahmed Al Hafoudh.

Affected versions


          0.1.0


          0.1.1


          0.1.2


          0.2.0


          0.2.1


          0.3.0


          0.4.0


          0.5.0


          0.6.0


          0.6.1


          0.6.2


          0.7.0

+ 2 more


            0.8.0


            0.9.0

Fixed in


          0.9.1

References

Updated Aug 18, 2026 · Source: OSV.dev

May 13, 2026

Activity

Reach

Details