chore(deps): update module github.com/sigstore/sigstore-go to v1.2.1 [security] (alauda-v0.70.0) - #181
Open
alaudaa-renovate[bot] wants to merge 1 commit into
Conversation
alaudaa-renovate
Bot
added
the
dependencies
Author
ℹ Artifact update noticeFile name: go.modIn order to perform the update(s) described in the table above, Renovate ran the
Details:
|
alaudaa-renovate
Bot
force-pushed
the
renovate/alauda-v0.70.0-go-github.com-sigstore-sigstore-go-vulnerability
branch
from
August 8, 2026 23:35
eb5176c to
ff5181d
Compare
alaudaa-renovate
Bot
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v1.1.4->v1.2.1sigstore-go has a multi-log threshold bypass via single compromised log
CVE-2026-49834 / GHSA-9vcr-p3rj-q5q6 / GO-2026-5952
More information
Details
Impact
What kind of vulnerability is it? Who is impacted?
A verifier configured with WithTransparencyLog(N>1) or WithSignedCertificateTimestamps(N>1) expected defense-in-depth against the compromise of a single log instance. However, threshold counting counted verified witnesses per-entry or per-validation-path rather than per-log-authority.
As a result, a single compromised transparency log could forge multiple entries with different indices, and a single compromised CT log could verify multiple times (either across multiple certificate chains or via multiple embedded SCTs), fully satisfying the multi-log threshold requirements and defeating the multi-log policy.
Note that this does not affect Cosign, as Cosign sets a threshold of 1.
Patches
Has the problem been patched? What versions should users upgrade to?
Upgrade to v1.1.5.
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
There is no workaround, beyond relying on trusted logs.
Severity
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go
CVE-2026-49834 / GHSA-9vcr-p3rj-q5q6 / GO-2026-5952
More information
Details
sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go
Severity
Unknown
References
This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).
sigstore-go fails to check signature timestamps against a signing key's validity period
CVE-2026-54787 / GHSA-wqqc-jjcq-vfxm / GO-2026-6162
More information
Details
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
ExpiringKeytype that implies expiration semantics: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 8ca80c47ef03d26ebf174db7c296700b075b2c16Apply the patch containing the test case and associated materials:
Run the test:
go test ./pkg/verify -run TestPublicKeyValidityCheckedAgainstSignedTimestampOn vulnerable code, the test fails because verification succeeds even though the trusted
ExpiringKeyis not valid at the signed timestamp:Severity
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:NReferences
This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).
sigstore-go fails to check signature timestamps against a signing key's validity period in github.com/sigstore/sigstore-go
CVE-2026-54787 / GHSA-wqqc-jjcq-vfxm / GO-2026-6162
More information
Details
sigstore-go fails to check signature timestamps against a signing key's validity period in github.com/sigstore/sigstore-go
Severity
Unknown
References
This data is provided by OSV and the Go Vulnerability Database (CC-BY 4.0).
Release Notes
sigstore/sigstore-go (github.com/sigstore/sigstore-go)
v1.2.1Compare Source
What's Changed
v1.2.1 resolves GHSA-wqqc-jjcq-vfxm.
Full Changelog: sigstore/sigstore-go@v1.2.0...v1.2.1
v1.2.0Compare Source
What's Changed
New Contributors
Full Changelog: sigstore/sigstore-go@v1.1.4...v1.2.0
Configuration
📅 Schedule: Branch creation - "" in timezone Asia/Shanghai, Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Renovate Bot.