Vulnerabilities in pkg:golang/zotregistry.dev/zot

PACKAGE
Advisory Identifier: GHSA-85jx-fm8m-x8c6
Advisory Summary

CVE-2026-31801 is a HIGH (CVSS 7.7) zot’s create-only policy allows overwrite vulnerability (CWE-863: Incorrect Authorization) affecting Zotregistry.dev/zot/v2 libraries in the Go ecosystem. The issue involves zot’s create-only policy allows overwrite attempts of existing latest tag (update permission not required). Remediation is available by upgrading affected packages to version 2.1.15.

4 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:golang/zotregistry.dev/zot

4 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:golang/zotregistry.dev/zot. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-85jx-fm8m-x8c6 CVE-2026-31801 HIGH zot’s create-only policy allows overwrite attempts of existing latest tag (update permission not required)
GHSA-c37v-3c8w-crq8 CVE-2025-48374 MODERATE zot logs secrets
GHSA-c9p4-xwr9-rfhx CVE-2025-23208 HIGH Zot IdP group membership revocation ignored
GHSA-55r9-5mx9-qq7r CVE-2024-39897 MODERATE Cache driver GetBlob() allows read access to any blob without access control check

CVE-2026-31801 at a Glance

CVE Identifier CVE-2026-31801
GHSA Identifier GHSA-85jx-fm8m-x8c6
Severity HIGH
CVSS v3.1 Base Score 7.7
CWE Classification CWE-863: Incorrect Authorization
Affected Product Zotregistry.dev/zot/v2
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 7.7

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality None (C:N)
Integrity High (I:H)
Availability None (A:N)

How to Fix CVE-2026-31801

To remediate this vulnerability, upgrade all affected Zotregistry.dev/zot/v2 dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

zotregistry.dev/zot/v2 fixed: 2.1.15
Upgrade zotregistry.dev/zot/v2 to 2.1.15
zotregistry.dev/zot fixed: Latest secure release
Upgrade zotregistry.dev/zot to Latest secure release
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for zotregistry.dev/zot/v2

How to Check if You Are Affected

To determine whether your application is affected by CVE-2026-31801, inspect your project dependencies for Zotregistry.dev/zot/v2:

inspect dependencies for zotregistry.dev/zot/v2

Analyze the terminal output to locate any version of Zotregistry.dev/zot/v2 in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 2.1.15), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-863: Incorrect Authorization, where 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. In Zotregistry.dev/zot/v2, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

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](https://github.com/user-attachments/files/24986139/addendum.md) [poc.zip](https://github.com/user-attachments/files/24986140/poc.zip) [PR_DESCRIPTION.md](https://github.com/user-attachments/files/24986141/PR_DESCRIPTION.md) [RUNNABLE_POC.md](https://github.com/user-attachments/files/24986142/RUNNABLE_POC.md)

CVE-2026-31801 Affected Zotregistry.dev/zot/v2 Versions

2 component(s)
Fixed Versions:
2.1.15
Product / Package Ecosystem Affected Versions Fixed Version
zotregistry.dev/zot/v2
Go
< 2.1.15
2.1.15
zotregistry.dev/zot
Go
≥ 1.3.0-20210831063041-c8779d9e87d9
≤ 1.4.4-20251014054906-73eef25681af

References

Frequently Asked Questions

What is CVE-2026-31801?
CVE-2026-31801 is a security vulnerability in Zotregistry.dev/zot/v2 involving zot’s create-only policy allows overwrite attempts of existing latest tag (update permission not required) under CWE-863: Incorrect Authorization.
Which Zotregistry.dev/zot/v2 versions are affected?
Affected versions include releases prior to 2.1.15 across affected packages: zotregistry.dev/zot/v2, zotregistry.dev/zot.
What version fixes CVE-2026-31801?
Upgrading to 2.1.15 (or the latest patched release for your respective branch) resolves the vulnerability.
Is zotregistry.dev/zot/v2 affected?
Yes, zotregistry.dev/zot/v2 is affected in releases prior to 2.1.15. Upgrade your dependency to 2.1.15 or later.
Is zotregistry.dev/zot affected?
Yes, zotregistry.dev/zot is affected in releases prior to Latest secure release. Upgrade your dependency to Latest secure release or later.
What is the CVSS score of CVE-2026-31801?
CVE-2026-31801 has a CVSS v3.1 base score of 7.7 (HIGH) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N.
What CWE is associated with CVE-2026-31801?
CVE-2026-31801 is classified under CWE-863: 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.).
How can I check Go dependencies for CVE-2026-31801?
Run the dependency tree command: 'inspect dependencies for zotregistry.dev/zot/v2'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-85jx-fm8m-x8c6",
  "modified" : "2026-03-10T23:44:25Z",
  "published" : "2026-03-10T23:44:25Z",
  "aliases" : [ "CVE-2026-31801" ],
  "summary" : "zot’s create-only policy allows overwrite attempts of existing latest tag (update permission not required)",
  "details" : "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\"`.\n\nas 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`.\n\n## affected component\n\n- file: `pkg/api/authz.go` (`DistSpecAuthzHandler`)\n- condition: `slices.Contains(tags, reference) && reference != \"latest\"` (line 352 at the pinned commit)\n\n## severity\n\nHIGH\ncategory: CWE-863 (incorrect authorization)\n\nnote: 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.\n\n## steps to reproduce\n\n1. configure access control so user `attacker` has `create` but not `update` on a repository.\n2. ensure the repository has an existing tag named `latest`.\n3. attempt to push a new manifest to `/v2/acme/app/manifests/latest` (example repository name).\n4. observe that the authorization check is evaluated as `create` (not `update`) for `latest`, so the request passes authorization even though the tag already exists.\n\nthe attached poc demonstrates this deterministically with `canonical.log` and `control.log` markers.\n\n## expected vs actual\n\n- expected: overwriting an existing tag should require `update` permission, including `latest` (or `latest` should be explicitly documented as exempt).\n- actual: when `reference==\"latest\"` and the tag exists, the middleware keeps the action as `create` instead of switching to `update`.\n\n## security impact\n\nthis 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`.\n\n## suggested fix\n\nremove 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`.\n\n## notes / rationale\n\n- 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`.\n- 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.\n\n[addendum.md](https://github.com/user-attachments/files/24986139/addendum.md)\n[poc.zip](https://github.com/user-attachments/files/24986140/poc.zip)\n[PR_DESCRIPTION.md](https://github.com/user-attachments/files/24986141/PR_DESCRIPTION.md)\n[RUNNABLE_POC.md](https://github.com/user-attachments/files/24986142/RUNNABLE_POC.md)",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "zotregistry.dev/zot/v2"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "2.1.15"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "Go",
      "name" : "zotregistry.dev/zot"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "1.3.0-20210831063041-c8779d9e87d9"
      }, {
        "last_affected" : "1.4.4-20251014054906-73eef25681af"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/project-zot/zot/security/advisories/GHSA-85jx-fm8m-x8c6"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-31801"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/project-zot/zot"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/project-zot/zot/releases/tag/v2.1.15"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-863" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-03-10T23:44:25Z",
    "nvd_published_at" : "2026-03-10T21:16:49Z"
  }
}