CVE-2026-54787: Insufficient Timestamp Validation in sigstore-go Key Verification Path

The Go implementation of the Sigstore signature verification engine, sigstore-go, provides high-performance cryptographic validation for software supply chain artifacts. Software deployment pipelines rely heavily on this library to verify signatures on container images, binary releases, and software bill-of-materials (SBOM) metadata. Within this ecosystem, verification is partitioned into two major execution paths: certificate-signed bundles, which utilize short-lived ephemeral certificates from Fulcio, and key-signed bundles, which rely on long-lived, self-managed public keys. To manage the lifecycle and eventual retirement of long-lived public keys, Sigstore defines an ExpiringKey structure that assigns precise temporal validity boundaries to each cryptographic key.

Prior to the release of version 1.2.1, a significant vulnerability existed in the key-signed bundle verification path. The library failed to reconcile verified RFC 3161 cryptographic timestamps against the defined validity boundaries of the public key wrapper. Although the system verified that the cryptographic signature itself was valid and that the timestamp was authentic, it omitted the logical assertion confirming that the signing event occurred during the key's active operational window. This omission established a critical security bypass, enabling expired, revoked, or historically retired key material to be used to sign novel software artifacts successfully.

From an adversarial perspective, this design flaw alters the threat model of long-lived cryptographic keys. If a private key is rotated due to policy requirements or compromised after its operational window closes, an attacker can continue to use that key to sign malicious binaries. Because vulnerable versions of sigstore-go skip the temporal check, the resulting signed bundles will be trusted without warning. This vulnerability directly maps to CWE-324: Use of a Key Past its Expiration Date, presenting a low-severity but highly targeted security risk to automated verification pipelines.

To understand the technical root cause of CVE-2026-54787, one must examine the state management of long-lived public keys within Sigstore's client Root of Trust. When verifying a signature without an accompanying Fulcio certificate, the verifier relies on configuration metadata loaded into the TrustedMaterialCollection. This collection contains instances of ExpiringKey, which wrap the public keys and specify two essential time coordinates: ValidAt (the inception of the key's authorization) and ValidUntil (the expiration of the key's authorization). These fields are designed to restrict the temporal window during which signatures created by the corresponding private key are deemed authoritative.

During verification, the library executes a multi-stage validation loop located within pkg/verify/signed_entity.go. When processing a key-signed bundle, the code resolves the raw signature blocks and validates their mathematical correctness against the public key. It then extracts the attached RFC 3161 timestamps, ensuring that they were issued by a trusted Timestamp Authority. However, prior to version 1.2.1, the engine lacked any logical link between these two verification outcomes. The cryptographic authenticity of the timestamp was checked, and the mathematical validity of the signature was checked, but the temporal boundaries of the public key itself were completely ignored.

Because of this logical separation, the engine would accept a bundle where the signing event took place years after the public key's ValidUntil threshold had passed. The system lacked an assertion block within the non-certificate verification branch to compare the validated timestamp against the key's active window. This technical oversight effectively decoupled key expiration from signature validation, making it impossible for system administrators to securely decommission long-lived keys without completely removing them from the root-of-trust configuration.

The remediation implemented in Pull Request #642 addresses the logic gap by introducing an explicit boundary check within the verification pipeline. In the affected versions of pkg/verify/signed_entity.go, the verification function transitioned straight from handling certificate-specific timestamp assertions to concluding verification, without applying equivalent temporal constraints to raw public keys. The fix introduces a conditional block targeting verificationContent.PublicKey() and ensures that the key's validity window is checked for every verified timestamp.

Below is the patch implemented in commit 4594ab4c779d08be1f4419803a8249188f35ed5f to remediate the vulnerability:

// pkg/verify/signed_entity.go
@@ -681,6 +681,13 @@ func (v *Verifier) Verify(entity SignedEntity, pb PolicyBuilder) (*VerificationR
 				return nil, fmt.Errorf("failed to verify signed certificate timestamp: %w", err)
 			}
 		}
