What happened
Insufficient isolation between execution-capable Docker sandboxes and trusted application services allows cross-tenant access: a sandbox-holder can enumerate and drive other tenants' sandboxes and hit the unauthenticated provisioner, and sandboxes can reach shared internal services. The result is cross-tenant data disclosure/modification, sandbox-state manipulation, and DoS via sandbox deletion — all without a container escape or kernel bug, and escalated to RCE where default DB credentials are unchanged and the exposed PostgreSQL role is a superuser.
Why it matters
This is a multi-tenant isolation failure in an AI agent development platform where tenants execute code in sandboxes that are supposed to be mutually isolated. An attacker with a low-privilege account gains access to other tenants' agent state, files, and secrets, and can pivot to shared database services — the precise isolation boundary that an AI/SaaS multi-tenant deployment depends on.
Attack vector
A low-privileged authenticated user who can execute commands in their own execution-capable Docker sandbox can reach other tenants' sandbox APIs, read their files and secrets, execute commands in active sandboxes, and enumerate/create/delete sandboxes via the unauthenticated provisioner — without knowing admin/database/MinIO credentials. Sandboxes can also reach shared internal services; if shipped default PostgreSQL/Neo4j/MinIO credentials remain unchanged, an attacker can use them and, if the PostgreSQL account is a superuser, gain command execution in the PostgreSQL container.
Affected systems
Yuxi >= 0.6.0.beta1, < 0.7.1
Mitigation
Upgrade to Yuxi 0.7.1. Separately rotate persisted PostgreSQL, Neo4j, and MinIO credentials that were previously set to documented/shipped defaults, because upgrading Compose files does not rotate them automatically.