Impact

A tenant with a workspace token can perform unauthorized read and write operations on the underlying worker filesystem, potentially resulting in cross-tenant data exposure and host system compromise.

Recommendation

Patch all Beta9 deployments by upgrading the gateway component to version 0.1.776 or later and the worker component to version 0.1.756 or later. These versions implement strict validation of volume identifiers and ownership checks.

Attack Chain

1. Attacker gains access to a valid tenant workspace token.
2. Attacker initiates or uses an active sandbox session.
3. Attacker crafts a file path containing sequences that bypass the mount destination prefix check.
4. The getHostPathFromContainerPath function resolves the malicious path to an absolute path on the host worker filesystem.
5. The file API calls (Upload, download, stat, list, find-in-files, replace-in-files, or delete-file) interact with the resolved host path.
6. The attacker reads or modifies sensitive host files, such as the Kubernetes service account token.
7. If applicable, the attacker uses the stolen service account token to achieve cluster-admin access.

Impact

An attacker can achieve full read, write, and delete access to the host worker filesystem as root. This allows for the exfiltration of data from other tenants on the same worker and potential cluster-wide privilege escalation if the worker pod is configured with elevated Kubernetes permissions.

Recommendation

• Upgrade the Beta9 worker to version 0.1.756 or later immediately to implement os.OpenRoot for sandbox file operations.
• Audit Kubernetes RBAC configurations for worker pods to ensure the principle of least privilege is applied, specifically restricting cluster-admin access for worker pods.
• Review access logs for the sandbox file API for anomalous path requests involving multiple parent-directory segments.