CVE-2026-39395
Logic Flaw in Cosign Verification Causes False Attestation Success
Publication date: 2026-04-07
Last updated on: 2026-04-15
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| sigstore | cosign | to 2.6.3 (exc) |
| sigstore | cosign | From 3.0.0 (inc) to 3.0.6 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-754 | The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-39395 is a vulnerability in the Cosign tool, specifically in the verify-blob-attestation function. This function may incorrectly report a "Verified OK" status for attestations that have malformed payloads or mismatched predicate types.
For old-format bundles and detached signatures, the problem is due to a logic flaw in error handling during predicate type validation. For new-format bundles, the predicate type validation is completely bypassed.
This means that when verify-blob-attestation is used without the --check-claims=true flag, attestations with valid signatures but malformed or unparsable payloads can be mistakenly accepted as valid. Also, relying on the --type <predicate type> option to reject attestations with mismatched types can lead to trusting unexpected attestation types.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by examining the use of the cosign tool's verify-blob-attestation function. Specifically, if the function is used without the --check-claims=true flag, it may incorrectly report a "Verified OK" status for attestations with malformed payloads or mismatched predicate types.
To detect potential exploitation or presence of the vulnerability, you can check if cosign verify-blob-attestation commands are run without the --check-claims=true flag or if the --type <predicate type> option is used to filter attestations, which may be insufficient.
A suggested command to verify attestations safely is:
- cosign verify-blob-attestation --check-claims=true --type <expected-predicate-type> <attestation-file>
Monitoring usage of cosign verify-blob-attestation commands without the --check-claims flag or with mismatched predicate types can help detect vulnerable verification attempts.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability immediately, upgrade cosign to version 3.0.6 or later, or 2.6.3 or later, where the issue is fixed.
If upgrading is not immediately possible, always use the --check-claims=true flag when running the verify-blob-attestation command to ensure proper validation of attestations.
Avoid relying solely on the --type <predicate type> option to reject attestations, as this may not be sufficient to prevent acceptance of malformed or mismatched attestations.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability in cosign's verify-blob-attestation function may cause malformed or mismatched attestations to be incorrectly accepted as valid. While the CVE description and resources do not explicitly mention compliance with standards such as GDPR or HIPAA, the issue could potentially impact the integrity of attestation verification processes.
Since the vulnerability allows low integrity impact by trusting invalid attestations, it may undermine trust in code signing and verification mechanisms that are often part of security controls required by such regulations. However, no direct statements about compliance impact are provided.
How can this vulnerability impact me? :
This vulnerability can lead to accepting invalid or malformed attestations as valid, which undermines the trustworthiness of the code signing and verification process.
As a result, an attacker could potentially trick systems or users into trusting containers or binaries that have incorrect or unexpected attestation data, possibly leading to the execution of unverified or malicious code.
The impact is rated as moderate with a CVSS score of 4.3, indicating a low integrity impact but no confidentiality or availability impact.