{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.8.2"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/fulcio"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-66506"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-405"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-05T18:18:26Z",
    "nvd_published_at": "2025-12-04T22:15:49Z",
    "severity": "HIGH"
  },
  "details": "Function [identity.extractIssuerURL](https://github.com/sigstore/fulcio/blob/main/pkg/identity/issuerpool.go#L44-L45) currently splits (via a call to [strings.Split](https://pkg.go.dev/strings#Split)) its argument (which is untrusted data) on periods.\n\nAs a result, in the face of a malicious request with an (invalid) OIDC identity token in the payload containing many period characters, a call to `extractIssuerURL` incurs allocations to the tune of O(n) bytes (where n stands for the length of the function\u0027s argument), with a constant factor of about 16. Relevant weakness: [CWE-405: Asymmetric Resource Consumption (Amplification)](https://cwe.mitre.org/data/definitions/405.html)\n\nDetails\nSee [identity.extractIssuerURL](https://github.com/sigstore/fulcio/blob/main/pkg/identity/issuerpool.go#L44-L45)\n\nImpact\nExcessive memory allocation",
  "id": "GHSA-f83f-xpx7-ffpw",
  "modified": "2025-12-05T18:18:26Z",
  "published": "2025-12-05T18:18:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/fulcio/security/advisories/GHSA-f83f-xpx7-ffpw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66506"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/fulcio/commit/765a0e57608b9ef390e1eeeea8595b9054c63a5a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/fulcio"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Fulcio allocates excessive memory during token parsing"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.10.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/sigstore"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.10.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24137"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-22T20:28:56Z",
    "nvd_published_at": "2026-01-23T00:15:52Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe legacy TUF client `pkg/tuf/client.go`, which supports caching target files to disk, constructs a filesystem path by joining a cache base directory with a target name sourced from signed target metadata, but it does not validate that the resulting path stays within the cache base directory.\n\nNote that this should only affect clients that are directly using the TUF client in sigstore/sigstore or are using an older version of Cosign. As this TUF client implementation is deprecated, users should migrate to https://github.com/sigstore/sigstore-go/tree/main/pkg/tuf as soon as possible.\n\nNote that this does not affect users of the public Sigstore deployment, where TUF metadata is validated by a quorum of trusted collaborators. \n\n## Impact\n\nA malicious TUF repository can trigger arbitrary file overwriting, limited to the permissions that the calling process has.\n\n## Workarounds\n\nUsers can disable disk caching for the legacy client by setting `SIGSTORE_NO_CACHE=true` in the environment, migrate to https://github.com/sigstore/sigstore-go/tree/main/pkg/tuf, or upgrade to the latest sigstore/sigstore release.",
  "id": "GHSA-fcv2-xgw5-pqxf",
  "modified": "2026-02-27T21:37:24Z",
  "published": "2026-01-22T20:28:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore/security/advisories/GHSA-fcv2-xgw5-pqxf"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24137"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore/commit/8ec410a2993ea78083aecf0e473a85453039496e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/sigstore"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore/releases/tag/v1.10.4"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2026-4358"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "sigstore legacy TUF client allows for arbitrary file writes with target cache path traversal"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/theupdateframework/go-tuf/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-23992"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-21T16:19:32Z",
    "nvd_published_at": "2026-01-22T03:15:47Z",
    "severity": "MODERATE"
  },
  "details": "# Security Disclosure: Improper validation of configured threshold for delegations\n\n## Summary\n\nA compromised or misconfigured TUF repository can have the configured value of signature thresholds set to 0, which effectively disables signature verification. \n\n## Impact\n\nUnathorized modification to TUF metadata files is possible at rest, or during transit as no integrity checks are made.\n\n## Patches\n\nUpgrade to v2.3.1\n\n## Workarounds\n\nAlways make sure that the TUF metadata roles are configured with a threshold of at least 1.\n\n## Affected code:\n\nThe `metadata.VerifyDelegate` did not verify the configured threshold prior to comparison. This means that a misconfigured TUF repository could disable the signature verification by setting the threshold to 0, or a negative value (and so always make the signature threshold computation to pass).",
  "id": "GHSA-fphv-w9fq-2525",
  "modified": "2026-01-22T15:43:46Z",
  "published": "2026-01-21T16:19:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/go-tuf/security/advisories/GHSA-fphv-w9fq-2525"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23992"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/go-tuf/commit/b38d91fdbc69dfe31fe9230d97dafe527ea854a0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/theupdateframework/go-tuf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/go-tuf/releases/tag/v2.3.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "go-tuf improperly validates the configured threshold for delegations"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/theupdateframework/go-tuf/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24686"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-26T23:49:55Z",
    "nvd_published_at": "2026-01-27T01:16:02Z",
    "severity": "MODERATE"
  },
  "details": "# Security Vulnerability: Path Traversal in TAP 4 Multirepo Client\n\n## Summary\n\ngo-tuf\u0027s TAP 4 Multirepo Client uses the map file repository name string (`repoName`) as a filesystem path component when selecting the local metadata cache directory. If an application accepts a map file from an untrusted source, an attacker can supply a `repoName` containing traversal (e.g., `../escaped-repo`) and cause go-tuf to create directories and write the root metadata file outside the intended `LocalMetadataDir` cache base, within the running process\u0027s filesystem permissions.\n\n## Affected Component\n\n| Field | Value |\n|-------|-------|\n| **File** | `metadata/multirepo/multirepo.go` |\n| **Function** | `(*MultiRepoClient) initTUFClients() error` |\n| **Callsite** | `metadataDir := filepath.Join(client.Config.LocalMetadataDir, repoName)` (around line 129 at the pinned commit) |\n\n## Impact\n\nWhen the TAP 4 map file content is attacker-controlled, this enables arbitrary file write relative to the process permissions (via metadata persistence during client initialization). This can be used to overwrite files writable by the process (for example, configuration files in writable directories) and may enable further compromise depending on the deployment environment.\n\n\u003e **Note:** Exploitability is deployment-dependent. If the map file is always local and trusted (not attacker-controlled), this reduces to a misconfiguration risk rather than a remotely triggerable issue.\n\n## Attacker Model\n\n- Attacker can cause the application to load a TAP 4 map file whose `repositories` keys are attacker-controlled (for example: fetched from a URL, supply-chain substituted, or otherwise attacker-influenced input).\n- Local caching is enabled (`DisableLocalCache=false`) and the configured `LocalMetadataDir` is writable by the running process.\n\n**Claim Ceiling:** HIGH when the map file is attacker-controlled; if the map file is always local and trusted, this is closer to a configuration footgun and likely lands as MEDIUM/LOW.\n\n| Field | Value |\n|-------|-------|\n| **Affected Versions** | \u2264 2.4.0 |\n| **Verified On** | Commit `bde5f18dc95dfac365fc452ee4e278e5fd66d4b4` (tag v2.4.0) |\n\n\u003e **Note:** First affected version has not been bisected.\n\n## Reproduction\n\nAttachments include `poc.zip` with:\n- `canonical.log` (contains `[CALLSITE_HIT]`, `[PROOF_MARKER]`)\n- `control.log` (contains `[CALLSITE_HIT]`, `[NC_MARKER]`, does not contain `[PROOF_MARKER]`)\n- `fix.patch` (minimal validation sketch)\n\n**Expected:** Multirepo repository names are treated as identifiers; a TAP 4 map file containing traversal or absolute paths is rejected (or safely normalized so that all writes stay under `LocalMetadataDir`).\n\n**Actual:** A traversal `repoName` escapes `LocalMetadataDir` and go-tuf persists `root.json` under the escaped path during initialization.\n\n### Run Local Repro\n\n```bash\nrm -rf _poc\nmkdir -p _poc\nunzip -q -o poc.zip -d _poc\ncd _poc/poc\nmake canonical\nmake control\n```\n\n## Workarounds\n\n1. Treat TAP 4 map files as trusted configuration only (do not fetch from untrusted sources).\n2. Validate repo names before passing the map file to go-tuf (reject absolute paths, path separators, and traversal components like `.` / `..`).\n3. If acceptable for the application, disable local caching to avoid writing metadata to disk (`DisableLocalCache=true`).\n\n## Suggested Remediation\n\nValidate multirepo repository names as identifiers (not paths) before using them in `filepath.Join`. Reject:\n- Absolute paths\n- Path separators (`/` and `\\`)\n- Traversal components (`.` and `..`)\n\nIf it is important to accept a wider set of repo names, a safer alternative is to map repo names to a stable, validated directory name (for example via encoding or hashing) and to ensure all writes stay under the cache base directory.\n\n## Triage Questions\n\n1. Is the TAP 4 map file expected to ever be fetched from untrusted sources in supported deployments?\n2. Should invalid repo names be treated as a hard error (reject initialization), or as a soft error (skip that repository entry)?\n\n## Attachments\n\n- [poc.zip](https://github.com/user-attachments/files/24849854/poc.zip)\n- [addendum.md](https://github.com/user-attachments/files/24849855/addendum.md)\n- [e2e.zip](https://github.com/user-attachments/files/24849856/e2e.zip)\n- [PR_DESCRIPTION.md](https://github.com/user-attachments/files/24849858/PR_DESCRIPTION.md)\n\n---\n\n*Reported by: Oleh*",
  "id": "GHSA-jqc5-w2xx-5vq4",
  "modified": "2026-01-29T03:26:24Z",
  "published": "2026-01-26T23:49:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/go-tuf/security/advisories/GHSA-jqc5-w2xx-5vq4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24686"
    },
    {
      "type": "WEB",
      "url": "https://github.com/theupdateframework/go-tuf/commit/d361e2ea24e427581343dee5c7a32b485d79fcc0"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/theupdateframework/go-tuf"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "go-tuf Path Traversal in TAP 4 Multirepo Client Allows Arbitrary File Write via Malicious Repository Names"
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.0.3"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/cosign/v3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.6.1"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/sigstore/cosign/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.6.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22703"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-13T14:58:50Z",
    "nvd_published_at": "2026-01-10T07:16:03Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nA Cosign bundle can be crafted to successfully verify an artifact even if the embedded Rekor entry does not reference the artifact\u0027s digest, signature or public key. When verifying a Rekor entry, Cosign verifies the Rekor entry signature, and also compares the artifact\u0027s digest, the user\u0027s public key from either a Fulcio certificate or provided by the user, and the artifact signature to the Rekor entry contents. Without these comparisons, Cosign would accept any response from Rekor as valid. A malicious actor that has compromised a user\u0027s identity or signing key could construct a valid Cosign bundle by including any arbitrary Rekor entry, thus preventing the user from being able to audit the signing event.\n\nThis vulnerability only affects users that provide a trusted root via `--trusted-root` or when fetched automatically from a TUF repository, when no trusted key material is provided via `SIGSTORE_REKOR_PUBLIC_KEY`. When using the default flag values in Cosign v3 to sign and verify (`--use-signing-config=true` and `--new-bundle-format=true` for signing, `--new-bundle-format=true` for verification), users are unaffected. Cosign v2 users are affected using the default flag values.\n\nThis issue had previously been fixed in https://github.com/sigstore/cosign/security/advisories/GHSA-8gw7-4j42-w388 but recent refactoring caused a regression. We have added testing to prevent a future regression.\n\n#### Steps to Reproduce\n\n```\necho blob \u003e /tmp/blob\ncosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.1 --use-signing-config=false /tmp/blob\ncosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.2 --use-signing-config=false /tmp/blob\njq \".rekorBundle |= $(jq .rekorBundle /tmp/bundle.2)\" /tmp/bundle.1 \u003e /tmp/bundle.3\ncosign verify-blob --bundle /tmp/bundle.3 --certificate-identity-regexp=\u0027.*\u0027 --certificate-oidc-issuer-regexp=\u0027.*\u0027 /tmp/blob\n```\n\n### Patches\n\nUpgrade to Cosign v2.6.2 or Cosign v3.0.4. This does not affect Cosign v1.\n\n### Workarounds\n\nYou can provide trusted key material via a set of flags under certain conditions. The simplest fix is to upgrade to the latest Cosign v2 or v3 release.\n\nNote that the example below works for `cosign verify`, `cosign verify-blob, `cosign verify-blob-attestation`, and `cosign verify-attestation`.\n\n```\nSIGSTORE_REKOR_PUBLIC_KEY=\u003cpath to Rekor pub key\u003e cosign verify-blob --use-signing-config=false --new-bundle-format=false --bundle=\u003cpath to bundle\u003e \u003cartifact\u003e\n```",
  "id": "GHSA-whqx-f9j3-ch6m",
  "modified": "2026-01-13T14:58:50Z",
  "published": "2026-01-13T14:58:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/security/advisories/GHSA-whqx-f9j3-ch6m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22703"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/pull/4623"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/cosign/commit/6832fba4928c1ad69400235bbc41212de5006176"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/cosign"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Cosign verification accepts any valid Rekor entry under certain conditions"
}