CVE-2026-54787: 
Docker Compose vulnerability analysis and mitigation

CVE-2026-54787 is a cryptographic signature validation flaw in sigstore-go, a Go library for Sigstore signing and verification. The library fails to check a bundle's signing timestamp against the validity window of an ExpiringKey wrapping a self-managed long-lived signing key (used without a certificate authority). This allows an attacker who has obtained expired key material to create bundles that pass verification despite the key being expired. All versions up to and including v1.2.0 are affected; the issue was fixed in v1.2.1. It carries a CVSS v3.1 base score of 3.1 (Low) (Github Advisory).

The root cause is classified as CWE-324 (Use of a Key Past its Expiration Date) and CWE-347 (Improper Verification of Cryptographic Signature). When a signing key is wrapped in the ExpiringKey type via root.NewExpiringKey() to enforce a validity window, the Verifier.Verify() function in pkg/verify/signed_entity.go did not compare the bundle's verified signing timestamp against that window for public-key-signed (non-certificate) bundles. The fix, introduced in PR #642 and commit 4594ab4, adds an explicit check: for bundles signed with a long-lived public key, each verified timestamp is now validated against verificationContent.ValidAtTime(), returning an error ("signature time outside of public key validity window") if the timestamp falls outside the key's validity period. This vulnerability does not affect standard Sigstore deployments using a certificate authority (Github Advisory, Fix PR).

Successful exploitation allows an attacker holding expired signing key material to produce Sigstore bundles that are accepted as valid by applications using the vulnerable library, undermining the integrity guarantees of the software supply chain signing workflow. The impact is limited to integrity (no confidentiality or availability impact), and only affects deployments using the self-managed long-lived key workflow with ExpiringKey; standard certificate-authority-based Sigstore deployments are unaffected. In a supply chain context, this could enable an attacker to sign malicious artifacts with a compromised or expired key and have them accepted as legitimate (Github Advisory).

No public exploit code or in-the-wild exploitation has been reported. The EPSS score is approximately 0.09% (1st percentile), indicating a very low probability of near-term exploitation. The NVD SSVC assessment classifies exploitation as "none" and the attack as non-automatable. The vulnerability requires the attacker to already possess expired key material and have low-level privileges, making opportunistic exploitation unlikely. It is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Github Advisory).

1. Obtain expired key material: The attacker must first acquire a private signing key that was previously used with a sigstore-go ExpiringKey configuration but has since passed its configured expiry date (e.g., a key whose validity window ended at time.Unix(1, 0)).
2. Craft a malicious bundle: Using the expired private key, sign a target artifact (e.g., a software package or container image) to produce a Sigstore bundle in the application/vnd.dev.sigstore.bundle.v0.3+json format, including a valid RFC 3161 timestamp from a trusted TSA.
3. Submit bundle for verification: Present the crafted bundle to a system using a vulnerable version of sigstore-go (≤ v1.2.0) configured with the corresponding ExpiringKey as the trusted verifier.
4. Bypass expiry check: Because the vulnerable code does not validate the bundle's signing timestamp against the ExpiringKey validity window, verification succeeds and the malicious bundle is accepted as legitimate (Github Advisory, Fix PR).

Upgrade sigstore-go to version v1.2.1 or later, which introduces the timestamp-vs-validity-window check for public-key-signed bundles. No configuration-based workaround is available for the vulnerable code path; upgrading is the only remediation. Organizations using the self-managed long-lived key workflow should audit any bundles verified with expired keys prior to patching. Standard certificate-authority-based Sigstore deployments require no action (Github Advisory, v1.2.1 Release).