Evidence used
- No CISA KEV confirmation is currently recorded.
- EPSS is 2.30% for the current model date.
BlackTreeCVE Intelligencecontainerd · containerd
Official source article: GitHub GHSA-742W-89GC-8M9C ↗. Check the applicable product and release in the original source.
Medium technical severity with no CISA KEV confirmation; remediate through the normal risk-based patch cycle unless local exposure raises the priority.
Debian findings are scoped to the named distribution, release and source package. An absent finding does not mean a package is unaffected.
A published vendor fix does not prove that a matching update is enabled and installable on a particular asset. Confirm the local package candidate before scheduling remediation.
| Distribution release | Source package | Vendor state | Fixed version | Evidence |
|---|---|---|---|---|
| Debian trixietrixie · source | containerd | Vendor fix publishedDebian records a fixed source-package version for this release. | 1.3.2~ds1-2 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
| Debian trixietrixie · source | docker.io | Vendor fix publishedDebian records a fixed source-package version for this release. | 19.03.13+dfsg2-1 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
| Debian bookwormbookworm · source | containerd | Vendor fix publishedDebian records a fixed source-package version for this release. | 1.3.2~ds1-2 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
| Debian bookwormbookworm · source | docker.io | Vendor fix publishedDebian records a fixed source-package version for this release. | 19.03.13+dfsg2-1 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
| Debian forkyforky · source | containerd | Vendor fix publishedDebian records a fixed source-package version for this release. | 1.3.2~ds1-2 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
| Debian forkyforky · source | docker.io | Vendor fix publishedDebian records a fixed source-package version for this release. | 19.03.13+dfsg2-1 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
| Debian sidsid · source | containerd | Vendor fix publishedDebian records a fixed source-package version for this release. | 1.3.2~ds1-2 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
| Debian sidsid · source | docker.io | Vendor fix publishedDebian records a fixed source-package version for this release. | 19.03.13+dfsg2-1 | Debian Security Tracker ↗Source updated 5 Oct 2026 |
Medium technical severity with no CISA KEV confirmation; remediate through the normal risk-based patch cycle unless local exposure raises the priority.
Fix not verifiedIn 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.
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.
The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
An attacker operating through a network path may attempt exploitation without authentication after a user interaction. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
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.
The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
An attacker operating through a network path may attempt exploitation without authentication after a user interaction. If successful, the issue may cause the confidentiality, integrity or availability impact described by the vendor.
CVSS severity, EPSS forecast probability, public exploit material and CISA-confirmed exploitation are separate signals.
No CISA KEV match was present at the last successful refresh. This means no confirmation from that source, not proof of no exploitation.
No exploit-tagged reference or CISA SSVC proof-of-concept state is currently recorded. Research may still exist outside the structured feeds.
CWE-522: Insufficiently Protected Credentials. The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:N/A:NCommon Vulnerability Scoring System 3.1: the compact vector below is decoded into plain language.
Operational remediation based on structured source evidence.
Published 16 Oct 2020 · Last source change 4 Aug 2024, 13:08 UTC · CWE-522 · Insufficiently Protected Credentials
Core structured fields are present and their contributing authorities are shown above.
No material field changes have been recorded since change tracking began. Routine source refreshes and cosmetic edits are intentionally excluded.