Every CVE Search/ Get API key

CVE-2020-15157

containerd can be coerced into leaking credentials during image pull

6.1 MediumFix available

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.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
High
Privileges needed
None
User interaction
Required

What an attacker can affect

Confidentiality
High
Integrity
None
Availability
None

Exploit likelihood

2.30%Up 1.0 points since Apr 14, 2021
90%50%10%1%

What each source reports

CVE List Score used 6.1

containerd can be coerced into leaking credentials during image pull

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.

Record
CVE-2020-15157
CVSS 3.1
6.1 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N
Weakness
CWE-522
Updated
2026-11-02
EUVDEUVD-2022-0879 6.1

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.

Record
EUVD-2022-0879
CVSS 3.1
6.1 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N
Updated
2026-11-03
GitHub AdvisoriesGHSA-742w-89gc-8m9c 6.1

containerd v1.2.x can be coerced into leaking credentials during image pull

Impact

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 rated by the containerd maintainers as medium, with a CVSS score of 6.1 and a vector string of CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N.

Patches

This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected.

Workarounds

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.

Credits

The containerd maintainers would like to thank Brad Geesaman, Josh Larsen, Ian Coldwater, Duffie Cooley, and Rory McCune for responsibly disclosing this issue in accordance with the containerd security policy.

Record
GHSA-742w-89gc-8m9c
CVSS 3.1
6.1 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N
Weakness
CWE-522
Updated
2026-11-02
NVD 6.1

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.

Record
CVE-2020-15157
CVSS 3.1
6.1 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N
CVSS 2.0
2.6 LowAV:N/AC:H/Au:N/C:P/I:N/A:N
Weakness
CWE-522
Updated
2026-11-02
OSV 6.1

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.

Record
CVE-2020-15157
CVSS 3.1
6.1 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N
Updated
2026-11-02
OSVDEBIAN-CVE-2020-15157 6.1

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.

Record
DEBIAN-CVE-2020-15157
CVSS 3.1
6.1 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N
Updated
2026-11-02
Show 13 moreShow less
OSVGHSA-742w-89gc-8m9c 6.1

containerd v1.2.x can be coerced into leaking credentials during image pull

Impact

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 rated by the containerd maintainers as medium, with a CVSS score of 6.1 and a vector string of CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N.

Patches

This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected.

Workarounds

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.

Credits

The containerd maintainers would like to thank Brad Geesaman, Josh Larsen, Ian Coldwater, Duffie Cooley, and Rory McCune for responsibly disclosing this issue in accordance with the containerd security policy.

Record
GHSA-742w-89gc-8m9c
CVSS 3.1
6.1 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N
Weakness
CWE-522
Updated
2026-11-02
OSVRHSA-2020:5634 8.6

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

Record
RHSA-2020:5634
CVSS 3.1
8.6 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
Updated
2026-11-02
OSVUBUNTU-CVE-2020-15157 6.1

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.

Record
UBUNTU-CVE-2020-15157
CVSS 3.1
6.1 MediumCVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:N
Updated
2026-11-02
OSVGO-2022-0803 No score

containerd v1.2.x can be coerced into leaking credentials during image pull in github.com/containerd/containerd

containerd v1.2.x can be coerced into leaking credentials during image pull in github.com/containerd/containerd

Record
GO-2022-0803
Updated
2026-11-02
OSVMGASA-2020-0406 No score

Updated docker packages fix a security vulnerability

It was discovered that Docker could be made to expose sensitive information when processing URLs in container image manifests. A remote attacker could use this to trick the user and obtain the user's registry credentials (CVE-2020-15157).

Record
MGASA-2020-0406
Updated
2026-11-02
OSVopenSUSE-SU-2022:23018-1 No score

Security update for conmon, libcontainers-common, libseccomp, podman

This update for conmon, libcontainers-common, libseccomp, podman fixes the following issues:

podman was updated to 3.4.4.

