sigstore-go CVE-2026-54787

Exploitation requires all of the following: (1) the target application uses sigstore-go's self-managed long-lived key workflow - the vulnerability does not affect any deployment using a certificate authority such as Fulcio; (2) the verifier is explicitly configured with a root.NewExpiringKey() wrapper encoding a validity start and end time for a public key; (3) the attacker possesses signing key material that is expired per the configured validity window but was at some point a genuine signing key for the system; (4) the attacker can cause a crafted bundle to be submitted for verification. Exploitation is limited by the AC:H prerequisite (acquiring expired key material is non-trivial), by the PR:L requirement (some authenticated access is needed to interact with the verification pipeline), and by the narrow deployment scope (self-managed long-lived key configuration is non-default and niche).

The CVSS 3.1 vector AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N yields a score of 3.1 (LOW), which accurately reflects the narrow impact here. Attack Complexity is High because an attacker must first obtain expired key material - a significant non-trivial prerequisite that limits opportunistic exploitation. PR:L indicates some level of authenticated access is required to submit bundles for verification. Impact is confined to Integrity:Low with no confidentiality or availability consequences. The vulnerability is not listed in the CISA KEV catalog, no standalone POC exploit has been released (only a test-case patch for reproduction), and no EPSS score was provided in the source data. Real-world risk is meaningful specifically for organizations that have adopted the long-lived key workflow in sigstore-go and depend on key expiry as a security boundary - for those teams, an attacker who has acquired a previously valid, now-expired signing key can present artifacts as validly signed indefinitely. For the broader ecosystem, the risk is low due to the non-default configuration requirement and the fact that the dominant Fulcio-based workflow is entirely unaffected.

An attacker who previously held or has since obtained a signing key that was once valid under an ExpiringKey configuration (e.g., recovered from a past key compromise or insider leak) generates a Sigstore bundle signed with that expired key material. The attacker submits the bundle to a supply chain verification pipeline powered by sigstore-go, which calls Verifier.Verify(). On vulnerable versions, the verifier confirms the signature cryptographically but never checks whether the signing timestamp falls within the ExpiringKey's validity window, so the bundle is accepted as trustworthy despite the key's configured expiration having passed.