Skip to content

Update module github.com/sigstore/sigstore-go to v1.2.1 [SECURITY] - #371

Merged
renovate-update-app[bot] merged 1 commit into
masterfrom
renovate/go-github.com-sigstore-sigstore-go-vulnerability
Oct 26, 2026
Merged

renovate-update-app[bot] merged 1 commit into
masterfrom
renovate/go-github.com-sigstore-sigstore-go-vulnerability

Conversation

@renovate-update-app

Copy link
Copy Markdown

This PR contains the following updates:

Package Change Age Confidence
github.com/sigstore/sigstore-go v1.1.4 → v1.2.1 age confidence

Warning

Some dependencies could not be looked up. Check the warning logs for more information.


sigstore-go has a multi-log threshold bypass via single compromised log

CVE-2026-49834 / GHSA-9vcr-p3rj-q5q6

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 Score: 5.9 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

References

This data is provided by the GitHub Advisory 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

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 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:

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:

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

Run the test:

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:

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

Severity

  • CVSS Score: 3.1 / 10 (Low)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).


sigstore-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 Score: 5.9 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

References

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 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:

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:

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

Run the test:

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:

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

Severity

  • CVSS Score: 3.1 / 10 (Low)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N

References

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.1

Compare Source

What's Changed

v1.2.1 resolves GHSA-wqqc-jjcq-vfxm.

  • Check signature time against public key validity window in #​642

Full Changelog: sigstore/sigstore-go@v1.2.0...v1.2.1

v1.2.0

Compare Source

What's Changed

New Contributors

Full Changelog: sigstore/sigstore-go@v1.1.4...v1.2.0


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

@renovate-update-app
renovate-update-app Bot enabled auto-merge (squash) October 26, 2026 01:40
@renovate-update-app

Copy link
Copy Markdown
Author

ℹ️ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

  • 11 additional dependencies were updated

Details:

Package Change
github.com/docker/cli v29.2.0+incompatible -> v29.4.3+incompatible
github.com/google/certificate-transparency-go v1.3.2 -> v1.3.3
github.com/google/go-containerregistry v0.20.7 -> v0.21.6
github.com/in-toto/attestation v1.1.2 -> v1.2.0
github.com/letsencrypt/boulder v0.20260223.0 -> v0.20260309.0
github.com/sergi/go-diff v1.3.2-0.20230802210424-5b0b94c5c0d3 -> v1.4.0
github.com/sigstore/rekor-tiles/v2 v2.0.1 -> v2.2.2-0.20260601073857-5d098a2b6443
github.com/sigstore/sigstore v1.10.6 -> v1.10.8
github.com/sigstore/timestamp-authority/v2 v2.0.3 -> v2.1.2
github.com/theupdateframework/go-tuf/v2 v2.3.0 -> v2.4.2-0.20260407074541-7e8f69f906ef
github.com/transparency-dev/formats v0.0.0-20251017110053-404c0d5b696c -> v0.1.1

@renovatee-approver-stackvista renovatee-approver-stackvista Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Auto-approving verified Renovate commits with native automerge enabled.

@renovate-update-app
renovate-update-app Bot merged commit df98187 into master Oct 26, 2026
10 checks passed
@renovate-update-app
renovate-update-app Bot deleted the renovate/go-github.com-sigstore-sigstore-go-vulnerability branch October 26, 2026 02:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants