CVE-2026-22703Medium· 5.5▾ SunlitCosign verification accepts any valid Rekor entry under certain conditions
▾ Sunlit zone — Low / medium · no exploitation signal
impact 30.3 · likelihood 0 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Aug 24.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via OSV
Last analysed / modified upstream
0.09%
0.09% → 0.10%
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.
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
Upgrade to Cosign v2.6.2 or Cosign v3.0.4. This does not affect Cosign v1.
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, and cosign 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>
github.com/sigstore/cosign/v3 < 3.0.4github.com/sigstore/cosign/v2 < 2.6.2Upgrade to a patched release:
github.com/sigstore/cosign/v3 3.0.4github.com/sigstore/cosign/v2 2.6.2Connected by shared product, vendor, weakness, or advisory.
CVE-2024-29902Medium· 4.2Cosign malicious attachments can cause system-wide denial of service
CVE-2026-44309Medium· 5.3gitsign verify accepts signatures over go-git-normalized bytes, enabling trust confusion on malformed commits
CVE-2026-44310Medium· 5.4gitsign --verify panics on empty-certificate PKCS7 and exits 0, bypassing exit-code callers
CVE-2022-35930High· 7.1PolicyController before 0.2.1 may bypass attestation verification
CVE-2026-22772Medium· 5.8Fulcio is vulnerable to Server-Side Request Forgery (SSRF) via MetaIssuer Regex Bypass
CVE-2025-66564High· 7.5Sigstore Timestamp Authority allocates excessive memory during request parsing