Docker Patches CVE-2025-9074: What You Actually Need to Know

So Docker just fixed a pretty nasty bug, and if you run containers, you will want to pay attention to this. The flaw is tracked as CVE-2025-9074, and it got a CVSS score of 9.3. For context, that score basically means “yeah, this is really bad.” The issue affects Docker Desktop on Windows and macOS, and the fix came out in version 4.44.3.

What went wrong?

The short version: a malicious container could talk directly to the Docker Engine API without any authentication. That is not supposed to happen. Once it gets that access, it can spin up other containers on its own. And since containers can mount drives from your host machine, you can already see where this is going—suddenly your host system files are exposed.

Security researcher Felix Boulet explained it in plain terms: the Docker API was reachable from any container over 192.168.65[.]7:2375 without asking for credentials. That oversight basically meant any “bad” container could escape its sandbox.

Boulet even dropped a proof-of-concept that makes this clear:

• First, send a request to create a new container, but bind the host’s C:\ drive to it.

• Then, just start the container. Boom—you now can read and write to the host system files from inside that container.

It sounds almost too simple, but that is what made it dangerous.

Windows vs macOS impact

On Windows, this was way worse. An attacker could mount the entire file system, peek into sensitive files, or even overwrite DLLs to gain full admin privileges on the host. In other words, game over.

On macOS, things looked a bit better. Docker Desktop does not run with admin rights by default, and if a container tries to mount your user directories, the OS prompts you first. That adds an extra layer of safety. Still, attackers could mess with Docker’s configs or backdoor the app itself, so it is not exactly harmless.

On Linux, you are safe from this specific bug. That version of Docker uses a named pipe instead of that exposed TCP socket, so the same attack path does not exist.

How an attacker could abuse this

The obvious way is by sneaking a malicious container into your environment. But researchers also mentioned you could chain it with something like an SSRF bug. That means if some web app running inside a container can be tricked into making HTTP requests, an attacker might be able to hit the Docker API through that route. That opens the door to different exploit chains, not just one-off malicious containers.

Why it happened

Philippe Dugre (aka zer0x64) summed it up bluntly: Docker’s internal API was exposed without checks. No auth, no access controls. It was just reachable. That sort of thing is less of a complicated hack and more of a major oversight in design.

What you should do

If you are on Docker Desktop for Windows or macOS, update to 4.44.3 right away. Do not put this off. A CVSS 9.3 bug is not one of those “meh, I will patch later” cases. It is critical.

Also, if you are running untrusted containers (say, stuff from Docker Hub without carefully checking), you really should not until you patch. This bug basically made “just one malicious image” enough to compromise your host.

Final thoughts

This might sound confusing at first—containers are supposed to isolate stuff, right? That is the whole point. But isolation only works if the APIs that manage containers are locked down. Here, that lock was missing, and attackers could just walk through.

If you ever needed a reminder that security in container tech is not just about the apps inside but also the tooling around it, this is it.