Soft Machine EUVD-2026-90190

Attacker must be an authenticated paying tenant (PR:L) running Soft Machine version 0.2.247 or earlier, with access to a workspace shell where the global CONTAINER_SHARED_SECRET is readable from the user-facing process environment. Exploitation consists of presenting that shared secret as a bearer token to another tenant's workspace HTTP API, which verifyContainerAuth() and authenticateWorkspaceHttp() accept without validating workspace ownership (the workspaceTokenMatches per-workspace check is bypassed entirely on the shared-secret path). Limiting factors: requires a valid (paid) account, adjacent/internal network reachability to the target workspace API (AV:A), and no user interaction; no patch is available, so only mitigations like rotating/segregating secrets or restricting the internal API apply.

This is a genuine high-priority multi-tenancy isolation failure, not an inflated CVSS number. The CWE-863 (improper authorization) flaw lets any authenticated tenant present the globally-shared CONTAINER_SHARED_SECRET as a bearer token to reach ANY other tenant's workspace API, yielding cross-workspace read, write, and destructive-restore primitives - hence the S:C (scope change) and full C:H/I:H/A:H that drive the 9.0 base score. The exploitation barrier is low once inside the platform: AC:L and PR:L mean any paying customer with a workspace shell (where the secret is already exposed in the process environment) can weaponize it with trivial effort. Tempering factors: AV:A limits reach to the platform's internal/adjacent network rather than the open Internet, and PR:L requires a valid (paid) account. No EPSS score, CISA KEV entry, or public POC was provided, so exploitation is 'no public exploit identified at time of analysis' - but the trivial mechanics (reuse an already-readable environment secret) mean a working exploit is cheap to develop. One signal to verify: the vendor selected AV:A, yet a workspace-to-workspace HTTP API call could arguably be AV:N depending on network topology - confirm with the vendor whether the API is exposed beyond the internal Fly network. Notably, there is no patch at publication, so no remediation floor exists.

A paying customer opens a shell in their own Soft Machine workspace and reads CONTAINER_SHARED_SECRET from the process environment. They send an HTTP request to another tenant's workspace API endpoint using that secret as a bearer token; verifyContainerAuth()/authenticateWorkspaceHttp() accept it without checking workspace ownership, granting read/write and destructive-restore access to the victim tenant's data. No public exploit code is known, but the attack requires only a valid paid account and basic HTTP tooling.