Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate as a tenant
-
DeliveryExecute code in own sandbox container
-
ExploitScan shared Docker bridge for peer containers
-
ExecutionConnect to victim container's exposed server
-
PersistBypass require_workspace_owner at network layer
-
ImpactExfiltrate vault secrets and sensitive files
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V15 - Secure Coding and Architecture Component isolation
|
| Exploitation Conditions | Requires a multi-tenant LangAlpha deployment where each tenant's sandbox runs as a Docker container on the default bridge network with inter-container communication (ICC) enabled - Docker's default behavior, so this is not a setting the operator must opt into. The attacker must be an authenticated tenant able to execute code inside their own sandbox (PR:L), and a victim tenant must concurrently run an exposed, network-listening server in its container that holds secrets (the AT:P/UI:P target-present condition). Exploitation is LIMITED by: mandatory authentication, the need to already achieve code execution in one's own sandbox, the requirement that a co-tenant have an exposed service running at the time of attack, and the discovery/timing effort of locating peer containers (AC:H). Deployments that isolate tenants on per-tenant Docker networks, disable ICC, or run single-tenant are not exposed. |
| Impact | This is a genuine but conditional multi-tenant isolation flaw, best treated as a medium-priority issue rather than a drop-everything emergency. The input CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:L/UI:P) scores 6.9 and tells a consistent story: a network-reachable attack that nonetheless requires authenticated access (PR:L), high complexity (AC:H), a present/active target condition (AT:P), and victim-side interaction (UI:P), with impact limited to confidentiality on both the vulnerable and a subsequent system (VC:H/SC:H; VI/VA/SI/SA:N). Public exploit code exists (reported by VulnCheck, with a Lasso Security write-up), which raises practical risk, but there is no CISA KEV listing and no EPSS score was supplied, so there is no evidence of active or widespread exploitation - publicly available exploit code must not be conflated with in-the-wild use. Real-world risk is gated hard by preconditions: the attacker must already be an authenticated tenant able to run code in their own sandbox, and a co-located victim tenant must run an exposed server holding secrets. The signals are broadly consistent (no conflict between the 'network' vector and the authenticated/code-execution precondition, since the hop is container-to-container over the shared Docker bridge). The dominant mitigating reality is deployment footprint: LangAlpha is a niche open-source AI agent project, so this is a high-quality vulnerability in a low-prevalence product. |
| Exploit ScenarioDerived | A paying or trial tenant on a shared LangAlpha instance runs attacker code inside their own sandbox container, then uses it to reach across Docker's default bridge network to another tenant's container listening on an internal service. Because inter-container communication is enabled and require_workspace_owner checks are bypassed at the network layer, the attacker reads that tenant's exposed files - including vault secrets. Public exploit code is available, lowering the skill barrier, though success depends on a victim tenant actively running an exposed server. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 20, 2026
Cross-tenant container access in LangAlpha through 2026.09.07 allows an authenticated tenant who can execute code inside their own sandbox container to reach peer tenants' containers over Docker's shared default bridge network and read sensitive data such as vault secrets. Because inter-container communication is enabled by default and every tenant sandbox sits on that same bridge, the platform's require_workspace_owner authorization checks are effectively bypassed for traffic originating from a sibling container. Publicly available exploit code exists and the flaw is tracked as CWE-653 (Improper Isolation or Compartmentalization); exploitation requires a multi-tenant deployment, prior code execution in one's own sandbox (PR:L), and a co-tenant running an exposed, network-listening service that holds secrets, so this is best treated as a medium-priority, conditional isolation defect rather than an emergency.
RemediationAI
No vendor-released patch was identified at time of analysis - the public references point to the offending configuration source rather than a fixed release, so operators should confirm with ginlix-ai whether a build later than 2026.09.07 addresses the network topology before relying on an upgrade. Until then, the highest-value fix is architectural and can be applied immediately: move each tenant sandbox onto its own user-defined Docker bridge network (for example 'langalpha-tenant-<id>') so Docker's default deny between distinct networks provides tenant separation, or, if a shared network must remain, recreate the bridge with inter-container communication disabled (--icc=false, or 'com.docker.network.bridge.enable_icc=false' in daemon.json) and add explicit links only where a sandbox legitimately needs a peer service - the trade-off is that any internal service discovery or sidecar communication in the platform must be re-plumbed through published ports, links, or an overlay/CNI layer, and a daemon-wide ICC change affects every container on the host. Additionally, stop running secret-bearing, network-listening services (Vault agents, token brokers, internal APIs) inside tenant sandbox containers or on the shared bridge; front them with an authenticated proxy on a dedicated network that sandboxes cannot route to. Where short-term mitigation is needed, egress-restrict sandbox containers with a default-deny network policy that permits only their intended upstream, and rotate any Vault tokens or workspace secrets that were reachable from co-tenant containers during the exposure window, since a successful cross-tenant read would not appear in the application's own authorization logs.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
LangAlpha provisions each tenant's code-execution sandbox as a Docker container. The configuration referenced in the vendor repository (src/ptc_agent/config/core.py, line 295) leaves containers attached to Docker's built-in 'default' bridge network, which enables inter-container communication (ICC) by default - containers on that bridge can reach one another by IP without any published port. Because all tenants share that single flat L2/L3 segment, the intended application-layer boundary (the require_workspace_owner authorization check that should gate access to a workspace's files and secrets) is never enforced for east-west traffic; a request arriving from another sandbox appears to originate inside the trusted network rather than from an untrusted tenant. The weakness class, CWE-653 (Improper Isolation or Compartmentalization), is exactly this: a shared trust domain where separate principals should have had separate ones. The tags (Docker, Hashicorp, RCE) suggest the practical prize is secrets held in or proxied through a co-tenant's container - for example a HashiCorp Vault client/server process or an injected Vault token - that an attacker reads once they can reach the peer's listening port. The correct design uses per-tenant user-defined bridge networks (which do not permit cross-network traffic by default) or an explicit --icc=false policy with only required links, so that container-to-container reachability is not the default.
Know when Langalpha gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N
Attacker needs authenticated sandbox code execution (PR:L) and a victim with an exposed server present (AC:H/UI:R); crossing into another tenant's container changes scope (S:C) with confidentiality-only impact.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
DescriptionCVE.org
LangAlpha through 2026.09.07 contains an improper isolation vulnerability that places all tenants' sandbox containers on Docker's shared default bridge network with inter-container communication enabled. Authenticated users with code execution in their own sandbox can connect directly to other tenants' containers, bypassing require_workspace_owner checks to read files such as vault secrets from exposed servers.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.
EUVD-2026-104681
GHSA-g5q6-qcmx-6vw9
NVD
CVE.org
EPSS
Vulnrichment
Exploit-DB