CVE-2026-54787

What it actually does

The flaw is a cryptographic verification weakness in sigstore-go before version 1.2.1. When verifying a Sigstore bundle that uses an ExpiringKey around a self-managed long-lived signing key without a certificate, the library fails to confirm that the bundle's signing timestamp falls within the ExpiringKey validity window. As a result, an attacker who still possesses expired signing key material may be able to produce a bundle that is accepted as valid even though the key should no longer be trusted. The practical impact is limited integrity bypass for systems that rely on this verification path; confidentiality and availability are not directly affected.

Why it matters to the business

Organizations using affected Sigstore verification workflows may incorrectly trust artifacts, attestations, or signatures produced with expired key material. This can weaken software supply chain controls and allow unauthorized or outdated signing credentials to continue authorizing releases, images, packages, or metadata. The reported CVSS score is low and EPSS is very low, there is no known CISA KEV listing, and no mature public exploitation is reported, but the issue is still important where Sigstore verification is used as a security gate for production software, container images, CI/CD pipelines, or compliance evidence.

How an attack unfolds

An attacker must first obtain or retain access to expired signing key material associated with a self-managed long-lived signing key workflow using ExpiringKey and no certificate. The attacker then creates or modifies an artifact and signs a Sigstore bundle using the expired key material. Because affected versions of sigstore-go do not validate the signing timestamp against the ExpiringKey validity window, a verifier using the vulnerable library can incorrectly accept the bundle as valid. The attacker’s success depends on the target using the affected sigstore-go verification path and trusting the relevant key identity or policy. There is currently no indication of broad exploitation, ransomware use, or named threat actor activity for this issue.

How to fix it

Upgrade sigstore-go to version 1.2.1 or later wherever it is directly used. For affected Red Hat-packaged products, apply RHSA-2026:44162 or later updates: spire1-14-main fixed in 1.14.7-0.3.hum1, spire1-15-main fixed in 1.15.2-0.3.hum1, and trivy-main fixed in 0.72.0-0.1.3.hum1. Rebuild internally maintained Go binaries that vendor sigstore-go, because updating a module reference alone does not protect already-built executables. As a compensating control until patching is complete, avoid accepting bundles signed with expired self-managed keys, rotate exposed or expired signing keys, enforce independent key expiration checks in policy, and prefer certificate-backed verification flows where possible.

How to confirm the fix worked

Confirm that all directly developed Go applications and downstream tools use sigstore-go version 1.2.1 or later. Review go.mod, go.sum, SBOMs, container image metadata, and built binary dependency reports for github.com/sigstore/sigstore-go versions earlier than 1.2.1. For Red Hat packages, verify installed package versions are at or above spire1-14-main 1.14.7-0.3.hum1, spire1-15-main 1.15.2-0.3.hum1, and trivy-main 0.72.0-0.1.3.hum1 as applicable. Functional validation should include a negative test: create or obtain a test bundle signed with an ExpiringKey outside its validity window and confirm the verifier rejects it after the fix. Also confirm CI/CD, admission controllers, artifact registries, and provenance enforcement points are running rebuilt or updated binaries, not only updated source dependencies.

Typical attack path

1. Identify an organization or pipeline that verifies Sigstore bundles using a vulnerable version of sigstore-go or downstream products that embed it.
2. Obtain expired signing key material for a trusted self-managed long-lived key without a certificate.
3. Create or tamper with an artifact, attestation, or metadata object that will be checked by the vulnerable verifier.
4. Generate a Sigstore bundle signed with the expired key material.
5. Submit the signed bundle to a build, deployment, admission control, scanning, or verification workflow that relies on affected sigstore-go behavior.
6. Have the vulnerable verifier incorrectly accept the bundle, allowing the artifact or metadata to pass an integrity or provenance check.

How to detect it

Investigate whether vulnerable verifiers accepted Sigstore bundles signed outside the allowed ExpiringKey validity window. Relevant sources include CI/CD job logs, artifact promotion logs, container registry admission or policy-controller logs, software provenance verification logs, release automation logs, Trivy scan logs if signature verification is enabled, SPIRE-related logs where Sigstore verification is integrated, and application logs from services embedding sigstore-go. Look for successful verification events involving self-managed long-lived keys, no certificate-backed identity, expired key IDs, or timestamps after the key expiration time. Compare each accepted bundle's signing timestamp against the corresponding ExpiringKey notBefore/notAfter or valid-from/valid-until values. Pay particular attention to artifacts accepted after key rotation, after key expiration, or from unusual build principals. Because no public exploit pattern or malware-specific indicator is known, detection should focus on behavioral evidence: accepted verification results where the signature time is outside the configured key validity window, unexpected reuse of retired keys, or artifacts promoted with keys that should have been inactive.

• github.com/sigstore/sigstore-go v1.2.0
• github.com/sigstore/sigstore-go v1.1.
• github.com/sigstore/sigstore-go v1.0.
• sigstore-go
• ExpiringKey
• verification succeeded
• signature verified
• bundle verified
• certificate not found
• no certificate
• self-managed key
• expired key
• key expired
• validity window
• notAfter
• validUntil
• spire1-14-main
• spire1-15-main
• trivy-main

What your security team should do

• Prioritize patching systems that use Sigstore verification to make release, deployment, container admission, package promotion, or provenance trust decisions.
• Inventory Go applications, security tools, scanners, CI/CD components, and container images that embed sigstore-go, including vendored and statically linked binaries.
• Apply RHSA-2026:44162 updates for affected Red Hat spire and trivy packages, or upgrade sigstore-go to 1.2.1 or later in internally maintained software.
• Search recent signing and verification records for accepted bundles whose signing timestamp is outside the configured ExpiringKey validity window.
• Rotate any signing keys that are expired, suspected exposed, shared broadly, or not governed by strong custody controls.
• Add policy checks that explicitly reject signatures made outside the key validity period, independent of library behavior.
• Re-run verification for high-risk recently accepted artifacts, releases, attestations, and container images that relied on vulnerable verification logic.
• Monitor vendor advisories and dependency scans for transitive sigstore-go usage in supply chain security tooling.