How severe is GHSA-85jx-fm8m-x8c6?

GHSA-85jx-fm8m-x8c6 has a CVSS score of 7.7/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by GHSA-85jx-fm8m-x8c6?

GHSA-85jx-fm8m-x8c6 affects the following packages: zotregistry.dev/zot/v2 (Go), zotregistry.dev/zot (Go). Ecosystems affected: Go.

How do I fix GHSA-85jx-fm8m-x8c6?

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 GHSA-85jx-fm8m-x8c6 is resolved across your whole dependency graph.

How do I detect GHSA-85jx-fm8m-x8c6 in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for zotregistry.dev/zot/v2. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-85jx-fm8m-x8c6 if there is no patch (or I can't update yet)?

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 does O3 Security protect against GHSA-85jx-fm8m-x8c6?

O3 pinpoints whether GHSA-85jx-fm8m-x8c6 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-85jx-fm8m-x8c6 actively exploited in the wild?

No public exploit code has been indexed for GHSA-85jx-fm8m-x8c6 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-85jx-fm8m-x8c6?

GHSA-85jx-fm8m-x8c6 has an EPSS (Exploit Prediction Scoring System) score of 0.2%, placing it in the 11th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-85jx-fm8m-x8c6?

GHSA-85jx-fm8m-x8c6 is classified as CWE-863 (CWE-863). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-85jx-fm8m-x8c6 published, and has it been updated?

GHSA-85jx-fm8m-x8c6 was published on March 10, 2026 and was last updated on March 23, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹 Go

GHSA-85jx-fm8m-x8c6

HIGH

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

Also known asCVE-2026-31801GO-2026-4668

Published

Mar 10, 2026

Updated

Mar 23, 2026

Affected

2 pkgs

Patched

1 / 2

Exploits

None indexed

EPSS Exploitation Probability

via FIRST.org ↗

0.2%probability of exploitation in next 30 days

Lower Risk11th percentile+0.17%

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.

Blast Radius

2 pkgs affected

🐹zotregistry.dev/zot/v2🐹zotregistry.dev/zot

Real-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 attacker has create but not update on 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 (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

Affected Packages

2 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`zotregistry.dev/zot/v2`	all versions	2.1.15
🐹Go	`zotregistry.dev/zot`	≥ 1.3.0-20210831063041-c8779d9e87d9	No fix

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for zotregistry.dev/zot/v2. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 GHSA-85jx-fm8m-x8c6 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 pinpoints whether GHSA-85jx-fm8m-x8c6 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-85jx-fm8m-x8c6. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

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

O3 Security · Impact-Aware SCA

Is GHSA-85jx-fm8m-x8c6 in your dependencies?

O3 detects GHSA-85jx-fm8m-x8c6 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works