CVE-2026-31801 — v2
HIGHCVE-2026-31801 is a high-severity (CVSS 7.7) CWE-863 vulnerability in zotregistry.dev/zot/v2. A fix is available for zotregistry.dev/zot/v2 — see the affected versions and patch details below.
zot create-only policy allows overwrite attempts of existing latest tag (update permission not required)
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-31801.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
CVE-2026-31801 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,636 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
zotregistry.dev/zot/v2🐹zotregistry.dev/zotReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
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
- configure access control so user
attackerhascreatebut notupdateon a repository. - ensure the repository has an existing tag named
latest. - attempt to push a new manifest to
/v2/acme/app/manifests/latest(example repository name). - observe that the authorization check is evaluated as
create(notupdate) forlatest, 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
updatepermission, includinglatest(orlatestshould be explicitly documented as exempt). - actual: when
reference=="latest"and the tag exists, the middleware keeps the action ascreateinstead of switching toupdate.
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
latestis exempt, this control does not apply tolatestunless documented otherwise.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | zotregistry.dev/zot/v2 | all versions | 2.1.15go get zotregistry.dev/zot/v2@v2.1.15 |
| 🐹Go | zotregistry.dev/zot | ≥ 1.3.0-20210831063041-c8779d9e87d9 | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for zotregistry.dev/zot/v2, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update zotregistry.dev/zot/v2 to 2.1.15 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-31801 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-31801 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-31801. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-31801 in your dependencies?
O3 Security finds CVE-2026-31801 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.