https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Thu, 01 Oct 2026 11:42:58 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-31801 <p>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 != &#34;latest&#34;. 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.</p> <p>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 != &#34;latest&#34;. 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.</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-31801 https://vulnerability.circl.lu/vuln/ghsa-85jx-fm8m-x8c6 <p><strong>Affected:</strong> Go: zotregistry.dev/zot/v2, Go: zotregistry.dev/zot</p> <p>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 != &#34;latest&#34;`.</p> <p>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`.</p> <p>## affected component</p> <p>- file: `pkg/api/authz.go` (`DistSpecAuthzHandler`) - condition: `slices.Contains(tags, reference) &amp;&amp; reference != &#34;latest&#34;` (line 352 at the pinned commit)</p> <p>## severity</p> <p>HIGH category: CWE-863 (incorrect authorization)</p> <p>note: impact depends on how a deployment uses `latest` (for example, if `latest` is treated as a protected or “push-once” tag), and on how access control is provisioned (users with `create` but without `update`). the attached poc demonstrates a real overwrite of `latest` (tag digest changes) under a create-only policy.</p> <p>## steps to reproduce</p> <p>1. configure access control so user `attacker` has `create` but not `update` on a repository. 2. ensure the repository has an existing tag named `latest`. 3. attempt to push a new manifest to `/v2/acme/app/manifests/latest` (example repository name). 4. observe that the authorization check is evaluated as `create` (not `update`) for `latest`, so the request passes authorization even though the tag already exists.</p> <p>the attached poc demonstrates this deterministically with `canonical.log` and `contr…</p> <p><strong>Affected:</strong> Go: zotregistry.dev/zot/v2, Go: zotregistry.dev/zot</p> <p>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 != &#34;latest&#34;`.</p> <p>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`.</p> <p>## affected component</p> <p>- file: `pkg/api/authz.go` (`DistSpecAuthzHandler`) - condition: `slices.Contains(tags, reference) &amp;&amp; reference != &#34;latest&#34;` (line 352 at the pinned commit)</p> <p>## severity</p> <p>HIGH category: CWE-863 (incorrect authorization)</p> <p>note: impact depends on how a deployment uses `latest` (for example, if `latest` is treated as a protected or “push-once” tag), and on how access control is provisioned (users with `create` but without `update`). the attached poc demonstrates a real overwrite of `latest` (tag digest changes) under a create-only policy.</p> <p>## steps to reproduce</p> <p>1. configure access control so user `attacker` has `create` but not `update` on a repository. 2. ensure the repository has an existing tag named `latest`. 3. attempt to push a new manifest to `/v2/acme/app/manifests/latest` (example repository name). 4. observe that the authorization check is evaluated as `create` (not `update`) for `latest`, so the request passes authorization even though the tag already exists.</p> <p>the attached poc demonstrates this deterministically with `canonical.log` and `contr…</p> https://vulnerability.circl.lu/vuln/ghsa-85jx-fm8m-x8c6