Yuxi sandbox isolation failure allows cross-tenant access and internal service compromise
Affects Yuxi 0.6.0.beta1 up to but not including 0.7.1, mainly Docker Compose deployments that enable execution-capable sandboxes. Fixed in 0.7.1.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fixed in 0.7.1
- Who is exposed
- Specific setups only
Do first: Check whether your setup matches what the bug needs. Docker Compose deployments that enable execution-capable sandboxes using the sandbox provisioner Affected versions are 0.6.0.beta1 up to but not including 0.7.1 Shipped default service credentials for PostgreSQL, Neo4j, or MinIO remain unchanged (for the default-credential path) Exposed PostgreSQL account is a PostgreSQL superuser (for command execution in the PostgreSQL container)
- Exploitation?/40Exploitation: unknown (data gap). No CISA SSVC exploitation rating yet
- Exposure8/25Specific setups only, reachable over the network
- Reach?/20Reach: unknown (data gap). No tracked technology or package matched
- Severity9.9/10CVSS 9.9
- No patch0/5No signal
What would change the score
- Would score about 68 if added to CISA KEV
- Would score about 63 if CISA's SSVC rates exploitation active
- Would score about 25 if CISA's SSVC rates it automatable
CVE-2026-97693 is not in CISA's Known Exploited Vulnerabilities (KEV) catalog. No public exploit code is tracked. It is rated CVSS 9.9 (critical) and affects Yuxi; fixed in 0.7.1.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 18/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 0.7.1
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Yuxi, a platform for building knowledge base and knowledge graph agents, has an isolation flaw that lets a low-privileged user with a login, reaching it over the network, access other tenants' Docker sandboxes to read files and secrets, run commands, and create or delete sandboxes. If shipped default service credentials were left unchanged, an attacker can also use them to reach shared internal services such as PostgreSQL, potentially gaining command execution there.
Read the original description
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.
What to do
Check whether your setup matches what the bug needs.
Docker Compose deployments that enable execution-capable sandboxes using the sandbox provisioner Affected versions are 0.6.0.beta1 up to but not including 0.7.1 Shipped default service credentials for PostgreSQL, Neo4j, or MinIO remain unchanged (for the default-credential path) Exposed PostgreSQL account is a PostgreSQL superuser (for command execution in the PostgreSQL container)Upgrade to a fixed version: 0.7.1.
Workaround: Disable sandbox execution, or restrict access to Yuxi to fully trusted administrators; place every sandbox in a network that cannot reach other sandboxes or the application network; block sandbox access to PostgreSQL, Neo4j, MinIO, Redis, and the sandbox provisioner; restrict the provisioner API; replace shipped or historical default credentials
Timeline
- CVE published
- First seen by cve.now
- Posted on X by cve.now
Affected versions
- xerrors Yuxi
From 0.6.0.beta1 · fixed in 0.7.1
Evidence 2
- Advisory
- Repository
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-97693
Is CVE-2026-97693 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
Sandbox isolation fails, so a sandbox can reach other tenants' sandbox APIs, files, and secrets, as well as shared internal services. The sandbox provisioner API can also be used to enumerate, create, or delete sandboxes, which can disrupt other tenants' sandboxes.Source: github.com
Which versions are affected by CVE-2026-97693?
Yuxi: from 0.6.0.beta1 before 0.7.1.Source: cve.now feed data
Am I affected, and how do I check?
Versions from 0.6.0.beta1 up to but not including 0.7.1 are affected, mainly Docker Compose deployments that enable execution-capable sandboxes using the sandbox provisioner. The default-credential path needs shipped PostgreSQL, Neo4j, or MinIO credentials that were never changed, and command execution in the PostgreSQL container needs an exposed database account that is a PostgreSQL superuser. To check, confirm the installed Yuxi version and whether sandbox execution is enabled in the Docker Compose configuration.Source: github.com
How do I fix CVE-2026-97693?
Upgrade to Yuxi 0.7.1, which contains the fix. Until the upgrade is applied, the workarounds are to disable sandbox execution or limit Yuxi access to fully trusted administrators, and to replace any shipped or historical default credentials.Source: github.com
Why do the sources disagree?
The description says the sandbox provisioner is unauthenticated, while the CVSS vector lists PR:L, meaning privileges are required. The sources therefore conflict on whether an attacker needs any privileges to reach the provisioner.Source: github.com