The broader takeaway is that container-based sandboxes can be unsafe defaults if network exposure and authentication aren’t properly coordinated, so secure defaults and explicit opt-ins are essential to prevent a sandbox from becoming an attacker’s foothold.

Shipped fixes show divergent patch statuses: a fix in version 0.3.42 binds to localhost in local mode and requires opt-in (CUA_ALLOW_INSECURE=1) to go public, while AutoAgent has a fix in progress or not yet released for all configurations, with ongoing issue #96.

Two CVEs published on September 5, 2026—CVE-2026-86121 for Cua and CVE-2026-86124 for AutoAgent—both carry a CVSS 3.1 score of 9.8 due to insecure sandbox defaults.

The vulnerabilities stem from default configurations that allow network exposure and lack authentication: Cua binds to all interfaces (0.0.0.0) with local mode skipping authentication, and AutoAgent exposes a root-tied sandbox on all interfaces with no authentication and a writable host bind mount.

Mitigation guidance includes five checks before running these tools: pin to secure versions, bind to loopback, do not run containers as root, publish ports only on loopback, mount volumes read-only unless necessary, and keep credentials out of mounted directories.

The author argues that secure defaults should be provided by maintainers, and the unsafe defaults in these projects underscore why careful default configurations matter for tool security.

Impact details: both sandboxes expose endpoints that can execute commands, read/write files, and provide an interactive PTY without credentials, creating potential for remote code execution and control when exposed over the network.