CubeSandbox: any host path mounted into a tenant's MicroVM

Upgrade to 0.5.1 or later (the latest release is 0.7.2). It includes #756, which only allows host-mount paths under configured prefixes.

1. Upgrade CubeMaster, CubeAPI and Cubelet on every node to 0.5.1 or later.
2. Review allowed_host_mount_prefixes under extra_conf in the CubeMaster config. Leave it at the default (/data/shared/) or list only the narrow directories tenants really need. Never list system paths or the Cubelet data directory (/data/cubelet).
3. Prefer read-only host mounts. A host-mount entry is still read-write unless the caller asks for readOnly.
4. Until you upgrade, do not let untrusted callers create sandboxes, or drop the host-mount key from the metadata of POST /sandboxes requests at your gateway.
5. If untrusted tenants could create sandboxes on an older version, treat the nodes as possibly compromised: check them for unexpected bind mounts under /data/cubelet/hostdir/ and rotate host and Cubelet credentials.

CubeSandbox runs untrusted, often LLM-generated code inside MicroVMs and sells hardware-level isolation as its core guarantee. Its host-mount feature lets a sandbox-create request ask for a host directory to be shared into the MicroVM. Before 0.5.1 nothing checked which directory: no authorization step, no allowlist, and no denylist. Any caller allowed to create a sandbox could mount any path on the Cubelet node, including /, and the mount was read-write unless the caller asked otherwise. The escape needs no kernel or VMM bug. It is a missing check in the control plane.

CubeSandbox before 0.5.1, in any deployment where a caller who is not fully trusted can create sandboxes. The host-mount path runs through CubeAPI, CubeMaster and Cubelet, and the issue was present from when the feature was added until the fix. Reviewed at cecb2e8 (v0.5.0 plus 8 commits, 2026-07-04). Fixed in 0.5.1 (2026-07-11).

A tenant creating a sandbox could set the Cube-specific host-mount metadata entry to any absolute host path. Cubelet then bind-mounted that path recursively, as root, into the share it exports to the guest over virtio-fs. With the host root mounted read-write, code inside the MicroVM could:

• Read any host file, such as /etc/shadow, host SSH keys, Cubelet's config and credentials, TLS keys, and the private key of the CubeEgress interception CA.
• Read other tenants' data. The rootfs and memory-snapshot files of every other sandbox on the node live under the Cubelet data directory on the same host.
• Take over the container runtime through the host's containerd socket, which controls every sandbox on the node.
• Run code on the host as root, by writing to the host filesystem (for example a cron entry, a systemd unit or root's SSH authorized_keys).

The only precondition is permission to call sandbox create, which is the normal baseline privilege of a tenant. The maintainer published the advisory as High.

Permalinks at cecb2e8, the commit reviewed before the fix.

• CubeAPI copies metadata["host-mount"] from the request body into the sandbox annotations with no validation: CubeAPI/src/services/sandboxes.rs#L172-L177
• The request arrives on the normal tenant route POST /sandboxes: CubeAPI/src/routes.rs#L119
• The auth middleware sends only the request path and method to the operator's auth callback, so the callback never sees the body and cannot deny a host mount: CubeAPI/src/middleware/auth.rs#L95-L102
• CubeMaster only checks that hostPath and mountPath start with /: CubeMaster/pkg/service/sandbox/hostdir_mount.go#L57-L66
• The direct volume API only checks that the fields are not empty: CubeMaster/pkg/service/sandbox/util.go#L631-L642
• Cubelet runs mount --rbind on the caller's path as root and remounts read-only only when asked: Cubelet/storage/hostdir.go#L76-L107

At this commit no feature flag, config option or allowlist in the repository gates or limits host-mount.

• #756 (merged 2026-07-05) adds validateHostPath() in CubeMaster. It cleans the path to remove .. and accepts it only if it falls under one of the allowed_host_mount_prefixes, which default to /data/shared/. It covers both the host-mount annotation and the direct volume API.
• The same PR makes CubeMaster refuse to start if / is listed as an allowed prefix, and documents path restriction and multi-tenant layouts for persistent storage.
• Released in 0.5.1 (2026-07-11). The check is still in place on master today.

On each Cubelet node, list active bind mounts under /data/cubelet/hostdir/ (for example with findmnt) and flag any whose source is outside the directories you meant to share, especially /, /etc, /root, /run or /data/cubelet. In CubeMaster logs, look for [hostdir] raw annotation lines and sandbox-create requests whose host-mount metadata names such paths. After upgrading, rejected requests return an error that the hostPath is not within an allowed mount prefix. A working exploit is withheld.

1. 2026-07-04Reported privately via GitHub PVR (GHSA-8frp-jfpv-5vhv), with a suggested fix.
2. 2026-07-05Maintainer merges #756 (host-mount path allowlist).
3. 2026-07-11CubeSandbox 0.5.1 released with the fix.
4. 2026-07-27We ask in #1184 for the advisory to be published, since the fix had shipped; the maintainer closes the issue the next day.
5. 2026-09-18Maintainer publishes GHSA-8frp-jfpv-5vhv as High.
6. 2026-09-23CVE ID requested from MITRE.
7. 2026-10-09We ask the maintainer in #1920 to request a CVE ID for the published advisory; public write-up.

Finder: Aaron Elijah Mars of Aeon. Tool: Aeon.

• Fix PR (merged 2026-07-05): TencentCloud/CubeSandbox#756
• Fixed release: CubeSandbox 0.5.1
• GitHub advisory: GHSA-8frp-jfpv-5vhv
• CVE: pending (requested from MITRE; maintainer also asked to request one from GitHub in #1920)
• Affected repository: TencentCloud/CubeSandbox