In cloud and DevOps, containers are everywhere. With that popularity comes a larger attack surface—meaning any misconfiguration can turn into a security nightmare. Two container runtimes—CRI-O and Moby/Docker Engine—were found to have a critical vulnerability (CVE-2022-27652). In simple terms: they incorrectly started containers with non-empty inheritable capabilities, which could lead to privilege escalation.

Here, we’ll break down the technical details in simple language, show you code snippets to understand the risk, and walk through how an attacker could exploit this in real life.

What Are Linux Capabilities?

First, you need a bit of background:  
Linux capabilities break the all-powerful root privileges into smaller pieces (like CAP_NET_ADMIN, CAP_SYS_ADMIN, etc). A process can hold capabilities in several sets (Effective, Permitted, Inheritable, etc).

Effective: Capabilities a process *is actually using right now*

For containers, it's best to only give out *minimal* capabilities, and ideally, keep the inheritable set empty.


## The Flaw in CRI-O and Moby/Docker

CRI-O and Docker Engine are container runtimes. Due to a flaw in how they were starting containers, the inheritable set was not empty by default. This means, if a process inside the container (let's say, a normal user process) ran another program (say, using execve(2)), any file capabilities could be *escalated* to full permitted capabilities.

If a non-root process had access to a binary with file capabilities, it could get extra privileges—*much more than it should*.

Real Example: Exploiting the Flaw

Imagine you have a container running as a non-root user and, due to this bug, the inheritable set isn’t empty. There’s a binary inside the container (owned by root) with a file capability, e.g., CAP_NET_ADMIN. Normally, a non-root user shouldn’t be able to get this capability. With this vulnerability, they can.

Hypothetical Container Scenario

Container User ID: 100 (not root)  
File Binary: /usr/local/bin/suspicious with CAP_NET_ADMIN file capability

Check with

getcap /usr/local/bin/suspicious
# /usr/local/bin/suspicious cap_net_admin+ei

Now, inside the container, if you execute this binary

id -u
# 100

/usr/local/bin/suspicious

Because of the non-empty inheritable set, this process suddenly has *permitted* CAP_NET_ADMIN—allowing network manipulation.

`bash

getcap -r / 2>/dev/null
  # Look for outputs like '/usr/local/bin/suspicious cap_net_admin+eip'

Use capsh to investigate your capabilities before and after

Run the binary

/usr/local/bin/suspicious

Abuse The Elevated Capability

With CAP_NET_ADMIN, you can do things like set up network interfaces, change routes, sniff traffic, etc:

Mitigations

Patch Now!  
- For CRI-O: Upgrade to CRI-O v1.22.5+, v1.23.4+, v1.24.+  
- For Docker/Moby: Update to a patched version

References

- GitHub Security Advisory for CRI-O
- GitHub Security Advisory for Moby/Docker
- man capabilities(7)
- Original CVE Record

Conclusion

This vulnerability serves as a reminder: even "safe defaults" can be wrong, and privilege escalation isn’t always about root. Always keep your container environments up to date, audit both runtime configs and container images for capabilities, and treat file capabilities with as much care as setuid programs.

Stay safe—and patch your containers!

*This post is exclusive and written in clear language to help you stay ahead in container security.*

Timeline

Published on: 04/18/2022 17:15:00 UTC
Last modified on: 04/27/2022 00:22:00 UTC