Security issues fixed:

  • fix CVE-2021-41190 [bsc#1193273], opencontainers: OCI manifest and index parsing confusion

  • fix CVE-2021-4024 [bsc#1193166], podman machine spawns gvproxy with port binded to all IPs

  • fix CVE-2021-20199 [bsc#1181640], Remote traffic to rootless containers is seen as orginating from localhost

  • Add: Provides: podman:/usr/bin/podman-remote subpackage for a clearer upgrade path from podman < 3.1.2

Update to version 3.4.4:

  • Bugfixes

    • Fixed a bug where the podman exec command would, under some circumstances, print a warning message about failing to move conmon to the appropriate cgroup (#12535).
    • Fixed a bug where named volumes created as part of container creation (e.g. podman run --volume avolume:/a/mountpoint or similar) would be mounted with incorrect permissions (#12523).
    • Fixed a bug where the podman-remote create and podman-remote run commands did not properly handle the --entrypoint='' option (to clear the container's entrypoint) (#12521).

  • Update to version 3.4.3:

    • Security

      • This release addresses CVE-2021-4024, where the podman machine command opened the gvproxy API (used to forward ports to podman machine VMs) to the public internet on port 7777.
      • This release addresses CVE-2021-41190, where incomplete specification of behavior regarding image manifests could lead to inconsistent decoding on different clients.

    • Features

      • The --secret type=mount option to podman create and podman run supports a new option, target=, which specifies where in the container the secret will be mounted (#12287).

    • Bugfixes

      • Fixed a bug where rootless Podman would occasionally print warning messages about failing to move the pause process to a new cgroup (#12065).
      • Fixed a bug where the podman run and podman create commands would, when pulling images, still require TLS even with registries set to Insecure via config file (#11933).
      • Fixed a bug where the podman generate systemd command generated units that depended on multi-user.target, which has been removed from some distributions (#12438).
      • Fixed a bug where Podman could not run containers with images that had /etc/ as a symlink (#12189).
      • Fixed a bug where the podman logs -f command would, when using the journald logs backend, exit immediately if the container had previously been restarted (#12263).
      • Fixed a bug where, in containers on VMs created by podman machine, the host.containers.internal name pointed to the VM, not the host system (#11642).
      • Fixed a bug where containers and pods created by the podman play kube command in VMs managed by podman machine would not automatically forward ports from the host machine (#12248).
      • Fixed a bug where podman machine init would fail on OS X when GNU Coreutils was installed (#12329).
      • Fixed a bug where podman machine start would exit before SSH on the started VM was accepting connections (#11532).
      • Fixed a bug where the podman run command with signal proxying (--sig-proxy) enabled could print an error if it attempted to send a signal to a container that had just exited (#8086).
      • Fixed a bug where the podman stats command would not return correct information for containers running Systemd as PID1 (#12400).
      • Fixed a bug where the podman image save command would fail on OS X when writing the image to STDOUT (#12402).
      • Fixed a bug where the podman ps command did not properly handle PS arguments which contained whitespace (#12452).
      • Fixed a bug where the podman-remote wait command could fail to detect that the container exited and return an error under some circumstances (#12457).
      • Fixed a bug where the Windows MSI installer for podman-remote would break the PATH environment variable by adding an extra ' (#11416).

    • API

      • The Libpod Play Kube…
Record
openSUSE-SU-2022:23018-1
Updated
2026-11-02
OSVopenSUSE-SU-2024:10693-1 No score

containerd-1.4.8-2.2 on GA media

These are all security issues fixed in the containerd-1.4.8-2.2 package on the GA media of openSUSE Tumbleweed.

Record
openSUSE-SU-2024:10693-1
Updated
2026-11-02
OSVopenSUSE-SU-2024:11757-1 No score

libcontainers-common-20210626-7.1 on GA media

These are all security issues fixed in the libcontainers-common-20210626-7.1 package on the GA media of openSUSE Tumbleweed.

Record
openSUSE-SU-2024:11757-1
Updated
2026-11-02
OSVSUSE-SU-2021:0445-1 No score

Security update for containerd, docker, docker-runc, golang-github-docker-libnetwork

This update for containerd, docker, docker-runc, golang-github-docker-libnetwork fixes the following issues:

Update Docker to 19.03.15-ce:

  • CVE-2021-21284: potential privilege escalation when the root user in the remapped namespace has access to the host filesystem (bsc#1181732)
  • CVE-2021-21285: malformed Docker image manifest crashes the dockerd daemon (bsc#1181730)
  • CVE-2020-15157: containerd: credentials leaking during image pull (bsc#1177598)
Record
SUSE-SU-2021:0445-1
Updated
2026-11-02
OSVSUSE-SU-2022:23018-1 No score

Security update for conmon, libcontainers-common, libseccomp, podman

This update for conmon, libcontainers-common, libseccomp, podman fixes the following issues:

podman was updated to 3.4.4.

Security issues fixed:

  • fix CVE-2021-41190 [bsc#1193273], opencontainers: OCI manifest and index parsing confusion

  • fix CVE-2021-4024 [bsc#1193166], podman machine spawns gvproxy with port binded to all IPs

  • fix CVE-2021-20199 [bsc#1181640], Remote traffic to rootless containers is seen as orginating from localhost

  • Add: Provides: podman:/usr/bin/podman-remote subpackage for a clearer upgrade path from podman < 3.1.2

Update to version 3.4.4:

  • Bugfixes

    • Fixed a bug where the podman exec command would, under some circumstances, print a warning message about failing to move conmon to the appropriate cgroup (#12535).
    • Fixed a bug where named volumes created as part of container creation (e.g. podman run --volume avolume:/a/mountpoint or similar) would be mounted with incorrect permissions (#12523).
    • Fixed a bug where the podman-remote create and podman-remote run commands did not properly handle the --entrypoint='' option (to clear the container's entrypoint) (#12521).

  • Update to version 3.4.3:

    • Security

      • This release addresses CVE-2021-4024, where the podman machine command opened the gvproxy API (used to forward ports to podman machine VMs) to the public internet on port 7777.
      • This release addresses CVE-2021-41190, where incomplete specification of behavior regarding image manifests could lead to inconsistent decoding on different clients.

    • Features

      • The --secret type=mount option to podman create and podman run supports a new option, target=, which specifies where in the container the secret will be mounted (#12287).

    • Bugfixes

      • Fixed a bug where rootless Podman would occasionally print warning messages about failing to move the pause process to a new cgroup (#12065).
      • Fixed a bug where the podman run and podman create commands would, when pulling images, still require TLS even with registries set to Insecure via config file (#11933).
      • Fixed a bug where the podman generate systemd command generated units that depended on multi-user.target, which has been removed from some distributions (#12438).
      • Fixed a bug where Podman could not run containers with images that had /etc/ as a symlink (#12189).
      • Fixed a bug where the podman logs -f command would, when using the journald logs backend, exit immediately if the container had previously been restarted (#12263).
      • Fixed a bug where, in containers on VMs created by podman machine, the host.containers.internal name pointed to the VM, not the host system (#11642).
      • Fixed a bug where containers and pods created by the podman play kube command in VMs managed by podman machine would not automatically forward ports from the host machine (#12248).
      • Fixed a bug where podman machine init would fail on OS X when GNU Coreutils was installed (#12329).
      • Fixed a bug where podman machine start would exit before SSH on the started VM was accepting connections (#11532).
      • Fixed a bug where the podman run command with signal proxying (--sig-proxy) enabled could print an error if it attempted to send a signal to a container that had just exited (#8086).
      • Fixed a bug where the podman stats command would not return correct information for containers running Systemd as PID1 (#12400).
      • Fixed a bug where the podman image save command would fail on OS X when writing the image to STDOUT (#12402).
      • Fixed a bug where the podman ps command did not properly handle PS arguments which contained whitespace (#12452).
      • Fixed a bug where the podman-remote wait command could fail to detect that the container exited and return an error under some circumstances (#12457).
      • Fixed a bug where the Windows MSI installer for podman-remote would break the PATH environment variable by adding an extra ' (#11416).

    • API

      • The Libpod Play Kube…
Record
SUSE-SU-2022:23018-1
Updated
2026-11-02
OSVSUSE-SU-2022:3312-1 No score

Security update for libcontainers-common

This update for libcontainers-common fixes the following issues:

libcontainers-common was updated:

  • common component was updated to 0.44.0.
  • storage component was updated to 1.36.0.
  • image component was updated to 5.16.0.
  • podman component was updated to 3.3.1.

3.3.1:

Bugfixes:

  • Fixed a bug where unit files created by podman generate systemd could not cleanup shut down containers when stopped by systemctl stop .
  • Fixed a bug where podman machine commands would not properly locate the gvproxy binary in some circumstances.
  • Fixed a bug where containers created as part of a pod using the --pod-id-file option would not join the pod's network namespace .
  • Fixed a bug where Podman, when using the systemd cgroups driver, could sometimes leak dbus sessions.
  • Fixed a bug where the until filter to podman logs and podman events was improperly handled, requiring input to be negated .
  • Fixed a bug where rootless containers using CNI networking run on systems using systemd-resolved for DNS would fail to start if resolved symlinked /etc/resolv.conf to an absolute path .

API:

  • A large number of potential file descriptor leaks from improperly closing client connections have been fixed.

3.3.0:

Features:

  • Containers inside VMs created by podman machine will now automatically handle port forwarding - containers in podman machine VMs that publish ports via --publish or --publish-all will have these ports not just forwarded on the VM, but also on the host system.
  • The podman play kube command's --network option now accepts advanced network options (e.g. --network slirp4netns:port_handler=slirp4netns) .
  • The podman play kube commmand now supports Kubernetes liveness probes, which will be created as Podman healthchecks.
  • Podman now provides a systemd unit, podman-restart.service, which, when enabled, will restart all containers that were started with --restart=always after the system reboots.
  • Rootless Podman can now be configured to use CNI networking by default by using the rootless_networking option in containers.conf.
  • Images can now be pulled using image:tag@digest syntax (e.g. podman pull fedora:34@sha256:1b0d4ddd99b1a8c8a80e885aafe6034c95f266da44ead992aab388e6aa91611a) .
  • The podman container checkpoint and podman container restore commands can now be used to checkpoint containers that are in pods, and restore those containers into pods.
  • The podman container restore command now features a new option, --publish, to change the ports that are forwarded to a container that is being restored from an exported checkpoint.
  • The podman container checkpoint command now features a new option, --compress, to specify the compression algorithm that will be used on the generated checkpoint.
  • The podman pull command can now pull multiple images at once (e.g. podman pull fedora:34 ubi8:latest will pull both specified images).
  • THe podman cp command can now copy files from one container into another directly (e.g. podman cp containera:/etc/hosts containerb:/etc/) .
  • The podman cp command now supports a new option, --archive, which controls whether copied files will be chown'd to the UID and GID of the user of the destination container.
  • The podman stats command now provides two additional metrics: Average CPU, and CPU time.
  • The podman pod create command supports a new flag, --pid, to specify the PID namespace of the pod. If specified, containers that join the pod will automatically share its PID namespace.
  • The podman pod create command supports a new flag, --infra-name, which allows the name of the pod's infra container to be set .
  • The podman auto-update command has had its output reformatted - it is now much clearer what images were pulled and what containers were updated.
  • The podman auto-update command now supports a new option, --dry-run, which reports what would be updated but does not actually perform the update .
  • The…
Record
SUSE-SU-2022:3312-1
Updated
2026-11-02
OSVUSN-4589-1 No score

containerd vulnerability

It was discovered that containerd could be made to expose sensitive information when processing URLs in container image manifests. A remote attacker could use this to trick the user and obtain the user's registry credentials.

Record
USN-4589-1
Updated
2026-11-02
OSVUSN-4589-2 No score

docker.io vulnerability

USN-4589-1 fixed a vulnerability in containerd. This update provides the corresponding update for docker.io.

Original advisory details:

It was discovered that containerd could be made to expose sensitive information when processing URLs in container image manifests. A remote attacker could use this to trick the user and obtain the user's registry credentials.

Record
USN-4589-2
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
github.com/containerd/containerd
Go
 before 1.2.14
1.2.14
containerd
Debian:12
 before 1.3.2~ds1-2
1.3.2~ds1-2
containerd
Debian:13
 before 1.3.2~ds1-2
1.3.2~ds1-2
containerd
Debian:14
 before 1.3.2~ds1-2
1.3.2~ds1-2
docker.io
Debian:12
 before 19.03.13+dfsg2-1
19.03.13+dfsg2-1
docker.io
Debian:13
 before 19.03.13+dfsg2-1
19.03.13+dfsg2-1
docker.io
Debian:14
 before 19.03.13+dfsg2-1
19.03.13+dfsg2-1
docker.io
Debian:10
From an advisory covering 4 CVEs
 before 18.09.1+dfsg1-7.1+deb10u3, plus listed versions
18.09.1+dfsg1-7.118.09.1+dfsg1-7.1+deb10u118.09.1+dfsg1-7.1+deb10u2
18.09.1+dfsg1-7.1+deb10u3
docker
Mageia:7
 before 18.09.9-1.2.mga7
18.09.9-1.2.mga7
openshift
Red Hat:openshift:4.7::el7
From an advisory covering 6 CVEs
 before 0:4.7.0-202102060108.p0.git.97095.7271b90.el7
0:4.7.0-202102060108.p0.git.97095.7271b90.el7
Show 57 moreShow less
Affected packages
PackageAffectedFixed
openshift-hyperkube
Red Hat:openshift:4.7::el7
From an advisory covering 6 CVEs
 before 0:4.7.0-202102060108.p0.git.97095.7271b90.el7
0:4.7.0-202102060108.p0.git.97095.7271b90.el7
openshift
Red Hat:openshift:4.7::el8
From an advisory covering 6 CVEs
 before 0:4.7.0-202102060108.p0.git.97095.7271b90.el8
0:4.7.0-202102060108.p0.git.97095.7271b90.el8
openshift-hyperkube
Red Hat:openshift:4.7::el8
From an advisory covering 6 CVEs
 before 0:4.7.0-202102060108.p0.git.97095.7271b90.el8
0:4.7.0-202102060108.p0.git.97095.7271b90.el8
python-rsa
Red Hat:openshift:4.7::el8
From an advisory covering 6 CVEs
 before 0:4.7-1.el8
0:4.7-1.el8
python3-rsa
Red Hat:openshift:4.7::el8
From an advisory covering 6 CVEs
 before 0:4.7-1.el8
0:4.7-1.el8
ignition
Red Hat:openshift:4.7::el8
From an advisory covering 6 CVEs
 before 0:2.9.0-2.rhaos4.7.git1d56dc8.el8
0:2.9.0-2.rhaos4.7.git1d56dc8.el8
ignition-debuginfo
Red Hat:openshift:4.7::el8
From an advisory covering 6 CVEs
 before 0:2.9.0-2.rhaos4.7.git1d56dc8.el8
0:2.9.0-2.rhaos4.7.git1d56dc8.el8
ignition-debugsource
Red Hat:openshift:4.7::el8
From an advisory covering 6 CVEs
 before 0:2.9.0-2.rhaos4.7.git1d56dc8.el8
0:2.9.0-2.rhaos4.7.git1d56dc8.el8
ignition-validate
Red Hat:openshift:4.7::el8
From an advisory covering 6 CVEs
 before 0:2.9.0-2.rhaos4.7.git1d56dc8.el8
0:2.9.0-2.rhaos4.7.git1d56dc8.el8
ignition-validate-debuginfo
Red Hat:openshift:4.7::el8
From an advisory covering 6 CVEs
 before 0:2.9.0-2.rhaos4.7.git1d56dc8.el8
0:2.9.0-2.rhaos4.7.git1d56dc8.el8
cri-o
Red Hat:openshift:4.7::el7
From an advisory covering 6 CVEs
 before 0:1.20.0-0.rhaos4.7.git8921e00.el7.51
0:1.20.0-0.rhaos4.7.git8921e00.el7.51
cri-o-debuginfo
Red Hat:openshift:4.7::el7
From an advisory covering 6 CVEs
 before 0:1.20.0-0.rhaos4.7.git8921e00.el7.51
0:1.20.0-0.rhaos4.7.git8921e00.el7.51
cri-tools
Red Hat:openshift:4.7::el7
From an advisory covering 6 CVEs
 before 0:1.18.0-3.el7
0:1.18.0-3.el7
cri-tools-debuginfo
Red Hat:openshift:4.7::el7
From an advisory covering 6 CVEs
 before 0:1.18.0-3.el7
0:1.18.0-3.el7
cri-o
Red Hat:openshift:4.7::el8
From an advisory covering 6 CVEs
 before 0:1.20.0-0.rhaos4.7.git8921e00.el8.51
0:1.20.0-0.rhaos4.7.git8921e00.el8.51
cri-o-debuginfo
Red Hat:openshift:4.7::el8
From an advisory covering 6 CVEs
 before 0:1.20.0-0.rhaos4.7.git8921e00.el8.51
0:1.20.0-0.rhaos4.7.git8921e00.el8.51
cri-o-debugsource
Red Hat:openshift:4.7::el8
From an advisory covering 6 CVEs
 before 0:1.20.0-0.rhaos4.7.git8921e00.el8.51
0:1.20.0-0.rhaos4.7.git8921e00.el8.51
cri-tools
Red Hat:openshift:4.7::el8
From an advisory covering 6 CVEs
 before 0:1.20.0-1.el8
0:1.20.0-1.el8
cri-tools-debuginfo
Red Hat:openshift:4.7::el8
From an advisory covering 6 CVEs
 before 0:1.20.0-1.el8
0:1.20.0-1.el8
cri-tools-debugsource
Red Hat:openshift:4.7::el8
From an advisory covering 6 CVEs
 before 0:1.20.0-1.el8
0:1.20.0-1.el8
containerd
SUSE:Linux Enterprise Module for Containers 12
From an advisory covering 3 CVEs
 before 1.3.9-16.35.1
1.3.9-16.35.1
docker
SUSE:Linux Enterprise Module for Containers 12
From an advisory covering 3 CVEs
 before 19.03.15_ce-98.60.2
19.03.15_ce-98.60.2
docker-runc
SUSE:Linux Enterprise Module for Containers 12
From an advisory covering 3 CVEs
 before 1.0.0rc10+gitr3981_dc9208a3303f-1.52.1
1.0.0rc10+gitr3981_dc9208a3303f-1.52.1
golang-github-docker-libnetwork
SUSE:Linux Enterprise Module for Containers 12
From an advisory covering 3 CVEs
 before 0.7.0.1+gitr2908_55e924b8a842-37.1
0.7.0.1+gitr2908_55e924b8a842-37.1
libcontainers-common
SUSE:Linux Enterprise Module for Basesystem 15 SP3
From an advisory covering 7 CVEs
 before 20210626-150300.8.3.1
20210626-150300.8.3.1
libseccomp
SUSE:Linux Enterprise Module for Basesystem 15 SP3
From an advisory covering 7 CVEs
 before 2.5.3-150300.10.5.1
2.5.3-150300.10.5.1
conmon
SUSE:Linux Enterprise Module for Containers 15 SP3
From an advisory covering 7 CVEs
 before 2.0.30-150300.8.3.1
2.0.30-150300.8.3.1
podman
SUSE:Linux Enterprise Module for Containers 15 SP3
From an advisory covering 7 CVEs
 before 3.4.4-150300.9.3.2
3.4.4-150300.9.3.2
conmon
SUSE:Linux Enterprise Micro 5.1
From an advisory covering 7 CVEs
 before 2.0.30-150300.8.3.1
2.0.30-150300.8.3.1
libcontainers-common
SUSE:Linux Enterprise Micro 5.1
From an advisory covering 7 CVEs
 before 20210626-150300.8.3.1
20210626-150300.8.3.1
libseccomp
SUSE:Linux Enterprise Micro 5.1
From an advisory covering 7 CVEs
 before 2.5.3-150300.10.5.1
2.5.3-150300.10.5.1
podman
SUSE:Linux Enterprise Micro 5.1
From an advisory covering 7 CVEs
 before 3.4.4-150300.9.3.2
3.4.4-150300.9.3.2
libcontainers-common
SUSE:Linux Enterprise High Performance Computing 15 SP1-ESPOS
From an advisory covering 5 CVEs
 before 20210626-150100.3.15.1
20210626-150100.3.15.1
libcontainers-common
SUSE:Linux Enterprise High Performance Computing 15 SP1-LTSS
From an advisory covering 5 CVEs
 before 20210626-150100.3.15.1
20210626-150100.3.15.1
libcontainers-common
SUSE:Linux Enterprise High Performance Computing 15 SP2-ESPOS
From an advisory covering 5 CVEs
 before 20210626-150100.3.15.1
20210626-150100.3.15.1
libcontainers-common
SUSE:Linux Enterprise High Performance Computing 15 SP2-LTSS
From an advisory covering 5 CVEs
 before 20210626-150100.3.15.1
20210626-150100.3.15.1
libcontainers-common
SUSE:Linux Enterprise Server 15 SP1-BCL
From an advisory covering 5 CVEs
 before 20210626-150100.3.15.1
20210626-150100.3.15.1
libcontainers-common
SUSE:Linux Enterprise Server 15 SP1-LTSS
From an advisory covering 5 CVEs
 before 20210626-150100.3.15.1
20210626-150100.3.15.1
libcontainers-common
SUSE:Linux Enterprise Server 15 SP2-BCL
From an advisory covering 5 CVEs
 before 20210626-150100.3.15.1
20210626-150100.3.15.1
libcontainers-common
SUSE:Linux Enterprise Server 15 SP2-LTSS
From an advisory covering 5 CVEs
 before 20210626-150100.3.15.1
20210626-150100.3.15.1
libcontainers-common
SUSE:Linux Enterprise Server for SAP Applications 15 SP1
From an advisory covering 5 CVEs
 before 20210626-150100.3.15.1
20210626-150100.3.15.1
libcontainers-common
SUSE:Linux Enterprise Server for SAP Applications 15 SP2
From an advisory covering 5 CVEs
 before 20210626-150100.3.15.1
20210626-150100.3.15.1
libcontainers-common
SUSE:Manager Proxy 4.1
From an advisory covering 5 CVEs
 before 20210626-150100.3.15.1
20210626-150100.3.15.1
libcontainers-common
SUSE:Manager Retail Branch Server 4.1
From an advisory covering 5 CVEs
 before 20210626-150100.3.15.1
20210626-150100.3.15.1
libcontainers-common
SUSE:Manager Server 4.1
From an advisory covering 5 CVEs
 before 20210626-150100.3.15.1
20210626-150100.3.15.1
libcontainers-common
SUSE:Enterprise Storage 6
From an advisory covering 5 CVEs
 before 20210626-150100.3.15.1
20210626-150100.3.15.1
libcontainers-common
SUSE:Enterprise Storage 7
From an advisory covering 5 CVEs
 before 20210626-150100.3.15.1
20210626-150100.3.15.1
containerd
Ubuntu:16.04:LTS
 before 1.2.6-0ubuntu1~16.04.4, plus listed versions
0.2.1-0ubuntu4~16.040.2.3-0ubuntu1~16.040.2.5-0ubuntu1~16.04.11.2.6-0ubuntu1~16.04.21.2.6-0ubuntu1~16.04.3
1.2.6-0ubuntu1~16.04.4
docker.io
Ubuntu:16.04:LTS
 before 18.09.7-0ubuntu1~16.04.6, plus listed versions
1.6.2~dfsg1-1ubuntu41.10.2-0ubuntu31.10.2-0ubuntu41.10.3-0ubuntu11.10.3-0ubuntu4
Show 15 moreShow less
1.10.3-0ubuntu51.10.3-0ubuntu61.11.2-0ubuntu5~16.041.12.1-0ubuntu13~16.04.11.12.3-0ubuntu4~16.04.21.12.6-0ubuntu1~16.04.11.13.1-0ubuntu1~16.04.217.03.2-0ubuntu2~16.04.118.06.1-0ubuntu1~16.04.218.06.1-0ubuntu1.2~16.04.118.09.2-0ubuntu1~16.04.118.09.5-0ubuntu1~16.04.218.09.7-0ubuntu1~16.04.118.09.7-0ubuntu1~16.04.418.09.7-0ubuntu1~16.04.5
18.09.7-0ubuntu1~16.04.6
docker.io
Ubuntu:18.04:LTS
 before 19.03.6-0ubuntu1~18.04.2, plus listed versions
1.13.1-0ubuntu617.03.2-0ubuntu117.03.2-0ubuntu317.03.2-0ubuntu517.12.1-0ubuntu1
Show 8 moreShow less
18.06.1-0ubuntu1~18.04.118.06.1-0ubuntu1.2~18.04.118.09.2-0ubuntu1~18.04.118.09.5-0ubuntu1~18.04.218.09.7-0ubuntu1~18.04.118.09.7-0ubuntu1~18.04.318.09.7-0ubuntu1~18.04.419.03.6-0ubuntu1~18.04.1
19.03.6-0ubuntu1~18.04.2
docker.io
Ubuntu:20.04:LTS
 before 19.03.8-0ubuntu1.20.04.1, plus listed versions
19.03.2-0ubuntu119.03.6-0ubuntu119.03.8-0ubuntu119.03.8-0ubuntu1.20.04
19.03.8-0ubuntu1.20.04.1
conmon
openSUSE:Leap 15.3
From an advisory covering 7 CVEs
 before 2.0.30-150300.8.3.1
2.0.30-150300.8.3.1
libcontainers-common
openSUSE:Leap 15.3
From an advisory covering 7 CVEs
 before 20210626-150300.8.3.1
20210626-150300.8.3.1
libseccomp
openSUSE:Leap 15.3
From an advisory covering 7 CVEs
 before 2.5.3-150300.10.5.1
2.5.3-150300.10.5.1
podman
openSUSE:Leap 15.3
From an advisory covering 7 CVEs
 before 3.4.4-150300.9.3.2
3.4.4-150300.9.3.2
containerd
openSUSE:Tumbleweed
From an advisory covering 9 CVEs
 before 1.4.8-2.2
1.4.8-2.2
libcontainers-common
openSUSE:Tumbleweed
From an advisory covering 5 CVEs
 before 20210626-7.1
20210626-7.1

History

History
RecordedChangedSources
affected, facts
aliasesEUVD
first indexedCVE List, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2020-15157 is a medium vulnerability (CVSS 6.1) in Containerd, published October 15, 2020. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 2.30%, the 83rd percentile. Fixed in github.com/containerd/containerd 1.2.14.

References

Show 80 moreShow less
This page doesn't list everything

Left out here: the rest of 3 source descriptions. The JSON record has them.

Pages All vulnerabilities Browse Docs Sources Guide Get API key
MoveEnter Open