Skip to main content

LangAlpha EUVDEUVD-2026-104681

| CVE-2026-109441 MEDIUM
Improper Isolation or Compartmentalization (CWE-653)
2026-10-20 VulnCheck GHSA-g5q6-qcmx-6vw9
6.9
CVSS 4.0 · Vendor: VulnCheck
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Authenticate as a tenant
  2. Delivery
    Execute code in own sandbox container
  3. Exploit
    Scan shared Docker bridge for peer containers
  4. Execution
    Connect to victim container's exposed server
  5. Persist
    Bypass require_workspace_owner at network layer
  6. Impact
    Exfiltrate 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.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.9).
No patch listed yet 0.4% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – 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

LangAlpha 0 ≤2026.09.07

Affected Packages

euvd langalpha no fix

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

Vendor (VulnCheck) PRIMARY 6.9 MEDIUM
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
vuln.today AI 5.8 MEDIUM

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.

3.1 AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:N/A:N
4.0 AV:N/AC:H/AT:P/PR:L/UI:P/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector
Network
Attack Complexity
High
Attack Requirements
Present
Privileges Required
Low
User Interaction
Passive
Vulnerable system: Confidentiality
High
Vulnerable system: Integrity
None
Vulnerable system: Availability
None
Subsequent system: Confidentiality
High
Subsequent system: Integrity
None
Subsequent system: Availability
None

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

EPSS Score
0.4%
Top 71% exploitable
Prevalence
Rare
obscure open-source AI agent project, minimal production deployment footprint
Exploit
POC
Public exploit code exists
Data Quality
6 sources
Confidence: High

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.

SignalValue
Severity MEDIUM
CISA KEV No
Public POC Yes
EPSS 0.4%
Patch available No
Active threat No
Deciding rule
MEDIUM severity (CVSS 4.0-6.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation
Poc
System Exposure· derived
Open
Automatable
No
Human Impact· derived
Medium
Technical Impact
Partial

Priority Score

54
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +34
PoC: +20
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Remote Code Execution represents the critical moment when an attacker successfully runs arbitrary code on a target system without physical access.

Related Vulnerabilities in LangAlpha Prompt Injection and Isolation Flaws

View all 2

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy