5.5

CVSS Score

3.1

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-22703

CVE-2026-22703: Cosign verification accepts any valid Rekor entry under certain conditions

Cosign provides code signing and transparency for containers and binaries. Prior to versions 2.6.2 and 3.0.4, 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 issue has been patched in versions 2.6.2 and 3.0.4.

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-22703

CVE-2026-22703:

5.5

CVSS Score

3.1

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
github.com/sigstore/cosign/v3	go	<= 3.0.3	3.0.4
github.com/sigstore/cosign/v2	go	<= 2.6.1	2.6.2

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The analysis of the provided patch for the vulnerability in sigstore/cosign clearly points to a single vulnerable function: github.com/sigstore/cosign/pkg/cosign.VerifyBundle. The vulnerability description explains that under specific conditions (using a trusted root), cosign would accept any valid Rekor entry, even if it didn't match the artifact being verified. The commit 6832fba4928c1ad69400235bbc41212de5006176 directly addresses this. The patch modifies the VerifyBundle function in pkg/cosign/verify.go. Before the patch, if a trusted root was used (co.TrustedMaterial != nil), the function would call tlog.VerifySET and return, skipping the essential checks that compare the signature, public key, and artifact hash between the bundle and the provided signature. The fix involves moving these verification steps (compareSigs, comparePublicKey, and the payload hash comparison) to be executed unconditionally at the beginning of the function. This ensures that regardless of whether a trusted root is used, the Rekor bundle is always cryptographically linked to the artifact and signature being verified. The commit message further confirms this by stating, "Ensure the bundle signature and key are compared to the rekor entry every time, not just when trusted root is used." Therefore, VerifyBundle is the precise location of the vulnerability.

Vulnerable functions

github.com/sigstore/cosign/pkg/cosign.VerifyBundle

pkg/cosign/verify.go

The vulnerability lies in the `VerifyBundle` function. When a trusted root is provided (`co.TrustedMaterial != nil`), the function would previously perform a verification of the Signed Entry Timestamp (SET) using `tlog.VerifySET` and then immediately return `true`. This logic path skipped crucial validation steps that were only performed in the `else` block. Specifically, it failed to compare the signature, public key, and artifact digest from the Rekor bundle against the signature and artifact being verified. An attacker could therefore craft a valid Cosign bundle with a mismatched but valid Rekor entry, bypassing the intended verification. The patch fixes this by moving the comparison logic to execute before the `if co.TrustedMaterial != nil` check, ensuring these validations are always performed.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.