<?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>Tue, 06 Oct 2026 17:18:17 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-319025</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-319025</link>
      <description>EUVD-2026-319025</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-319025</guid>
    </item>
    <item>
      <title>fkie_cve-2026-44309</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-44309</link>
      <description>&lt;p&gt;Gitsign is a keyless Sigstore to signing tool for Git commits with your a GitHub / OIDC identity. Prior to 0.16.0, gitsign verify and gitsign verify-tag re-encode commit/tag objects through go-git&amp;#39;s EncodeWithoutSignature before checking the signature, instead of verifying against the raw git object bytes. For malformed objects with duplicate tree headers, git-core and go-git parse different trees: git-core uses the first, go-git uses the second. A signature crafted over the go-git-normalized form (second tree) passes gitsign verify while git-core resolves the commit to a completely different tree. This breaks the invariant that a verified signature, the commit semantics git-core presents to users, and the object hash logged in Rekor all refer to the same content. This vulnerability is fixed in 0.16.0.&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. Prior to 0.16.0, gitsign verify and gitsign verify-tag re-encode commit/tag objects through go-git&amp;#39;s EncodeWithoutSignature before checking the signature, instead of verifying against the raw git object bytes. For malformed objects with duplicate tree headers, git-core and go-git parse different trees: git-core uses the first, go-git uses the second. A signature crafted over the go-git-normalized form (second tree) passes gitsign verify while git-core resolves the commit to a completely different tree. This breaks the invariant that a verified signature, the commit semantics git-core presents to users, and the object hash logged in Rekor all refer to the same content. This vulnerability is fixed in 0.16.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-44309</guid>
    </item>
    <item>
      <title>GHSA-7rmh-48mx-2vwc — gitsign verify accepts signatures over go-git-normalized bytes, enabling trust confusion on malformed commits</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-7rmh-48mx-2vwc</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 verify` and `gitsign verify-tag` re-encode commit/tag objects through go-git&amp;#39;s `EncodeWithoutSignature` before checking the signature, instead of verifying against the raw git object bytes. For malformed objects with duplicate `tree` headers, git-core and go-git parse different trees: git-core uses the first, go-git uses the second. A signature crafted over the go-git-normalized form (second tree) passes `gitsign verify` while git-core resolves the commit to a completely different tree. This breaks the invariant that a verified signature, the commit semantics git-core presents to users, and the object hash logged in Rekor all refer to the same content.&lt;/p&gt;
&lt;p&gt;## Severity&lt;/p&gt;
&lt;p&gt;**Medium** (CVSS 3.1: 5.7)&lt;/p&gt;
&lt;p&gt;`CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N`&lt;/p&gt;
&lt;p&gt;- **Attack Vector:** Network — a malformed commit can be distributed via any accessible git remote
- **Attack Complexity:** High — exploitation requires crafting malformed objects that also bypass git server fsck checks (not universally enabled)
- **Privileges Required:** None — the most impactful form (signature replay) requires no signing key
- **User Interaction:** Required — a victim must run `gitsign verify` on the malformed commit
- **Scope:** Unchanged — impact is confined to the repository under verification
- **Confidentiality Impact:** None
- **Integrity Impact:** High — a verified signature appears to endorse content different from what git-core resolves and presents to users
- **Availability Impact:** None…&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 verify` and `gitsign verify-tag` re-encode commit/tag objects through go-git&amp;#39;s `EncodeWithoutSignature` before checking the signature, instead of verifying against the raw git object bytes. For malformed objects with duplicate `tree` headers, git-core and go-git parse different trees: git-core uses the first, go-git uses the second. A signature crafted over the go-git-normalized form (second tree) passes `gitsign verify` while git-core resolves the commit to a completely different tree. This breaks the invariant that a verified signature, the commit semantics git-core presents to users, and the object hash logged in Rekor all refer to the same content.&lt;/p&gt;
&lt;p&gt;## Severity&lt;/p&gt;
&lt;p&gt;**Medium** (CVSS 3.1: 5.7)&lt;/p&gt;
&lt;p&gt;`CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N`&lt;/p&gt;
&lt;p&gt;- **Attack Vector:** Network — a malformed commit can be distributed via any accessible git remote
- **Attack Complexity:** High — exploitation requires crafting malformed objects that also bypass git server fsck checks (not universally enabled)
- **Privileges Required:** None — the most impactful form (signature replay) requires no signing key
- **User Interaction:** Required — a victim must run `gitsign verify` on the malformed commit
- **Scope:** Unchanged — impact is confined to the repository under verification
- **Confidentiality Impact:** None
- **Integrity Impact:** High — a verified signature appears to endorse content different from what git-core resolves and presents to users
- **Availability Impact:** None…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-7rmh-48mx-2vwc</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-44309</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-44309</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:25.10: gitsign, Ubuntu:Pro:26.04:LTS: gitsign&lt;/p&gt;
&lt;p&gt;Gitsign is a keyless Sigstore to signing tool for Git commits with your a GitHub / OIDC identity. Prior to 0.16.0, gitsign verify and gitsign verify-tag re-encode commit/tag objects through go-git&amp;#39;s EncodeWithoutSignature before checking the signature, instead of verifying against the raw git object bytes. For malformed objects with duplicate tree headers, git-core and go-git parse different trees: git-core uses the first, go-git uses the second. A signature crafted over the go-git-normalized form (second tree) passes gitsign verify while git-core resolves the commit to a completely different tree. This breaks the invariant that a verified signature, the commit semantics git-core presents to users, and the object hash logged in Rekor all refer to the same content. This vulnerability is fixed in 0.16.0.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:25.10: gitsign, Ubuntu:Pro:26.04:LTS: gitsign&lt;/p&gt;
&lt;p&gt;Gitsign is a keyless Sigstore to signing tool for Git commits with your a GitHub / OIDC identity. Prior to 0.16.0, gitsign verify and gitsign verify-tag re-encode commit/tag objects through go-git&amp;#39;s EncodeWithoutSignature before checking the signature, instead of verifying against the raw git object bytes. For malformed objects with duplicate tree headers, git-core and go-git parse different trees: git-core uses the first, go-git uses the second. A signature crafted over the go-git-normalized form (second tree) passes gitsign verify while git-core resolves the commit to a completely different tree. This breaks the invariant that a verified signature, the commit semantics git-core presents to users, and the object hash logged in Rekor all refer to the same content. This vulnerability is fixed in 0.16.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-44309</guid>
    </item>
  </channel>
</rss>
