<?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://cve.radiocsirt.org</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>Sun, 04 Oct 2026 20:00:44 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-199437</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-199437</link>
      <description>EUVD-2026-199437</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-199437</guid>
    </item>
    <item>
      <title>fkie_cve-2024-51746</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2024-51746</link>
      <description>&lt;p&gt;Gitsign is a keyless Sigstore to signing tool for Git commits with your a GitHub / OIDC identity. gitsign may select the wrong Rekor entry to use during online verification when multiple entries are returned by the log. gitsign uses Rekor&amp;#39;s search API to fetch entries that apply to a signature being verified. The parameters used for the search are the public key and the payload. The search API returns entries that match either condition rather than both. When gitsign&amp;#39;s credential cache is used, there can be multiple entries that use the same ephemeral keypair / signing certificate. As gitsign assumes both conditions are matched by Rekor, there is no additional validation that the entry&amp;#39;s hash matches the payload being verified, meaning that the wrong entry can be used to successfully pass verification. Impact is minimal as while gitsign does not match the payload against the entry, it does ensure that the certificate matches. This would need to be exploited during the certificate validity window (10 minutes) by the key holder.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Gitsign is a keyless Sigstore to signing tool for Git commits with your a GitHub / OIDC identity. gitsign may select the wrong Rekor entry to use during online verification when multiple entries are returned by the log. gitsign uses Rekor&amp;#39;s search API to fetch entries that apply to a signature being verified. The parameters used for the search are the public key and the payload. The search API returns entries that match either condition rather than both. When gitsign&amp;#39;s credential cache is used, there can be multiple entries that use the same ephemeral keypair / signing certificate. As gitsign assumes both conditions are matched by Rekor, there is no additional validation that the entry&amp;#39;s hash matches the payload being verified, meaning that the wrong entry can be used to successfully pass verification. Impact is minimal as while gitsign does not match the payload against the entry, it does ensure that the certificate matches. This would need to be exploited during the certificate validity window (10 minutes) by the key holder.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2024-51746</guid>
    </item>
    <item>
      <title>GHSA-8pmp-678w-c8xx — gitsign may use incorrect Rekor entries during verification</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-8pmp-678w-c8xx</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/sigstore/gitsign&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;gitsign may select the wrong Rekor entry to use during online verification when multiple entries are returned by the log.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;gitsign uses Rekor&amp;#39;s search API to fetch entries that apply to a signature being verified. The parameters used for the search are the public key and the payload. The search API returns entries that match _either_ condition rather than _both_. When gitsign&amp;#39;s credential cache is used, there can be multiple entries that use the same ephemeral keypair / signing certificate. As gitsign assumes both conditions are matched by Rekor, there is no additional validation that the entry&amp;#39;s hash matches the payload being verified, meaning that the wrong entry can be used to successfully pass verification.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;Enable the credential cache and create commit signatures using the cached signing certificate. `gitsign verify` or `git log --show-signature` will demonstrate the use of the wrong entry index for the corresponding commit. Note that this depends on the order of matching entries in the response from the Rekor search API, so it may take a few attempts to trigger this.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Minimal. While gitsign does not match the payload against the entry, it does ensure that the certificate matches. This would need to be exploited during the certificate validity window (10 minutes) by the key holder.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Go: github.com/sigstore/gitsign&lt;/p&gt;
&lt;p&gt;### Summary&lt;/p&gt;
&lt;p&gt;gitsign may select the wrong Rekor entry to use during online verification when multiple entries are returned by the log.&lt;/p&gt;
&lt;p&gt;### Details&lt;/p&gt;
&lt;p&gt;gitsign uses Rekor&amp;#39;s search API to fetch entries that apply to a signature being verified. The parameters used for the search are the public key and the payload. The search API returns entries that match _either_ condition rather than _both_. When gitsign&amp;#39;s credential cache is used, there can be multiple entries that use the same ephemeral keypair / signing certificate. As gitsign assumes both conditions are matched by Rekor, there is no additional validation that the entry&amp;#39;s hash matches the payload being verified, meaning that the wrong entry can be used to successfully pass verification.&lt;/p&gt;
&lt;p&gt;### PoC&lt;/p&gt;
&lt;p&gt;Enable the credential cache and create commit signatures using the cached signing certificate. `gitsign verify` or `git log --show-signature` will demonstrate the use of the wrong entry index for the corresponding commit. Note that this depends on the order of matching entries in the response from the Rekor search API, so it may take a few attempts to trigger this.&lt;/p&gt;
&lt;p&gt;### Impact&lt;/p&gt;
&lt;p&gt;Minimal. While gitsign does not match the payload against the entry, it does ensure that the certificate matches. This would need to be exploited during the certificate validity window (10 minutes) by the key holder.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-8pmp-678w-c8xx</guid>
    </item>
    <item>
      <title>openSUSE-SU-2024:14470-1 — govulncheck-vulndb-0.0.20241106T172143-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2024:14470-1</link>
      <description>&lt;p&gt;govulncheck-vulndb-0.0.20241106T172143-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;govulncheck-vulndb-0.0.20241106T172143-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2024:14470-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2024:4042-1 — Security update for govulncheck-vulndb</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2024:4042-1</link>
      <description>&lt;p&gt;Security update for govulncheck-vulndb&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for govulncheck-vulndb&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2024:4042-1</guid>
    </item>
  </channel>
</rss>
