Inheritable Linux Process Capabilities in containerd
Summary
GHSA-c9cp-9c75-9v8c: containerd started with non-empty inheritable Linux process capabilities. Affects github.com/containerd/containerd across 2 version ranges.
< 1.5.11
>= 1.6.0, < 1.6.2
Fixed in 1.5.11 or 1.6.2, depending on the release line you run. How to fix ↓
Check if this vulnerability affects your application
Upload a manifest or SBOM and we'll show whether you're affected, plus every other risky package in the same scan.
No signup required · Results in about 60 seconds
Background
containerd is an open-source container runtime that provides a platform-agnostic interface for managing containers. It is written in Go and is widely used in container orchestration systems like Kubernetes. containerd allows users to run containers with specific Linux process capabilities, which define the privileges and permissions available to the container's processes. However, a vulnerability was discovered in containerd where containers were started with non-empty inheritable Linux process capabilities, leading to an atypical Linux environment and potential privilege escalation.
Vulnerability Detail
The vulnerability in containerd allowed containers to be started with non-empty inheritable Linux process capabilities. This meant that executable programs within the container with inheritable file capabilities could elevate those capabilities to the permitted set during execve(2). Normally, unprivileged users and processes can execute programs with specified permitted file capabilities and gain those capabilities up to the bounding set. However, due to this bug, containers with executable programs containing inheritable file capabilities allowed unprivileged users and processes to additionally gain these inheritable file capabilities up to the container's bounding set. This primarily affected containers using Linux users and groups for privilege separation.
How To Fix
Latest published version: v1.7.36 as of 22 Oct 2026
go get github.com/containerd/containerd@v1.7.36Upgrading to it may include breaking changes; the versions below are the minimum fixed release for this vulnerability.
If you can't move to the latest
The minimum fixed version depends on the release line you run.
-
< 1.5.111.5.11go get github.com/containerd/containerd@v1.5.11 -
>= 1.6.0, < 1.6.21.6.2go get github.com/containerd/containerd@v1.6.2
Tip — Not sure which release line you're on? Vulert can find the fix for the version you are using. Scan free →
Workaround
To mitigate the vulnerability, the entrypoint of a container can be modified to use a utility like capsh(1) to drop inheritable capabilities before the primary process starts.
Conclusion
The vulnerability in containerd that allowed containers to start with non-empty inheritable Linux process capabilities has been fixed in versions 1.5.11 and 1.6.2. Users are advised to update to these versions and recreate running containers. A workaround is available by modifying the container's entrypoint. For further support on vulnerability remediation, contact DevNack.com.
See every vulnerability recorded for github.com/containerd/containerd →
FAQ
containerd is an open-source container runtime used in container orchestration systems like Kubernetes. It provides a platform-agnostic interface for managing containers.
The vulnerability in containerd allowed unprivileged users and processes to gain inheritable file capabilities up to the container's bounding set, potentially enabling privilege escalation within containers.
The vulnerability affects containerd versions prior to 1.5.11 and 1.6.2.
Update containerd to versions 1.5.11 or 1.6.2. Stop, delete, and recreate running containers for the inheritable capabilities to be reset.
Yes, you can modify the entrypoint of a container to use a utility like capsh(1) to drop inheritable capabilities before the primary process starts.
References
Related vulnerabilities
Recent vulnerabilities recorded for github.com/containerd/containerd.
