What happened
The GitHub security advisory confirms the auth helpers accept the global CONTAINER_SHARED_SECRET as a bearer token without verifying which workspace the caller belongs to. Since the secret is identical on every container and reachable from tenant shells, any tenant can reach any other tenant's workspace API and obtain cross-workspace read, write, upload, backup-hijack, and destructive-restore primitives. A working request-level PoC (one header per primitive) is documented in the advisory.
Why it matters
This is a zero-permission cross-tenant capability ladder in an agentic development/cloud-OS platform: attacker-controlled read of victim source, .git history, secrets and user data, plus write into victim workspaces (supply-chain seeding) and destructive restore. An agentic platform holding customer code is entirely compromised by any single paying tenant.
Attack vector
From a shell inside any active workspace, an attacker presents the app-wide CONTAINER_SHARED_SECRET (injected into every container's user-facing environment) as a Bearer token to a peer workspace's /archive, /upload-file, /backup, /restore, or /bind endpoints. Auth helpers verifyContainerAuth()/authenticateWorkspaceHttp() accept the secret with no workspace/audience binding.
Affected systems
Soft Machine (agentic VM-based development environment/Cloud OS) versions 0.2.247 and prior
Mitigation
Upgrade to a patched Soft Machine release (> 0.2.247) per advisory GHSA-63gh-vp9f-vxhj; until then isolate workspaces and restrict the shared secret's reachability.