Summary
Soft Machine improperly accepts a global container secret as a bearer token without confirming that the caller belongs to the requested workspace. Because the secret is shared across containers and exposed to workspace processes, a tenant may authenticate to another tenant's workspace API and perform unauthorized read, write, or destructive restore operations.
Affected context
The issue affects Soft Machine deployments using the vulnerable authentication helpers in the server component. Risk is present when the same CONTAINER_SHARED_SECRET is configured across containers, is accessible from a user-facing workspace process, and is accepted for workspace API authentication without a corresponding workspace-ownership check. The per-workspace token validation path may remain protected while the shared-secret path bypasses that control.
Exploit preconditions
- Attack surface: Workspace HTTP APIs exposed by the Soft Machine server
- Required access: A shell or equivalent execution capability in any paying customer's workspace
- Credential availability: Access to the globally shared
CONTAINER_SHARED_SECRETthrough the workspace process environment - Trigger point: Authentication requests handled by
verifyContainerAuth()orauthenticateWorkspaceHttp() - Why exploitation is possible: The shared-secret bearer path authenticates the request without verifying that the caller belongs to the target workspace
Why this happens
The underlying flaw is an authorization-boundary failure mapped to CWE-863: Incorrect Authorization. Authentication with a broadly shared credential is treated as sufficient authorization for workspace-specific operations, even though the credential does not identify or constrain the caller to a particular tenant. This creates an insecure pattern in which a global service secret bypasses the per-workspace authorization check.
Potential impact
- An attacker may read data belonging to other workspaces.
- An attacker could modify another tenant's workspace state or resources.
- An attacker may invoke destructive restore operations against an unrelated workspace.
- Cross-tenant activity can result in data loss, service disruption, or confidentiality breaches.
- The shared-secret design could increase the blast radius of a compromise within one workspace.
General mitigation guidance
Mitigation generally focuses on making authorization workspace-aware on every
authentication path.
Common defensive patterns include:
- Requiring scoped, per-workspace credentials for workspace-specific APIs.
- Binding authenticated identities and tokens to an explicit workspace or tenant identifier.
- Removing global shared secrets from user-facing process environments where possible.
- Ensuring every bearer-token path performs the same workspace authorization checks as the per-workspace token path.
- Applying least privilege to workspace API capabilities and separating read, write, and destructive operations.
- Failing closed when workspace identity, token scope, or tenant association cannot be established.
- Auditing existing credentials and sessions after suspected cross-workspace exposure.
How teams detect issues like this
Organizations can detect this class of issue through:
- Static analysis and code review searches for global secrets accepted by tenant-scoped endpoints.
- Review of authentication helpers to confirm that identity verification is followed by resource authorization.
- Integration tests that attempt to use credentials from one workspace against another workspace's API.
- Monitoring for cross-workspace requests, unusual restore operations, and bearer tokens reused across tenant boundaries.
- Policy checks that prohibit unscoped credentials in multi-tenant services and prevent sensitive secrets from being exposed to user-controlled processes.
Automated application-security review tools may help identify authentication paths that lack tenant or resource authorization checks.
