github.com/sigstore/sigstore-go

Version	Released
`v1.3.0` minor	Jul 30, 2026
`v1.2.2` patch	Jul 06, 2026
`v1.2.1` patch	Jun 09, 2026
`v1.2.0` minor 1 CVE	Jun 03, 2026
`v1.1.4` patch 2 CVEs	Dec 08, 2025
`v1.1.3` patch 2 CVEs	Sep 26, 2025
`v1.1.2` patch 2 CVEs	Sep 08, 2025
`v1.1.1` patch 2 CVEs	Aug 05, 2025
`v1.1.0` minor 2 CVEs	Jul 14, 2025
`v1.0.0` major 2 CVEs	May 12, 2025
`v0.7.3` patch 2 CVEs	May 07, 2025
`v0.7.2` patch 2 CVEs	Apr 11, 2025
`v0.7.1` patch 2 CVEs	Apr 07, 2025
`v0.7.0` minor 2 CVEs	Jan 24, 2025
`v0.6.2` patch 2 CVEs	Sep 10, 2024
`v0.6.1` patch 2 CVEs	Sep 04, 2024
`v0.6.0` minor 3 CVEs	Aug 16, 2024
`v0.5.1` patch 3 CVEs	Jul 24, 2024
`v0.5.0` minor 3 CVEs	Jul 24, 2024
`v0.4.0` minor 3 CVEs	Jun 10, 2024
`v0.3.0` minor 3 CVEs	Apr 10, 2024
`v0.2.0` minor 3 CVEs	Feb 12, 2024
`v0.1.0` initial 3 CVEs	Jan 24, 2024

v1.3.0 minor

Jul 30, 2026

v1.2.2 patch

Jul 06, 2026

v1.2.1 patch

Jun 09, 2026

v1.2.0 minor

1 CVE

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

Jun 03, 2026

v1.1.4 patch

2 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

Dec 08, 2025

v1.1.3 patch

2 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

Sep 26, 2025

v1.1.2 patch

2 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

Sep 08, 2025

v1.1.1 patch

2 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

Aug 05, 2025

v1.1.0 minor

2 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

Jul 14, 2025

v1.0.0 major

2 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

May 12, 2025

v0.7.3 patch

2 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

May 07, 2025

v0.7.2 patch

2 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

Apr 11, 2025

v0.7.1 patch

2 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

Apr 07, 2025

v0.7.0 minor

2 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

Jan 24, 2025

v0.6.2 patch

2 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

Sep 10, 2024

v0.6.1 patch

2 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

Sep 04, 2024

v0.6.0 minor

3 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2024-45395 GO-2024-3116 GHSA-cq38-jh5f-37mq Sep 06, 2024

sigstore-go has an unbounded loop over untrusted input can lead to endless data attack in github.com/sigstore/sigstore-go

Fixed in


          0.6.1

References

Updated Feb 04, 2026 · Source: OSV.dev

Aug 16, 2024

v0.5.1 patch

3 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2024-45395 GO-2024-3116 GHSA-cq38-jh5f-37mq Sep 06, 2024

sigstore-go has an unbounded loop over untrusted input can lead to endless data attack in github.com/sigstore/sigstore-go

Fixed in


          0.6.1

References

Updated Feb 04, 2026 · Source: OSV.dev

Jul 24, 2024

v0.5.0 minor

3 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2024-45395 GO-2024-3116 GHSA-cq38-jh5f-37mq Sep 06, 2024

sigstore-go has an unbounded loop over untrusted input can lead to endless data attack in github.com/sigstore/sigstore-go

Fixed in


          0.6.1

References

Updated Feb 04, 2026 · Source: OSV.dev

Jul 24, 2024

v0.4.0 minor

3 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2024-45395 GO-2024-3116 GHSA-cq38-jh5f-37mq Sep 06, 2024

sigstore-go has an unbounded loop over untrusted input can lead to endless data attack in github.com/sigstore/sigstore-go

Fixed in


          0.6.1

References

Updated Feb 04, 2026 · Source: OSV.dev

Jun 10, 2024

v0.3.0 minor

3 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2024-45395 GO-2024-3116 GHSA-cq38-jh5f-37mq Sep 06, 2024

sigstore-go has an unbounded loop over untrusted input can lead to endless data attack in github.com/sigstore/sigstore-go

Fixed in


          0.6.1

References

Updated Feb 04, 2026 · Source: OSV.dev

Apr 10, 2024

v0.2.0 minor

3 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2024-45395 GO-2024-3116 GHSA-cq38-jh5f-37mq Sep 06, 2024

sigstore-go has an unbounded loop over untrusted input can lead to endless data attack in github.com/sigstore/sigstore-go

Fixed in


          0.6.1

References

Updated Feb 04, 2026 · Source: OSV.dev

Feb 12, 2024

v0.1.0 initial

3 CVEs

CVE-2026-54787 GHSA-wqqc-jjcq-vfxm Jul 31, 2026

sigstore-go fails to check signature timestamps against a signing key's validity period

3.1 / 10

Low

Network High Low None Unchanged None Low None

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.

Fixed in


          1.2.1

References

Updated Jul 31, 2026 · Source: OSV.dev

CVE-2026-49834 GO-2026-5952 GHSA-9vcr-p3rj-q5q6 Jul 17, 2026

sigstore-go has a multi-log threshold bypass via single compromised log in github.com/sigstore/sigstore-go

Fixed in


          1.2.0

References

https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6

Updated Jul 23, 2026 · Source: OSV.dev

CVE-2024-45395 GO-2024-3116 GHSA-cq38-jh5f-37mq Sep 06, 2024

sigstore-go has an unbounded loop over untrusted input can lead to endless data attack in github.com/sigstore/sigstore-go

Fixed in


          0.6.1

References

Updated Feb 04, 2026 · Source: OSV.dev

Jan 24, 2024

Activity

Reach

Details