What happened
DeepSeek's harness sandboxes run mount-capable processes inside bwrap/Landlock without a user namespace, so when executed as root the sandboxed agent retains CAP_SYS_ADMIN and can remount the read-only root filesystem read-write and write/delete any host file. A public mechanism-level reproduction confirms the escape as root while non-root is blocked by the kernel.
Why it matters
DeepSeek's official harness is the reference implementation that sandboxes autonomous code-executing agents during evaluation; a sandbox-escape that defeats the read-only/workspace boundary means agent outputs and evaluation payloads can already fully compromise a host — especially in container/CI deployments where the harness runs as root — undermining the safety of the agent sandbox itself.
Attack vector
The bwrap profile omits --unshare-user and the Landlock launcher never drops mount capability, so a sandboxed agent running as root retains CAP_SYS_ADMIN and can remount the read-only root read-write (or bind-mount over /etc, or tmpfs over /root) and write/delete any host file. Paralleled by CVE-2026-101102 (Code Mode sandbox) in the same harness.
Affected systems
deepseek-ai deepseek-harness sandboxes (bwrap and Landlock backends) up to 0.1.7-rc.2 (sandbox-local profiles.ts; e2b backend CVE-2026-101131)
Mitigation
Add --unshare-user / user-namespace to the bwrap profile and drop mount capability in the Landlock launcher (as Codex does). No upstream fix confirmed; run harness only as non-root until patched. Primary disclosure: Ruoyyy SECURITY-MOUNT-ESCAPE note; NVD CVE-2026-101078.