flawopen.com/Reference/Cosign verification bypass

Cosign GHSA-fx35-mq7g-6g98: Legacy Bundle Verification Bypass

High severity · CVSS 7.4 CWE-295: Improper Certificate Validation; CWE-347: Improper Verification of Cryptographic Signature Software supply chain

ELI5 — The ticket and the ID check

Think of a venue checking both a ticket and the name on an official ID. The vulnerable legacy-bundle path could mistake a loose key for that official ID, then accept the ticket while skipping the name check. The signature could be mathematically valid, yet the required workflow identity was not established.

Boundary: Boundary: legacy JSON bundle parsing in `cosign verify-blob` and `cosign verify-blob-attestation`

Failure: Failure: an unparsable `cert` value could be treated as a raw public key, bypassing X.509 chain and certificate-policy validation

Impact: Impact: an unauthorized signer could produce a successful verification result for a supplied blob; integrity impact depends on downstream use

Remediation: Fix: upgrade to Cosign v2.6.5 or v3.1.3 or later, and pin both the expected certificate identity and OIDC issuer

The parsing fallback that crossed the trust boundary

GHSA-fx35-mq7g-6g98 affects `cosign verify-blob` and `cosign verify-blob-attestation` when keyless verification uses identity and issuer flags (or their regex variants) with a legacy JSON `--bundle`. If the bundle’s `cert` field did not parse as an X.509 certificate, affected Cosign versions fell back to loading it as a raw public key. That set an internal signature verifier, causing the downstream path to skip certificate-chain validation and `CheckCertificatePolicy`; the identity and issuer constraints were therefore not enforced. A valid signature under that embedded key could return success. A bundle key could also override an explicitly supplied `--key`. The advisory says container image verification and the standardized Sigstore protobuf bundle path are not affected. No known CVE is assigned; the upstream advisory classifies it High, CVSS 7.4, CWE-295 and CWE-347.

How the verification failure reached a release decision

A CI job receives an artifact and a legacy JSON bundle

The artifact and bundle may come from a release workflow, cache, mirror, or other pipeline input; the receiving job must treat both as untrusted until policy checks pass.

The vulnerable parser accepts a key where a certificate is expected

In affected versions, a failed X.509 parse triggered raw public-key fallback. That populated the signature verifier and skipped keyless certificate-policy enforcement.

The signature check succeeds without proving the required workflow identity

Verification may exit successfully even though the pinned certificate identity and OIDC issuer were not established. A pipeline that gates publication only on exit status can then consume an unauthorized artifact.

Pin a fixed Cosign release and signer identity

Both snippets pin the same exact GitHub Actions identity and OIDC issuer. The vulnerable command uses an affected Cosign release; with a legacy JSON bundle, its parser could still bypass those identity checks. The hardened command uses a fixed release and exact-value flags instead of regular expressions. Pin the Cosign binary or container by a reviewed version and digest in CI. These commands verify an artifact; they do not create or demonstrate a malicious bundle.

Affected-version CI policyUNPATCHED FLAW

# Risk: affected versions accept legacy JSON bundles in this path
# cosign v2.6.4 or earlier, or v3.1.2 or earlier
cosign verify-blob release.tar.gz \
  --bundle release.sigstore.json \
  --certificate-identity-regexp "^https://github\.com/acme/service/\.github/workflows/release\.yml@refs/heads/main$" \
  --certificate-oidc-issuer-regexp "^https://token\.actions\.githubusercontent\.com$"

Fixed-version CI policyHARDENED PATCH

# Require Cosign v2.6.5+ or v3.1.3+ in the pinned CI toolchain
cosign verify-blob release.tar.gz \
  --bundle release.sigstore.json \
  --certificate-identity "https://github.com/acme/service/.github/workflows/release.yml@refs/heads/main" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com"

Remediation and rollout checklist

✓Inventory CI jobs that run `cosign verify-blob` or `cosign verify-blob-attestation`; check the version actually executed, including downloaded or containerized tool copies.
✓Upgrade affected v2 installations to v2.6.5+ and v3 installations to v3.1.3+; prefer a currently supported release and pin its provenance and digest.
✓Set an exact `--certificate-identity` and `--certificate-oidc-issuer` for the expected signing workflow. Avoid `.*` policies that accept unrelated identities.
✓Migrate legacy JSON bundles to the standardized Sigstore bundle format where feasible. The advisory identifies that format’s verification path as unaffected; validate the exact tool/version behavior during rollout.
✓Keep artifact and bundle provenance coupled, fail closed on any verification error, and make publication depend on successful verification in the same controlled job.
✓Review whether artifacts verified by affected versions were subsequently published or deployed. Re-verify retained artifacts with a fixed Cosign version and the intended identity policy; investigate provenance mismatches.

Browse related vulnerability and supply-chain analysis:Security directory →