• Hello and welcome! Register to enjoy full access and benefits:

    • Advertise in the Marketplace section for free.
    • Get more visibility with a signature link.
    • Company/website listings.
    • Ask & answer queries.
    • Much more...

    Register here or log in if you're already a member.

  • 🎉 WHV has crossed 35,000 monthly views (unique) and 208,000 clicks per month, as per Google Analytics! Thank you for your support! 🎉

Critical runC Bugs Could Let Attackers Escape Docker Containers

johny899

New Member
Content Writer
Messages
742
Reaction score
3
Points
23
Balance
$915.8USD
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.

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.
If you run trusted images while securing your environment, your risk will greatly diminish.

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.
If you are using Kubernetes, or multiple containers on a single host, it makes it all that much more important to patch everything and lock it down.
 
Top