CVE-2026-31801

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.

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

The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions. Typical impact: unauthorized data access or execution of privileged operations.

CVE-2026-31801 has a CVSS score of 7.7 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.1.15); upgrading removes the vulnerable code path.

Kodem intelligence

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.

1. What is CVE-2026-31801? CVE-2026-31801 is a high-severity incorrect authorization vulnerability in zotregistry.dev/zot/v2 (go), affecting versions < 2.1.15. It is fixed in 2.1.15. The application does not correctly enforce access controls, allowing a principal to access resources or operations beyond their granted permissions.
2. How severe is CVE-2026-31801? CVE-2026-31801 has a CVSS score of 7.7 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which packages are affected by CVE-2026-31801?
   • zotregistry.dev/zot/v2 (go) (versions < 2.1.15)
   • zotregistry.dev/zot (go) (versions >= 1.3.0-20210831063041-c8779d9e87d9, <= 1.4.4-20251014054906-73eef25681af)
4. Is there a fix for CVE-2026-31801? Yes. CVE-2026-31801 is fixed in 2.1.15. Upgrade to this version or later.
5. Is CVE-2026-31801 exploitable, and should I be worried? Whether CVE-2026-31801 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-31801 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-31801? Upgrade zotregistry.dev/zot/v2 to 2.1.15 or later.