CVE-2026-22703: 
Datadog Agent vulnerability analysis and mitigation

CVE-2026-22703 is a Cosign bundle verification bypass vulnerability classified as "Insufficient Verification of Data Authenticity" (CWE-345). It affects Sigstore Cosign versions up to and including 2.6.1 (v2 branch) and 3.0.0–3.0.3 (v3 branch), and was published on January 9–10, 2026. The flaw allows a crafted Cosign bundle to pass verification even when the embedded Rekor transparency log entry does not reference the artifact's digest, signature, or public key. It carries a CVSS v3.1 base score of 5.5 (Medium) (Github Advisory, Cosign Advisory).

The root cause is a regression in the VerifyBundle function in pkg/cosign/verify.go. After a prior fix for GHSA-8gw7-4j42-w388, a code refactoring moved the compareSigs and comparePublicKey calls to a code path that was only reached when SIGSTORE_REKOR_PUBLIC_KEY was set — meaning that when a trusted root was provided via --trusted-root or fetched from a TUF repository, these critical comparisons were skipped entirely. As a result, sigstore-go's VerifySET function was used alone, which only verifies the Rekor entry's signed entry timestamp (SET) signature but does not cross-check the artifact digest, artifact signature, or public key against the Rekor entry body. The fix (commit 6832fba) moves the compareSigs and comparePublicKey calls before the trusted-root branch so they execute unconditionally (Cosign Advisory, Fix Commit). Exploitation requires local access and low privileges; the attacker must have already compromised a user's signing identity or key.

A malicious actor with access to a compromised signing identity or key can construct a Cosign bundle containing an arbitrary, valid Rekor entry that does not correspond to the artifact being verified, causing Cosign to accept the bundle as legitimate. This undermines the integrity guarantees of the software supply chain: fraudulent or tampered artifacts can appear as properly signed and auditable, and the legitimate signing event cannot be audited by the victim. There is no confidentiality or availability impact, but the integrity impact is rated High, as attackers could distribute malicious artifacts that bypass signature verification controls (Github Advisory, Cosign Advisory).

A proof-of-concept reproduction sequence is publicly documented in the official security advisory, demonstrating how to craft a bundle with a mismatched Rekor entry that still passes verification (Cosign Advisory). There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.006% (0th percentile), indicating very low probability of near-term exploitation (Github Advisory). No threat actor attribution has been reported.

1. Prerequisite — Compromise signing identity or key: The attacker must have already obtained a user's Sigstore/Fulcio identity (OIDC token) or their signing key, enabling them to produce valid Cosign bundles.
2. Sign two blobs to obtain two bundles: Using the compromised identity, sign two separate blobs with the old bundle format to generate two distinct Rekor-backed bundles:

   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

3. Craft a malicious bundle: Swap the Rekor entry from bundle.2 into bundle.1, creating a bundle where the Rekor entry does not correspond to the artifact's actual signature:

   jq ".rekorBundle |= $(jq .rekorBundle /tmp/bundle.2)" /tmp/bundle.1 > /tmp/bundle.3

4. Verify the crafted bundle: On a vulnerable Cosign installation (v2 ≤ 2.6.1 or v3 ≤ 3.0.3) using a trusted root (via --trusted-root or TUF), the crafted bundle passes verification:

   cosign verify-blob --bundle /tmp/bundle.3 --certificate-identity-regexp='.*' --certificate-oidc-issuer-regexp='.*' /tmp/blob

5. Distribute the fraudulent artifact: The attacker can now distribute a tampered artifact alongside the crafted bundle, which will appear as legitimately signed and verified, preventing auditing of the actual signing event (Cosign Advisory).

• File System: Presence of Cosign bundle files (.json or .bundle) where the rekorBundle field's log entry body does not reference the artifact's digest, signature, or public key — detectable by comparing the bundle's Rekor entry body against the artifact's actual SHA-256 digest and signature.
• Logs: Cosign verification logs showing successful verification of bundles using --new-bundle-format=false and --use-signing-config=false flags in combination with a trusted root, particularly on Cosign v2 ≤ 2.6.1 or v3 ≤ 3.0.3.
• Audit Trail: Missing or inconsistent Rekor transparency log entries when cross-referencing signed artifact digests against the Rekor log — the Rekor entry referenced in the bundle may correspond to a different artifact or signing event than expected (Cosign Advisory).

Upgrade to Cosign v2.6.2 (for v2 users) or v3.0.4 (for v3 users); Cosign v1 is unaffected. As a workaround without upgrading, provide trusted Rekor key material explicitly via the SIGSTORE_REKOR_PUBLIC_KEY environment variable, which forces the vulnerable code path to perform the full comparison. Cosign v3 users using default flags (--use-signing-config=true and --new-bundle-format=true) are not affected by this vulnerability. The workaround command is: SIGSTORE_REKOR_PUBLIC_KEY=<key> cosign verify-blob --use-signing-config=false --new-bundle-format=false --bundle=<bundle> <artifact> (Cosign Advisory, Github Advisory).

The vulnerability was discovered by researcher "1seal" and responsibly disclosed to the Sigstore team, who patched it the same day it was reported (January 9, 2026). The Sigstore maintainers noted this was a regression of a previously fixed issue (GHSA-8gw7-4j42-w388) caused by code refactoring, and added regression tests to prevent recurrence (Cosign Advisory, Fix PR). Downstream distributions including SUSE, Fedora, Amazon Linux, Chainguard, and Wolfi have issued advisories and updated packages.