Skip to content

zot’s create-only policy allows overwrite attempts of existing latest tag (update permission not required)

High severity GitHub Reviewed Published Mar 9, 2026 in project-zot/zot • Updated Mar 10, 2026

Package

gomod zotregistry.dev/zot (Go)

Affected versions

>= 1.3.0-20210831063041-c8779d9e87d9, <= 1.4.4-20251014054906-73eef25681af

Patched versions

None
gomod zotregistry.dev/zot/v2 (Go)
< 2.1.15
2.1.15

Description

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.

affected component

  • file: pkg/api/authz.go (DistSpecAuthzHandler)
  • condition: slices.Contains(tags, reference) && reference != "latest" (line 352 at the pinned commit)

severity

HIGH
category: CWE-863 (incorrect authorization)

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.

steps to reproduce

  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.

the attached poc demonstrates this deterministically with canonical.log and control.log markers.

expected vs actual

  • expected: overwriting an existing tag should require update permission, including latest (or latest should be explicitly documented as exempt).
  • actual: when reference=="latest" and the tag exists, the middleware keeps the action as create instead of switching to update.

security impact

this can break least-privilege expectations in deployments that rely on the create vs update split to prevent tag overwrites (for example, “push-once” policies). if latest is used as a high-trust tag in ci/cd, this can create supply-chain risk because a create-only principal can overwrite an existing latest tag while other existing tags correctly require update.

suggested fix

remove the special-case exemption for latest when determining whether an existing tag requires update permission (treat latest the same as other tags), or document and enforce an explicit policy rule for latest.

notes / rationale

  • oci distribution spec does not define a standard authorization model; this report is about zot’s own create vs update semantics and the observable behavior in DistSpecAuthzHandler.
  • zot documentation describes immutable tags as being enforceable via authorization policies (create-only “push once”, update disallowed). if latest is exempt, this control does not apply to latest unless documented otherwise.

addendum.md
poc.zip
PR_DESCRIPTION.md
RUNNABLE_POC.md

References

@rchincha rchincha published to project-zot/zot Mar 9, 2026
Published by the National Vulnerability Database Mar 10, 2026
Published to the GitHub Advisory Database Mar 10, 2026
Reviewed Mar 10, 2026
Last updated Mar 10, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Changed
Confidentiality
None
Integrity
High
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(8th percentile)

Weaknesses

Incorrect Authorization

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. Learn more on MITRE.

CVE ID

CVE-2026-31801

GHSA ID

GHSA-85jx-fm8m-x8c6

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.