Filtered by vendor Zotregistry
Subscriptions
Total
2 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-31801 | 2 Project-zot, Zotregistry | 2 Zot, Zot | 2026-03-18 | 7.7 High |
| zot is ancontainer image/artifact registry based on the Open Container Initiative Distribution Specification. From 1.3.0 to 2.1.14, zot’s dist-spec authorization middleware infers the required action for PUT /v2/{name}/manifests/{reference} as create by default, and only switches to update when the tag already exists and reference != "latest". As a result, when latest already exists, a user who is allowed to create (but not allowed to update) can still pass the authorization check for an overwrite attempt of latest. This vulnerability is fixed in 2.1.15. | ||||
| CVE-2024-39897 | 1 Zotregistry | 1 Zot | 2025-04-23 | 4.3 Medium |
| zot is an OCI image registry. Prior to 2.1.0, the cache driver `GetBlob()` allows read access to any blob without access control check. If a Zot `accessControl` policy allows users read access to some repositories but restricts read access to other repositories and `dedupe` is enabled (it is enabled by default), then an attacker who knows the name of an image and the digest of a blob (that they do not have read access to), they may maliciously read it via a second repository they do have read access to. This attack is possible because [`ImageStore.CheckBlob()` calls `checkCacheBlob()`](https://github.com/project-zot/zot/blob/v2.1.0-rc2/pkg/storage/imagestore/imagestore.go#L1158-L1159) to find the blob a global cache by searching for the digest. If it is found, it is copied to the user requested repository with `copyBlob()`. The attack may be mitigated by configuring "dedupe": false in the "storage" settings. The vulnerability is fixed in 2.1.0. | ||||
Page 1 of 1.