‍Overview

LangAlpha (ginlix-ai/LangAlpha) runs each workspace's code in its own sandbox. In self-hosted deployments without a Daytona API key, the Docker sandbox provider places every workspace's container on Docker's default bridge network, where containers can reach each other directly.

‍

The HTTP API correctly checks workspace ownership, but a direct container-to-container connection never goes through the API. An attacker with code execution in one tenant's sandbox can therefore connect to another tenant's sandbox over the shared network and read its files, including the vault secrets file, whenever a server in that sandbox is listening on all interfaces, as the product's own preview-URL feature does.

‍

‍

Affected Product

ginlix-ai/LangAlpha

‍

Affected Files

• src/ptc_agent/config/core.py (DockerConfig.network_mode: str = "bridge", the default network for every sandbox container the Docker provider creates, with no per-workspace override in .env.example or docker-compose.yml)
• src/ptc_agent/core/sandbox/providers/docker.py (DockerProvider.create sets host_config["NetworkMode"] = self._config.network_mode with no additional isolation, ICC restriction, or per-tenant network; every sandbox container is named langalpha-sandbox-{id} on the shared bridge)
• src/server/utils/api.py (require_workspace_owner), src/server/app/vault.py, src/server/app/workspace_sandbox.py (ownership checks that gate the HTTP API only and have no bearing on a direct container-to-container network path)
• src/ptc_agent/core/sandbox/vault_helper.py (writes the vault secrets file under the workspace working directory, which a directory-serving process bound to 0.0.0.0 would expose to the flat network)

Root Cause

The Docker sandbox provider, which is the fallback for any self-hosted deployment with DAYTONA_API_KEY unset, creates every workspace's container with NetworkMode set to DockerConfig.network_mode, whose default is bridge: Docker's shared default bridge network, with inter-container communication enabled and no per-workspace segmentation.

‍

An attacker who has code execution in one tenant's sandbox can therefore open a direct network connection to a different tenant's sandbox container over that shared bridge. This bypasses the require_workspace_owner ownership checks that correctly gate every vault and sandbox-stats endpoint in the HTTP API, because a container-to-container connection never touches the API. The vault secrets file lives under the workspace working directory, and the product's own preview-URL feature binds agent-started servers to 0.0.0.0, so a server in one tenant's sandbox is reachable from another tenant's sandbox on the shared network.

‍

‍

PoC

Confirmed empirically on a self-hosted deployment (fake CANARY string only; the live SaaS was never contacted), using the repo's verbatim DockerProvider and DockerConfig against the repo's own langalpha-sandbox:latest image:

1. Create two independent sandboxes with DockerConfig() defaults, exactly as the app creates one per workspace.

2. Write a fake vault secret (CANARY_VAULT_SECRET=lasso_security_canary_do_not_use) into tenant B's sandbox at the real path {working_dir}/_internal/.vault_secrets.json.

3. Start python3 -m http.server bound to 0.0.0.0 inside tenant B's container, serving its working directory (the same bind pattern the preview-URL feature uses).

4. From inside tenant A's separate sandbox, run curl against tenant B's container IP on the Docker bridge, with no HTTP API call, no workspace_id, and no auth token.

Tenant A retrieved tenant B's fake vault secret (cross_tenant_secret_read=True). The host's default bridge reported enable_icc:true, which is Docker's documented default whenever network_mode is not explicitly overridden.

‍

Impact

Once an attacker has code execution in any one tenant's sandbox, the shared unsegmented bridge network lets them read a different tenant's sandbox files directly over the network, bypassing the HTTP API ownership checks entirely.

‍

This was confirmed as a cross-tenant read; write or code-execution access into another tenant's sandbox was not demonstrated. Whether the hosted product runs this same Docker provider in production, or Daytona's hosted infrastructure with different isolation, was not tested.

‍

Suggested Remediation

Give each workspace's Docker sandbox its own isolated network, or at minimum disable inter-container communication on the shared bridge and add explicit, allow-listed egress only, so one tenant's sandbox cannot reach another tenant's sandbox container at the network layer.

This closes the escalation to cross-tenant independently of whether the sandbox code-execution path is fixed.

‍

Additional Resources

• CVE-2026-109441 record

‍