Skip to content

chore(deps): update module github.com/sigstore/sigstore-go to v1.2.1 [security] (release-2.4) - #237

Open
crossplane-renovate[bot] wants to merge 1 commit into
release-2.4from
renovate/release-2.4-go-github.com-sigstore-sigstore-go-vulnerability
Open

chore(deps): update module github.com/sigstore/sigstore-go to v1.2.1 [security] (release-2.4)#237
crossplane-renovate[bot] wants to merge 1 commit into
release-2.4from
renovate/release-2.4-go-github.com-sigstore-sigstore-go-vulnerability

Conversation

@crossplane-renovate

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

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

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 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 OSV and the GitHub Advisory 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


Configuration

📅 Schedule: (UTC)

  • Branch creation
    • At any time (no schedule defined)
  • 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.


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

This PR has been generated by Mend Renovate.

@crossplane-renovate
crossplane-renovate Bot requested review from a team, jcogilvie and tampakrap as code owners August 1, 2026 08:47
@crossplane-renovate
crossplane-renovate Bot requested review from haarchri and removed request for a team August 1, 2026 08:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

0 participants