Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Systems that run distribution built after a specific commit running on memory-restricted environments can suffer from denial of service by a crafted malicious /v2/catalog API endpoint request. Patches Upgrade to at least 2.8.2-beta.1 if you are running v2.8.x release. If you use the code from the main branch, update at least to the commit after f55a6552b006a381d9167e328808565dd2bf77dc. Workarounds There is no way to work around this issue without patching. Restrict access to the affected API endpoint: see the recommendations section. References /v2/catalog endpoint accepts a parameter to control the maximum amount of records returned (query string: n). When not given the default n=100 is used. The server trusts that n has an acceptable value, however when using a maliciously large value, it allocates an array/slice of n of strings before filling the slice with data. This behaviour was introduced ~7yrs ago [1]. Recommendation The /v2/catalog endpoint was designed specifically…
Recommended action: Upgrade to 2.8.2-beta.1 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Docker Registry before 2.6.2 in Docker Distribution does not properly restrict the amount of content accepted from a user, which allows remote attackers to cause a denial of service (memory consumption) via the manifest endpoint. Specific Go Packages Affected github.com/docker/distribution/registry/storage github.com/docker/distribution/registry/handlers
Recommended action: Upgrade to 2.7.0-rc.0 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Systems that rely on digest equivalence for image attestations may be vulnerable to type confusion. Patches Upgrade to at least v2.8.0-beta.1 if you are running v2.x release. If you use the code from the main branch, update at least to the commit after b59a6f827947f9e0e67df0cfb571046de4733586. Workarounds There is no way to work around this issue without patching. References Due to an oversight in the OCI Image Specification that removed the embedded mediaType field from manifests, a maliciously crafted OCI Container Image can cause registry clients to parse the same image in two different ways without modifying the image’s digest by modifying the Content-Type header returned by a registry. This can invalidate a common pattern of relying on container image digests for equivalence. For more information If you have any questions or comments about this advisory: Open an issue in distribution Open an issue in distribution-spec Email us at cncf-distribution-security@lists.cncf.io
Recommended action: Upgrade to 2.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.