Sigstore Timestamp Authority has Improper Certificate Validation in verifier
### 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)
02 / AFFECTED SOFTWARE
Affected packages
28 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
Sigstore Timestamp Authority is a service for issuing RFC 3161 timestamps. Versions 2.0.5 and below contain an authorization bypass vulnerability in the VerifyTimestampResponse function. VerifyTimestampResponse correctly verifies the certificate chain signature, but the TSA-specific constraint checks in VerifyLeafCert uses the first non-CA certificate from the PKCS#7 certificate bag instead of the leaf certificate from the verified chain. An attacker can exploit this by prepending a forged certificate to the certificate bag while the message is signed with an authorized key, causing the library to validate the signature against one certificate but perform authorization checks against another. This vulnerability only affects users of the timestamp-authority/v2/pkg/verification package and does not affect the timestamp-authority service itself or sigstore-go. The issue has been fixed in version 2.0.6.
Sigstore Timestamp Authority has Improper Certificate Validation in verifier in github.com/sigstore/timestamp-authority
### 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)
05 / REFERENCES
Further evidence
- https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/39xxx/CVE-2026-39984.json
- https://github.com/sigstore/timestamp-authority/releases/tag/v2.0.6
- https://github.com/sigstore/timestamp-authority/security/advisories/GHSA-xm5m-wgh2-rrg3
- https://nvd.nist.gov/vuln/detail/CVE-2026-39984
- https://github.com/sigstore/timestamp-authority