Consider a situation where you're running applications in a secure Docker container thinking that everything is locked down. Then all of a sudden someone breaks out and into your main system. Not good! The new runC vulnerabilities could allow this to happen to a malicious actor.
I use Docker all the time, so this definitely caught my interest! runC is like the "engine" that is responsible for launching and running containers in Docker and Kubernetes. If the engine is broken, containers are not very secure.
• CVE-2025-31133 - Attackers could trick runC into mounting a fake file (like /dev/null) that actually points to a sensitive area on the host system.
• CVE-2025-52565 - Malicious actors could mess with /dev/console mounts and gain access to files on the host.
• CVE-2025-52881 - runC may write to system files in /proc that they control and that allow the attacker to bypass security tools.
In short, these vulnerability allows an attacker to escape the container and target the host machine.
Not very good news, is it?
• runC 1.2.8, 1.3.3, 1.4.0-rc.3 or above.
If it’s an old version, then get it updated now. It is very easy to skip this step, but believe me: avoiding updates is like leaving your front door unlocked at home in the middle of the night.
So far, there are no known next generation security attacks being executed using the bugs, but that doesn’t mean they won’t be occurring any day now.
I use Docker all the time, so this definitely caught my interest! runC is like the "engine" that is responsible for launching and running containers in Docker and Kubernetes. If the engine is broken, containers are not very secure.
What is the problem, simply?
A group of researchers identified three major vulnerabilities in runC:• CVE-2025-31133 - Attackers could trick runC into mounting a fake file (like /dev/null) that actually points to a sensitive area on the host system.
• CVE-2025-52565 - Malicious actors could mess with /dev/console mounts and gain access to files on the host.
• CVE-2025-52881 - runC may write to system files in /proc that they control and that allow the attacker to bypass security tools.
In short, these vulnerability allows an attacker to escape the container and target the host machine.
Why it matters
The entire principle of containers is to isolate them from each other in their respective box. If you break out of that box, you can take full control of the underlying system. That means you can steal data, destroy files, and even crash the system completely.Not very good news, is it?
Who's vulnerable?
However, not everyone is vulnerable. To do this, a malicious party would need to start containers with certain permissions, including:- Starting containers with their own mounts, or
- Uploading and starting their own container images.
How to fix it
The good news is, there is already a fix! The secure versions are:• runC 1.2.8, 1.3.3, 1.4.0-rc.3 or above.
If it’s an old version, then get it updated now. It is very easy to skip this step, but believe me: avoiding updates is like leaving your front door unlocked at home in the middle of the night.
So far, there are no known next generation security attacks being executed using the bugs, but that doesn’t mean they won’t be occurring any day now.
What do you want to do?
Here’s what I would say:- Update the runC to the latest version.
- Only use trusted images. Do not pull random containers from any repo on the internet.
- Whenever applicable, Containers should be executed as a non-root user.
- Use rootless mode or user namespaces.
- Watch for odd symbolic link or mount activity it can means things are going bad.