Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
5.5
Sigstore Timestamp Authority Verifier Allows Unauthorized Access
GHSA-xm5m-wgh2-rrg3
CVE-2026-39984
Summary
A bug in the Sigstore Timestamp Authority Verifier can allow attackers to pretend to be someone else, potentially gaining unauthorized access. This issue only affects users of the specific 'timestamp-authority/v2/pkg/verification' package, and not the Sigstore Timestamp Authority service or the sigstore-go library. To fix this, users of VerifyTimestampResponse can specify the correct certificate to use, which will prevent the issue.
What to do
- Update github.com sigstore to version 2.0.6.
Affected software
| Ecosystem | Vendor | Product | Affected versions |
|---|---|---|---|
| go | github.com | sigstore |
<= 2.0.5 Fix: upgrade to 2.0.6
|
Original title
Sigstore Timestamp Authority has Improper Certificate Validation in verifier
Original description
### Authorization bypass via certificate bag manipulation in sigstore/timestamp-authority verifier
An authorization bypass vulnerability exists in sigstore/timestamp-authority verifier (timestamp-authority/v2/pkg/verification): `VerifyTimestampResponse` function correctly verifies the certificate chain but when the TSA specific constraints are verified in `VerifyLeafCert`, the first non-CA certificate from the PKCS#7 certificate bag is used instead of the leaf certificate from the certificate chain. An attacker can exploit this by prepending a forged certificate to the certificate bag while the message is signed with an authorized key. The library validates the signature using the one certificate but performs authorization checks on the another, allowing an attacker to bypass some authorization controls.
This vulnerability does **not** apply to timestamp-authority service, only to users of `timestamp-authority/v2/pkg/verification` package.
This vulnerability does **not** apply to sigstore-go even though it is a user of `timestamp-authority/v2/pkg/verification`: Providing `TSACertificate` option to `VerifyTimestampResponse` fully mitigates the issue.
### Patches
The issue will be fixed in timestamp-authority 2.0.6
### Workarounds
Users of `VerifyTimestampResponse` can use the `TSACertificate` option to specify the exact certificate they expect to be used: this fully mitigates the issue.
### References
This issue was found after reading CVE-2026-33753 / GHSA-3xxc-pwj6-jgrj (originally reported by @Jaynornj and @Pr00fOf3xpl0it)
An authorization bypass vulnerability exists in sigstore/timestamp-authority verifier (timestamp-authority/v2/pkg/verification): `VerifyTimestampResponse` function correctly verifies the certificate chain but when the TSA specific constraints are verified in `VerifyLeafCert`, the first non-CA certificate from the PKCS#7 certificate bag is used instead of the leaf certificate from the certificate chain. An attacker can exploit this by prepending a forged certificate to the certificate bag while the message is signed with an authorized key. The library validates the signature using the one certificate but performs authorization checks on the another, allowing an attacker to bypass some authorization controls.
This vulnerability does **not** apply to timestamp-authority service, only to users of `timestamp-authority/v2/pkg/verification` package.
This vulnerability does **not** apply to sigstore-go even though it is a user of `timestamp-authority/v2/pkg/verification`: Providing `TSACertificate` option to `VerifyTimestampResponse` fully mitigates the issue.
### Patches
The issue will be fixed in timestamp-authority 2.0.6
### Workarounds
Users of `VerifyTimestampResponse` can use the `TSACertificate` option to specify the exact certificate they expect to be used: this fully mitigates the issue.
### References
This issue was found after reading CVE-2026-33753 / GHSA-3xxc-pwj6-jgrj (originally reported by @Jaynornj and @Pr00fOf3xpl0it)
ghsa CVSS3.1
5.5
Vulnerability type
CWE-295
Improper Certificate Validation
Published: 14 Apr 2026 · Updated: 15 Apr 2026 · First seen: 14 Apr 2026