Insecure handling of image volumes in containerd CRI plugin
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 1.4.13, 1.5.10, 1.6.1
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- 1 proof of concept on GitHub
Summary
containerd is a container runtime available as a daemon for Linux and Windows. A bug was found in containerd prior to versions 1.6.1, 1.5.10, and 1.14.12 where containers launched through containerd’s CRI implementation on Linux with a specially-crafted image configuration could gain access to read-only copies of arbitrary files and directories on the host. This may bypass any policy-based enforcement on container setup (including a Kubernetes Pod Security Policy) and expose potentially sensitive information. Kubernetes and crictl can both be configured to use containerd’s CRI implementation. This bug has been fixed in containerd 1.6.1, 1.5.10, and 1.4.12. Users should update to these versions to resolve the issue.
Timeline
- CVE published
- Record last updated
- EPSS reached 10%
FIRST estimates at least a 10% chance of exploitation in the next 30 days
Affected versions
- containerd containerd
fixed in 1.4.13; From 1.5.0 · fixed in 1.5.10; From 1.6.0 · fixed in 1.6.1
- github.com/containerd/containerdGo
fixed in 1.4.13; From 1.5.0 · fixed in 1.5.10; From 1.6.0 · fixed in 1.6.1
- github.com/containerd/containerdGo
fixed in 1.4.13
- github.com/containerd/containerdGo
From 1.5.0 · fixed in 1.5.10
- github.com/containerd/containerdGo
From 1.6.0 · fixed in 1.6.1