Breaking Docker’s Isolation Using... Docker? (CVE-2025-9074)

Author

Philippe Dugre ("zer0x64")

A while ago, a long time friend and security researcher, Felix Boulet, contacted me regarding something he found.This blog post is about my part in analysing and testing the CVE-2025-9074 vulnerability, a critical vulnerability allowing an attacker to break out of a docker container on Docker Desktop, the Windows and MacOS version of Docker.

Finding and confirming the vulnerability

Felix was messing around with network scans from a Docker container, when he found an open port that he didn’t recognize. After a bit of investigation, he found out it was the Docker engine socket and that there was no authentication system to access it. When he found out what he had, he contacted me about it because I’ve got more experience with Docker and development in general.

The first step was to validate the vulnerability. His setup is admittedly very non-standard since he is always trying to break software, so he needed a second opinion on a fresh installation. I dusted off an old laptop, did all the Windows updates and freshly installed Docker on it. I adjusted his proof of concept to my setup and was able to exploit it, confirming the vulnerability. I then proceeded to test it on Linux and MacOS, while also refining the exploit code. It turned out that Linux is not vulnerable, for reasons which will be discussed later, but MacOS was, although with a lower impact than on Windows.

The vulnerability

The vulnerability itself is pretty simple: The Docker Engine socket should never be accessible by untrustworthy code or user. This socket is the management API for docker and having access to it grants full access to everything the docker application can do.

This obviously includes creating and deleting containers, but a more nefarious capability here is volume mounting.

Let’s say the docker engine runs a production application using a database, which also runs on docker. An attacker can simply create a new container and mount the database’s volume, which then allows him to read and write anything to the database.

An even scarier application of this, however, is mounting the host’s file system. This allows the attacker to read and write files on the host.

On Windows, since the Docker Engine runs via WSL2, the attacker can mount as an administrator the entire filesystem, read any sensitive file, and ultimately overwrite a system DLL to escalate the attacker to administrator of the host system.

On MacOS, however, the Docker Desktop application still has a layer of isolation and trying to mount a user directory prompts the user for permission. By default, the docker

application does not have access to the rest of the filesystem and does not run with administrative privileges, so the host is a lot safer than in the Window’s case. However, the attacker does still have full control of the docker application/containers and can even backdoor it by mounting and modifying the application’s configuration, which does not need any user approval.

What about Linux?

Linux does not use a TCP socket for the Docker Engine’s API. Instead, it uses a named pipe on the host’s filesystem. Unless a specific unsafe configuration is used, the container does not have access to that named pipe. Note that this vulnerability is documented and by design when doing a Docker-in-Docker setup, which shouldn’t be used in production for this very reason.

How easy is it to exploit?

When it comes to the difficulty of exploiting the vulnerability in a perfect scenario, it is indeed very easy to exploit. For my MacOS proof of concept, I only needed 3 lines of python code:

Python

   import docker
   client = docker.DockerClient(base_url="tcp://192.168.65.7:2375")


   client.containers.run("alpine", "touch /mnt/pwned",
   volumes=["/Users/<username>/:/mnt"])