What is the CVSS score of CVE-2026-54787?

CVE-2026-54787 has a CVSS 3.1 base score of 3.1 (Low). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N. EPSS exploitation probability: 0.1%.

Is there a patch available for CVE-2026-54787?

Yes, a patch is available for CVE-2026-54787. Update the affected software to the latest version immediately.

sigstore-go CVE-2026-54787

EUVD-2026-51665 LOW

Use of a Key Past its Expiration Date (CWE-324)

2026-07-31 https://github.com/sigstore/sigstore-go

GHSA-wqqc-jjcq-vfxm

Information Disclosure

3.1

CVSS 3.1 · Vendor: https://github.com/sigstore/sigstore-go

Severity by source

Vendor (https://github.com/sigstore/sigstore-go) PRIMARY

3.1 LOW

AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N

vuln.today AI

3.1 LOW

Attacker must first acquire expired key material (AC:H); some authenticated access needed to submit bundles (PR:L); impact is solely integrity-limited bypass of key expiry (I:L), no confidentiality or availability consequences.

3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N

4.0 AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/sigstore/sigstore-go).

CVSS VectorVendor: https://github.com/sigstore/sigstore-go

Attack Vector

Network

Attack Complexity

High

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

Low

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

Jul 31, 2026 - 22:21 vuln.today

Analysis Generated

Jul 31, 2026 - 22:21 vuln.today

DescriptionCVE.org

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:

bash

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:

bash

git apply sigstore-go-public-key-validity-test.patch

Run the test:

bash

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:

text

--- FAIL: TestPublicKeyValidityCheckedAgainstSignedTimestamp
    signed_entity_test.go:602:
        	Error:      	An error is expected but got nil.

[patch]: https://github.com/user-attachments/files/28614520/sigstore-go-public-key-validity-test.patch

AnalysisAI

sigstore-go versions up to and including 1.2.0 accept Sigstore bundles signed with expired long-lived public keys because the verifier omits the timestamp-validity check when using ExpiringKey-wrapped verifiers. An attacker who obtains expired signing key material can produce bundles that pass verification despite the key's configured expiry window, undermining supply chain integrity guarantees enforced by key rotation policies. This affects only the self-managed long-lived key workflow - standard Sigstore deployments using Fulcio certificate authorities are explicitly unaffected. No public exploit identified at time of analysis.

Technical ContextAI

sigstore-go is the Go reference implementation of the Sigstore artifact signing and verification framework, identified by package path pkg:go/github.com/sigstore/sigstore-go. The vulnerability (CWE-324: Use of a Key Past its Expiration Date) resides in pkg/verify/signed_entity.go within the Verifier.Verify() method. The Sigstore protocol supports two signing workflows: (1) short-lived certificates issued by a certificate authority such as Fulcio, where expiry is enforced through the certificate chain, and (2) self-managed long-lived keys, where the operator wraps a public key verifier in a root.ExpiringKey type that explicitly encodes a validity start and end time. The bug is that the code path handling public-key-based bundles omitted a call to ValidAtTime() against the verified timestamps, meaning the validator accepted bundles regardless of whether the signing event fell within the key's configured validity window. The fix in PR #642 (commit 4594ab4c779d08be1f4419803a8249188f35ed5f) adds an explicit loop over verifiedTimestamps that returns an error when the signing time falls outside the ExpiringKey window, matching the API contract that was implied but not enforced.

RemediationAI

Upgrade sigstore-go to v1.2.1 (https://github.com/sigstore/sigstore-go/releases/tag/v1.2.1), which enforces the signing-timestamp-to-key-validity-window check introduced in PR #642 (commit 4594ab4c779d08be1f4419803a8249188f35ed5f). If an immediate upgrade is not feasible, organizations using the long-lived key workflow should audit all ExpiringKey verifier configurations and treat any bundle verification result as potentially unreliable with respect to key expiry enforcement. Transitioning to the Fulcio certificate authority workflow eliminates the exposure entirely, as that path enforces validity through the certificate chain - though this is a significant architectural change with operational implications for key management. There is no in-place workaround that preserves the ExpiringKey API behavior without upgrading; the missing check cannot be compensated at the caller level because the validation logic is internal to the library's verification method.