On August 6, 2026, Sigstore disclosed a high-severity vulnerability that could let an unauthorized signing key pass verification in certain Cosign workflows. Tracked as GHSA-fx35-mq7g-6g98, the flaw received a CVSS 3.1 score of 7.4 out of 10.
The problem was not a broken signature algorithm. It was a verification fallback that could turn a certificate-parsing failure into successful public-key verification, bypassing the identity restrictions an operator expected Cosign to enforce.
If you rely on signed artifacts in CI/CD pipelines, this is a useful reminder: proving that a signature is mathematically valid does not necessarily prove that an authorized publisher created it.
What happened in GHSA-fx35-mq7g-6g98?
The vulnerability affected cosign verify-blob and cosign verify-blob-attestation when they processed legacy JSON bundles. Under the affected conditions, keyless verification could ignore the expected certificate identity and OpenID Connect (OIDC) issuer.
Sigstore’s official security advisory lists these affected and patched versions:
| Cosign release branch | Affected versions | First patched version |
|---|---|---|
| v2 | v2.6.4 and earlier | v2.6.5 |
| v3 | v3.1.2 and earlier | v3.1.3 |
As of October 25, 2026, the upstream release history lists v3.1.4 as the latest Cosign release. Version 3.1.3 contains the original fix; administrators should use a current, compatible patched release.
The scope is specific. The advisory excludes OCI container-image verification through cosign verify and cosign verify-attestation, as well as verification using the newer standardized Sigstore protobuf bundle format.
Why keyless signing depends on identity verification
Cosign is part of the Sigstore ecosystem, which helps developers sign software artifacts and verify their origin. In a typical keyless-signing workflow, a developer or automated build authenticates through an OIDC identity provider. Fulcio, Sigstore’s certificate authority, issues a short-lived certificate binding the signer’s public key to the authenticated identity.
The signing process produces cryptographic evidence that can include the signature, certificate and transparency-log information. A verifier then checks the signature and evaluates the certificate against the expected identity policy. Transparency evidence can also help establish when the signing event occurred.
These checks serve different purposes:
- Signature verification: Does the signature validate against the public key?
- Certificate validation: Is the certificate trusted and valid under the applicable rules?
- Identity enforcement: Does the certificate identify the developer, repository or workflow the verifier expects?
Consider a build pipeline that accepts releases only when they originate from a designated GitHub Actions workflow. A signature made with an attacker’s own key can be perfectly valid. It should still fail because the key is not associated with the required workflow identity.
That separation between cryptographic validity and authorization is central to Sigstore’s keyless-signing workflow.
The legacy-bundle parsing flaw
The root cause involved the way Cosign interpreted the cert field in its legacy LocalSignedPayload bundle format.
In the vulnerable code, Cosign first attempted to parse the field as an X.509 certificate. If that failed, it silently tried to load the same contents as a raw public key. The fallback populated an internal verifier variable named co.SigVerifier.
That decision changed the subsequent verification path. When co.SigVerifier was set, certificate-chain validation and certificate-policy enforcement through CheckCertificatePolicy were skipped. Consequently, the configured --certificate-identity and --certificate-oidc-issuer checks, including their regular-expression equivalents, could be bypassed.
The flaw had another consequence. If an operator supplied a trusted public key through --key, the key embedded in a malicious legacy bundle could overwrite that configured verifier.
How an attacker could exploit the weakness
The attack requires a vulnerable verifier to process an attacker-controlled legacy bundle. It does not require breaking RSA, ECDSA or another signature algorithm, nor does it automatically compromise every machine running Cosign.
- Prepare the verification material. An attacker creates or supplies a legacy bundle whose
certfield contains a raw public key rather than a Fulcio X.509 certificate. - Supply a signature matching that key. The signature can be cryptographically valid for an artifact controlled by the attacker.
- Reach an affected verification command. A developer or CI pipeline processes the bundle using a vulnerable Cosign release.
- Exploit the fallback. Certificate parsing fails, the raw key becomes the verifier, and the intended certificate identity and issuer restrictions are bypassed.
The advisory warns that verification could complete with exit code 0 and report Verified OK. A downstream pipeline could then consume an artifact signed by an unauthorized key, believing the required identity checks had succeeded.
The practical risk depends on how the result is used. If successful verification authorizes an artifact to enter a release pipeline or production deployment, a false success can undermine a supply-chain security control.
What the fix changes
The correction merged on August 5, 2026, one day before the public advisory. Rather than trying to make the fallback safer, the maintainers removed it.
The patch made three related changes:
- Legacy signing and attestation paths no longer place a raw public key in the certificate field.
verify-blobandverify-blob-attestationno longer reinterpret certificate contents as a public key when X.509 parsing fails.- Regression tests check that a legacy bundle containing a key in the certificate field fails with a parsing error.
The distinction is deliberate. An invalid certificate should cause verification to fail, not silently select a different trust mechanism. This follows the principle of failing closed when security-critical material does not match its expected type.
The change also avoids breaking ordinary container-image verification through an unnecessary patch to an unaffected code path.
What infrastructure teams should do now
Upgrading is the first step, but teams should also identify where legacy bundles remain in use. Cosign v3 supports both legacy and modern bundle formats for compatibility, so upgrading the binary alone does not guarantee that every workflow has stopped processing old-format material.
- Inventory Cosign versions. Check developer machines, CI runners, build containers, release workflows and verification utilities. Upgrade affected installations to a patched, compatible release.
- Review verification policies. Confirm that workflows explicitly constrain the expected certificate identity and OIDC issuer wherever keyless identity verification is required.
- Migrate legacy bundles. Adopt the standardized Sigstore protobuf bundle format. The advisory identifies
cosign bundle createas a migration option; verify converted artifacts and retained signing evidence before relying on them. - Reassess previous verification results. Identify legacy bundles processed by affected versions, particularly those connected to published releases or production deployments. Re-verify relevant artifacts using patched software and the intended trust policy.
The standardized Sigstore bundle format represents verification material explicitly, including certificate material and supporting transparency-log information. However, teams should not assume that every JSON bundle is vulnerable or that a filename alone identifies its format. The actual bundle structure and verification path determine exposure.
The broader lesson for software supply-chain security
GHSA-fx35-mq7g-6g98 was a verification-path flaw, not a cryptographic break. The fallback made a public key embedded in untrusted legacy data capable of replacing the intended certificate-based identity check.
That is a dangerous failure mode for any system that treats verification as a single yes-or-no operation. A successful signature check cannot substitute for certificate validation, issuer restrictions or an explicit signer identity policy.
Sigstore has patched the affected Cosign branches and identified the standardized bundle format as an unaffected alternative. Teams using blob signatures or attestations should upgrade, audit their legacy-bundle workflows and revisit any high-trust decisions made by vulnerable verification jobs.
The safest verification pipeline is one that rejects unexpected trust material rather than guessing how to interpret it. In software supply-chain security, a clear failure is far easier to investigate than a successful check that never enforced the policy it claimed to enforce.