+	} else if verificationContent.PublicKey() != nil {
+		// If the bundle was signed by a long-lived key, we need to check the signature time against the key's validity window.
+		for _, verifiedTs := range verifiedTimestamps {
+			if !verificationContent.ValidAtTime(verifiedTs.Timestamp, v.trustedMaterial) {
+				return nil, errors.New("signature time outside of public key validity window")
+			}
+		}
 	}

This implementation closes the vulnerability loop by forcing the engine to loop through the verifiedTimestamps slice and verify each timestamp against the ValidAtTime function. The ValidAtTime method queries the root-of-trust configuration, retrieving the boundary metadata associated with the public key's ExpiringKey wrapper. If any verified timestamp falls outside the authorized window, the system halts execution and returns a descriptive error, immediately invalidating the bundle.

An attacker seeking to exploit this vulnerability must first obtain access to a retired or compromised long-lived private key. This key must have been previously trusted, with its lifetime configured in the verifier's root-of-trust metadata as an ExpiringKey block. Since the attacker's objective is to sign novel, unauthorized artifacts using an expired cryptographic identity, the target must have a configured sigstore-go verifier with older package dependencies.

Once the retired private key is in the attacker's possession, they sign the unauthorized payload (e.g., a modified software package or container image) and compile it into a Sigstore bundle structure. Next, the attacker acquires an RFC 3161 timestamp signature from a trusted Timestamp Authority (TSA). Because the target verification environment uses a vulnerable version of sigstore-go, the verifier checks the validity of the timestamp signature itself and verifies the mathematical correctness of the signature block, but skips checking if the timestamp falls outside the key's active window.

When the bundle is distributed to systems utilizing vulnerable versions of sigstore-go, the verification function completes successfully without throwing an error (err == nil). The runtime environment executes the malicious package, trusting it as if it were signed by an active, valid key. This process successfully circumvents the security boundaries established by key rotation policies.

By bypassing key-lifetime validations, CVE-2026-54787 invalidates the operational benefits of key rotation. When cryptographic keys are retired or rotated out due to routine schedules or suspected compromise, they are meant to be treated as untrusted for any future signature actions. This bug allows an attacker to construct valid bundles utilizing compromised key material indefinitely, provided they can secure a valid timestamp from a trusted TSA. The integrity of the software distribution pipeline is compromised because the system fails to differentiate between historical signatures generated when the key was active and newly forged signatures.

This vulnerability is characterized by a low CVSS base score of 3.1. The low score reflects the highly specific conditions required to exploit the flaw. An attacker must possess an authentic long-lived signing key that was historically trusted, and the target configuration must map this key inside an ExpiringKey block. Because the attack vector relies on specialized target configurations and the possession of rotated/compromised signing keys, it is difficult to execute as a general automated exploit.

Despite the low score, the impact within targeted environments can be severe. Organizations that use self-managed keys for critical internal software distribution will find their key revocation and rotation mechanisms ineffective against an insider threat or an adversary that has harvested retired keys from backup storage or developer workstations.

The definitive remediation for CVE-2026-54787 is upgrading the sigstore-go dependency to version 1.2.1 or later. This can be accomplished within your Go workspace by running go get github.com/sigstore/sigstore-go@v1.2.1 followed by go mod tidy to update the module dependencies.

Analysis of the fix commit reveals an operational nuance that could lead to a persistent security bypass. The new validation code relies entirely on iterating over the verifiedTimestamps slice. If a verifier is configured with the verify.WithNoObserverTimestamps() option, this slice will be empty at runtime. Under this specific configuration, the validation loop is skipped entirely, and the expired key will continue to be accepted as valid. This behavior is demonstrated in the official test suites, where bundles verified without observer timestamps bypass the temporal boundary check and execute without returning an error.

To prevent this bypass, security administrators must audit their verifier configuration. Ensure that policies requiring self-managed key verification do not disable observer timestamps. Developers should enforce a policy requiring at least one verified signed timestamp (using verify.WithSignedTimestamps(1) or similar parameters) to guarantee that the temporal checks added in version 1.2.1 are executed.