<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://vulnerability.circl.lu</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Tue, 29 Sep 2026 16:27:06 +0000</lastBuildDate>
    <item>
      <title>GHSA-xm5m-wgh2-rrg3 — Sigstore Timestamp Authority has Improper Certificate Validation in verifier</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-xm5m-wgh2-rrg3</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/sigstore/timestamp-authority/v2&lt;/p&gt;
&lt;p&gt;### Authorization bypass via certificate bag manipulation in sigstore/timestamp-authority verifier&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;This vulnerability does **not** apply to timestamp-authority service, only to users of `timestamp-authority/v2/pkg/verification` package.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;The issue will be fixed in timestamp-authority 2.0.6&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Users of `VerifyTimestampResponse` can use the `TSACertificate` option to specify the exact certificate they expect to be used: this fully mitigates the issue.&lt;/p&gt;
&lt;p&gt;### References&lt;/p&gt;
&lt;p&gt;This issue was found after reading CVE-2026-33753 / GHSA-3xxc-p…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/sigstore/timestamp-authority/v2&lt;/p&gt;
&lt;p&gt;### Authorization bypass via certificate bag manipulation in sigstore/timestamp-authority verifier&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;This vulnerability does **not** apply to timestamp-authority service, only to users of `timestamp-authority/v2/pkg/verification` package.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;### Patches&lt;/p&gt;
&lt;p&gt;The issue will be fixed in timestamp-authority 2.0.6&lt;/p&gt;
&lt;p&gt;### Workarounds&lt;/p&gt;
&lt;p&gt;Users of `VerifyTimestampResponse` can use the `TSACertificate` option to specify the exact certificate they expect to be used: this fully mitigates the issue.&lt;/p&gt;
&lt;p&gt;### References&lt;/p&gt;
&lt;p&gt;This issue was found after reading CVE-2026-33753 / GHSA-3xxc-p…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-xm5m-wgh2-rrg3</guid>
    </item>
  </channel>
</rss>
