CVE-2026-97693 in Yuxi
Summary
by MITRE • 11/04/2026
Yuxi is a large-model-based intelligent knowledge base and knowledge graph agent development platform. From 0.6.0.beta1 until 0.7.1, there is insufficient isolation between execution-capable Docker sandboxes and trusted application services. A low-privileged authenticated user who can execute commands in their own sandbox can reach other tenants' sandbox APIs, access their files and secrets, execute commands in active sandboxes, and enumerate, create, or delete sandboxes through the unauthenticated provisioner without knowing administrator, database, or MinIO credentials. Sandboxes can also reach shared internal services; if shipped default service credentials remain unchanged, an attacker can use them, and if the exposed PostgreSQL account is a superuser, obtain command execution in the PostgreSQL container. These paths can disclose or modify cross-tenant data and sandbox state or cause denial of service through sandbox deletion without a container escape or kernel vulnerability. This vulnerability is fixed in 0.7.1. Existing deployments must separately rotate persisted PostgreSQL, Neo4j, or MinIO credentials that were previously set to documented or shipped defaults because upgrading the Compose files does not automatically rotate them.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
The Yuxi platform, an intelligent knowledge base and graph agent development tool built on large language models, suffered from a critical architectural flaw in versions ranging from 0.6.0.beta1 to 0.7.1 involving insufficient isolation between execution-capable Docker sandboxes and trusted application services. This vulnerability stems from a failure to properly segregate multi-tenant environments at the network and service access control layers. In this flawed configuration, the security boundary that should prevent lateral movement across tenant boundaries was effectively bypassed due to overly permissive internal networking rules and shared infrastructure components. The core issue lies in the fact that containers designated for user code execution were granted excessive privileges within the Docker swarm or compose environment, allowing them to communicate with backend services intended only for administrative use or other tenants' isolated environments.
A low-privileged authenticated user who possesses the ability to execute commands within their own sandbox can exploit this misconfiguration to reach APIs belonging to other tenants. This capability allows an attacker to access sensitive files and secrets stored in shared storage buckets, such as MinIO instances that were not properly segmented by tenant identity. Furthermore, the attacker can interact with active sandboxes of other users, executing arbitrary commands within those environments without needing any elevated privileges or knowledge of administrator credentials. The vulnerability also extends to infrastructure management capabilities; through an unauthenticated provisioner endpoint, attackers could enumerate existing sandboxes, create new ones for further exploitation, or delete them entirely. This lack of authentication on the provisioning interface represents a severe breakdown in access control mechanisms, enabling denial of service attacks and potential data exfiltration without requiring any prior compromise of administrative accounts.
The impact is significantly amplified by the platform's reliance on shared internal services like PostgreSQL and Neo4j for persistent storage and graph management. If default credentials shipped with the software were left unchanged, an attacker could leverage these known secrets to authenticate directly against database containers. In scenarios where the exposed PostgreSQL account held superuser privileges, this access translates directly into command execution within the container environment via extensions or configuration file manipulation. This path allows for complete compromise of the data layer and potential pivoting to other services on the host network. The vulnerability enables cross-tenant data disclosure and modification as well as sandbox state tampering without requiring a traditional container escape or exploitation of kernel-level vulnerabilities, making it accessible to attackers with minimal initial foothold privileges.
This flaw aligns closely with CWE-284 Improper Access Control and CWE-732 Incorrect Permission Assignment for Critical Resource from the Common Weakness Enumeration standards. From an offensive security perspective, the ability to move laterally between containers and access shared services maps directly to MITRE ATT&CK techniques such as T1090 Proxying and T1552 Unsecured Credentials. The exploitation chain demonstrates how default configurations can lead to catastrophic privilege escalation in containerized multi-tenant architectures. To mitigate this risk, organizations must upgrade immediately to version 0.7.1 or later where the isolation boundaries have been reinforced. Crucially, simply upgrading the software is insufficient for existing deployments; administrators are required to manually rotate all persisted credentials for PostgreSQL, Neo4j, and MinIO services that were previously set to documented defaults. This manual intervention ensures that any potential compromise of default secrets does not persist after the patch is applied, thereby closing the attack vector entirely.