GHSA-WHQX-F9J3-CH6M

Vulnerability from github – Published: 2026-01-13 14:58 – Updated: 2026-01-13 14:58
VLAI
Summary
Cosign verification accepts any valid Rekor entry under certain conditions
Details

Impact

A Cosign bundle can be crafted to successfully verify an artifact even if the embedded Rekor entry does not reference the artifact's digest, signature or public key. When verifying a Rekor entry, Cosign verifies the Rekor entry signature, and also compares the artifact's digest, the user's 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's 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.

This 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.

This 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.

Steps to Reproduce

echo blob > /tmp/blob
cosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.1 --use-signing-config=false /tmp/blob
cosign sign-blob -y --new-bundle-format=false --bundle /tmp/bundle.2 --use-signing-config=false /tmp/blob
jq ".rekorBundle |= $(jq .rekorBundle /tmp/bundle.2)" /tmp/bundle.1 > /tmp/bundle.3
cosign verify-blob --bundle /tmp/bundle.3 --certificate-identity-regexp='.*' --certificate-oidc-issuer-regexp='.*' /tmp/blob

Patches

Upgrade to Cosign v2.6.2 or Cosign v3.0.4. This does not affect Cosign v1.

Workarounds

You 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.

Note that the example below works for cosign verify, cosign verify-blob,cosign verify-blob-attestation, andcosign verify-attestation`.

SIGSTORE_REKOR_PUBLIC_KEY=<path to Rekor pub key> cosign verify-blob --use-signing-config=false --new-bundle-format=false --bundle=<path to bundle> <artifact>
Severity
5.5 (Medium)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "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"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





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.


Detection rules are retrieved from Rulezet.