Skip to main content
No exploitation reportedFix available

CVE-2020-15157

No exploitation reported by the sources we read.

  • Published2020-10-16
  • WeaknessCWE-522

Am I affected?

With a domain, we read the version its public headers and pages expose. A distribution build can carry the fix under an older number.

Description

In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a “foreign layer”), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources. Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected.

Timeline

dates in UTC
  1. 2020-10-1617:15CVE publishedNVD

Versions per branch

NVD · OSV
Canonical ubuntu linux
BranchAffectedFixed in
16.4= 16.04no fix published
18.4= 18.04no fix published
20.4= 20.04no fix published
Linuxfoundation containerd
BranchAffectedFixed in
1.2≥ 1.2.0, < 1.2.141.2.14
1.2< 1.2.141.2.14
1.3= 1.3.0no fix published
Debian debian linux
BranchAffectedFixed in
10.0= 10.0no fix published

as publishedRanges as NVD and OSV publish them; a distribution’s build can be fixed under an older number.

Distribution builds and vendor advisories

Packages from OSV.dev and products from the vendors' CSAF advisories.

version not verifiedVersions not verified: read as OSV.dev and the vendors publish them, not checked against each vendor's release list.

Packages

  • conmonSUSE:Linux Enterprise Module for Containers 15 SP3all versions · fixed in 2.0.30-150300.8.3.1
  • conmonSUSE:Linux Enterprise Micro 5.1all versions · fixed in 2.0.30-150300.8.3.1
  • conmonopenSUSE:Leap 15.3all versions · fixed in 2.0.30-150300.8.3.1
  • containerdUbuntu:16.04:LTSall versions · fixed in 1.2.6-0ubuntu1~16.04.4
  • containerdSUSE:Linux Enterprise Module for Containers 12all versions · fixed in 1.3.9-16.35.1
  • containerdopenSUSE:Tumbleweedall versions · fixed in 1.4.8-2.2
  • containerdDebian:14all versions · fixed in 1.3.2~ds1-2
  • containerdDebian:13all versions · fixed in 1.3.2~ds1-2

45 more package ranges on OSV.dev

Vendor advisories

  • RHSA-2020:5634 Red Hat Product Security6 products fixed

    Red Hat Security Advisory: OpenShift Container Platform 4.7.0 packages security update

Full record on NVD

Fix

  1. Vendor fix Red Hat Product Security RHSA-2020:5634 · 6 productsFor OpenShift Container Platform 4.7 see the following documentation, which will be updated shortly for this release, for important instructions on how to upgrade your cluster and fully apply this asynchronous errata update: https://docs.openshift.com/container-platform/4.7/release_notes/ocp-4-7-r…

Detection

Nuclei template
none so far
ProjectDiscovery
Exploit-DB
no entry
Exploit-DB
Proof of concept
Metasploit modules
none listed
Metasploit Framework

Sources

  • CNACVSS 3.16.1known since 2026-10-23
  • NVDCVSS 3.16.1read 2026-10-23
  • NVDCVSS 2.02.6read 2026-10-23
  • CNAweakness (CWE)CWE-522known since 2026-10-23
  • NVDweakness (CWE)CWE-522read 2026-10-23
  • FIRST EPSSEPSS score2.3 %2026-11-09
  • OSVaffected packages—
  • GitHub AdvisoriesadvisoryMODERATE2021-05-24

Identifiers

Technical details

CVSS v3 Vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N
Published
2020-10-16
Last Modified
2026-06-17
NVD status
Modified
GitHub Advisory
GHSA-742w-89gc-8m9c

Frequently asked questions

What is CVE-2020-15157?

In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a “foreign layer”), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources. Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected.

Is CVE-2020-15157 actively exploited?

Active exploitation of CVE-2020-15157 has not been confirmed. Its EPSS score was 2.3% on 2026-11-09, the estimated probability of exploitation in the next 30 days.

What is the CVSS score for CVE-2020-15157?

CVE-2020-15157 has a CVSS v3 base score of 6.1 (MEDIUM severity), with vector string CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N.

Running containerd/containerd? Hear about its next vulnerability

Surveillance reads the versions in your stack — a domain, a lockfile or a list — checks each CVE against the ranges its sources publish, and alerts you when one you run is exploited or enters CISA KEV. A version it cannot read stays « version not verified ».

Get alerts for this productCISA KEV additions, November 2026Search CVEs

No credit card required · No monthly cap on website lookups · 250 API requests/month

Go further

Related vulnerabilities

Same product first, then the same vendor advisory and the same publication week.

Back to CVE Database

Sources for this record