https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 21:26:18 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-6270 EUVD-2026-6270 https://cve.radiocsirt.org/vuln/euvd-2026-6270 https://cve.radiocsirt.org/vuln/fkie_cve-2024-39897 <p>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 &#34;dedupe&#34;: false in the &#34;storage&#34; settings. The vulnerability is fixed in 2.1.0.</p> <p>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 &#34;dedupe&#34;: false in the &#34;storage&#34; settings. The vulnerability is fixed in 2.1.0.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-39897 https://cve.radiocsirt.org/vuln/ghsa-55r9-5mx9-qq7r <p><strong>Affected:</strong> Go: zotregistry.io/zot, Go: zotregistry.dev/zot</p> <p>### Summary</p> <p>Cache driver `GetBlob()` allows read access to any blob without access control check</p> <p>### Details</p> <p>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 allows an attacker to read an image that the `accessControl` policy denies.</p> <p>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()`.</p> <p>This cache behavior is intentionally used in [`RouteHandler.CreateBlobUpload()`](https://github.com/project-zot/zot/blob/v2.1.0-rc2/pkg/api/routes.go#L1194-L1197) to implement cross repository blob mount (`POST /v2/&lt;name&gt;/blobs/uploads/?mount=&lt;digest&gt;&amp;from=&lt;repository name&gt;`) in Zot. This is still missing an access control to check read access on the source repository.</p> <p>This cache behavior is unexpectedly also used in [`RouteHandler.CheckBlob()`](https://github.com/project-zot/zot/blob/v2.1.0-rc2/pkg/api/routes.go#L886) too for `HEAD /v2/&lt;name&gt;/blobs/&lt;digest&gt;`. If a blob is requested that does not…</p> <p><strong>Affected:</strong> Go: zotregistry.io/zot, Go: zotregistry.dev/zot</p> <p>### Summary</p> <p>Cache driver `GetBlob()` allows read access to any blob without access control check</p> <p>### Details</p> <p>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 allows an attacker to read an image that the `accessControl` policy denies.</p> <p>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()`.</p> <p>This cache behavior is intentionally used in [`RouteHandler.CreateBlobUpload()`](https://github.com/project-zot/zot/blob/v2.1.0-rc2/pkg/api/routes.go#L1194-L1197) to implement cross repository blob mount (`POST /v2/&lt;name&gt;/blobs/uploads/?mount=&lt;digest&gt;&amp;from=&lt;repository name&gt;`) in Zot. This is still missing an access control to check read access on the source repository.</p> <p>This cache behavior is unexpectedly also used in [`RouteHandler.CheckBlob()`](https://github.com/project-zot/zot/blob/v2.1.0-rc2/pkg/api/routes.go#L886) too for `HEAD /v2/&lt;name&gt;/blobs/&lt;digest&gt;`. If a blob is requested that does not…</p> https://cve.radiocsirt.org/vuln/ghsa-55r9-5mx9-qq7r