CVE-2026-54787
ADVISORY - githubSummary
sigstore-go fails to check signature timestamps against a signing key's validity period for self-managed long-lived keys without certificates.
Impact
To verify a bundle with a self-managed long-lived key, the key needs to be wrapped in an ExpiringKey type that implies expiration semantics:
signatureVerifier, _ := signature.LoadDefaultVerifier(publicKey)
expiredKey := root.NewExpiringKey(signatureVerifier, time.Unix(0, 0), time.Unix(1, 0))
Despite the API contract, the validator does not check the bundle signing time against the validity window. Attackers that obtain expired key materials may be able to sign bundles with those materials that are accepted despite a configured expiry date. This issue only impacts the long-lived signing key workflow, and not standard deployments involving a certificate authority.
Reproduction steps
Start from a sigstore-go checkout:
git clone https://github.com/sigstore/sigstore-go.git
cd sigstore-go
git checkout 8ca80c47ef03d26ebf174db7c296700b075b2c16
Apply the patch containing the test case and associated materials:
git apply sigstore-go-public-key-validity-test.patch
Run the test:
go test ./pkg/verify -run TestPublicKeyValidityCheckedAgainstSignedTimestamp
On vulnerable code, the test fails because verification succeeds even though the trusted ExpiringKey is not valid at the signed timestamp:
--- FAIL: TestPublicKeyValidityCheckedAgainstSignedTimestamp
signed_entity_test.go:602:
Error: An error is expected but got nil.
Common Weakness Enumeration (CWE)
Use of a Key Past its Expiration Date
Sign in to Docker Scout
See which of your images are affected by this CVE and how to fix them by signing into Docker Scout.
Sign in