Summary
Soft Machine's workspace HTTP service exposes file and archive endpoints without authentication or origin checks, allowing reachable peers to access workspace data. An attacker able to reach TCP port 8080 on a workspace may read files beneath its workspace root or download project trees as archives.
Affected context
The issue occurs in Soft Machine workspaces where the internal HTTP service listens on 0.0.0.0:8080 and exposes health, file, and archive endpoints without verifying the caller's identity or origin. Because workspaces on the same Fly application or organization can share private network reachability and resolve peer addresses through an unauthenticated service-discovery record, the workspace-owner boundary may not be enforced.
Exploit preconditions
- Attack surface: The workspace HTTP service on TCP port 8080
- Required access: Network reachability to the target workspace, including access from another reachable workspace
- Trigger point: Requests to file-reading or directory-archive endpoints
- Why exploitation is possible: The service does not require authentication or validate the request origin before serving workspace content
Why this happens
The underlying bug is a missing authentication control on sensitive HTTP endpoints. The service treats network reachability as sufficient authorization and exposes filesystem-backed operations without establishing that the caller is the workspace owner or an approved service. This maps to CWE-306, which covers missing authentication for functionality that requires identity verification.
Potential impact
- An attacker may read source code, configuration files, and other data within a workspace
- An attacker could download complete project trees as archive files
- Exposed secrets or tokens could enable further unauthorized access
- Workspace confidentiality may be reduced across tenants or peer machines
General mitigation guidance
Mitigation generally focuses on enforcing authentication and authorization
at every filesystem-backed endpoint rather than relying on private network
placement.
Common defensive patterns include:
- Require strong, workspace-scoped authentication for file and archive operations
- Authorize each request against the specific workspace and requested path
- Use authenticated service-to-service identity instead of unauthenticated peer discovery
- Restrict listener exposure and apply network policies that limit workspace-to-workspace access
- Constrain file access to an explicitly permitted root and reject traversal or ambiguous path forms
- Run workspace services with least-privilege filesystem and network permissions
- Keep health checks limited to non-sensitive status information
How teams detect issues like this
Organizations can look for:
- Static analysis findings where HTTP handlers access filesystem paths without authentication middleware
- Code review signals such as wildcard listeners, missing origin validation, and authorization checks absent from sensitive routes
- Integration tests that attempt file and archive requests from an unauthorized peer
- Network policy reviews verifying that private connectivity does not implicitly grant application access
- Runtime monitoring for unexpected requests to file and archive endpoints or unusually broad archive downloads
- Policy enforcement requiring authenticated identity and resource-level authorization for internal APIs
