<?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>Sat, 03 Oct 2026 21:17:13 +0000</lastBuildDate>
    <item>
      <title>EUVD-2026-319020</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-319020</link>
      <description>EUVD-2026-319020</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-319020</guid>
    </item>
    <item>
      <title>fkie_cve-2026-44310</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-44310</link>
      <description>&lt;p&gt;Gitsign is a keyless Sigstore to signing tool for Git commits with your a GitHub / OIDC identity. From 0.4.0 to before 0.15.0, CertVerifier.Verify() in pkg/git/verifier.go unconditionally dereferences certs[0] after sd.GetCertificates() without checking the slice length. A CMS/PKCS7 signed message with an empty certificate set is a structurally valid DER payload; GetCertificates() returns an empty slice with no error, causing an immediate index-out-of-range panic. On the gitsign --verify code path (the GPG-compatible mode invoked by git verify-commit), the panic is silently recovered by internal/io/streams.go&amp;#39;s Wrap() function, which returns nil instead of an error. main.go then exits with code 0, causing exit-code-only verification callers to interpret the failed verification as success. This vulnerability is fixed in 0.15.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. From 0.4.0 to before 0.15.0, CertVerifier.Verify() in pkg/git/verifier.go unconditionally dereferences certs[0] after sd.GetCertificates() without checking the slice length. A CMS/PKCS7 signed message with an empty certificate set is a structurally valid DER payload; GetCertificates() returns an empty slice with no error, causing an immediate index-out-of-range panic. On the gitsign --verify code path (the GPG-compatible mode invoked by git verify-commit), the panic is silently recovered by internal/io/streams.go&amp;#39;s Wrap() function, which returns nil instead of an error. main.go then exits with code 0, causing exit-code-only verification callers to interpret the failed verification as success. This vulnerability is fixed in 0.15.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-44310</guid>
    </item>
    <item>
      <title>GHSA-7c37-gx6w-8vc5 — gitsign --verify panics on empty-certificate PKCS7 and exits 0, bypassing exit-code callers</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-7c37-gx6w-8vc5</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;`CertVerifier.Verify()` in `pkg/git/verifier.go` unconditionally dereferences `certs[0]` after `sd.GetCertificates()` without checking the slice length. A CMS/PKCS7 signed message with an empty certificate set is a structurally valid DER payload; `GetCertificates()` returns an empty slice with no error, causing an immediate index-out-of-range panic. On the `gitsign --verify` code path (the GPG-compatible mode invoked by `git verify-commit`), the panic is silently recovered by `internal/io/streams.go`&amp;#39;s `Wrap()` function, which returns `nil` instead of an error. `main.go` then exits with code 0, causing exit-code-only verification callers to interpret the failed verification as success.&lt;/p&gt;
&lt;p&gt;## Severity&lt;/p&gt;
&lt;p&gt;**Medium** (CVSS 3.1: 5.8)&lt;/p&gt;
&lt;p&gt;`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L`&lt;/p&gt;
&lt;p&gt;- **Attack Vector:** Network — attacker pushes a commit carrying a crafted signature to any accessible repository, or delivers the signature file out-of-band
- **Attack Complexity:** Low — stripping certificates from a PKCS7 object requires only standard ASN.1 tooling
- **Privileges Required:** None — writing to an accessible repo (or creating a repo a victim clones) is sufficient
- **User Interaction:** Required — victim must run `git verify-commit`, `gitsign --verify`, or an equivalent verification step
- **Scope:** Unchanged
- **Confidentiality Impact:** None
- **Integrity Impact:** Low — exit-code-only callers (scripts, some CI pipelines) treat the panicked verification as success; git&amp;#39;s o…&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;`CertVerifier.Verify()` in `pkg/git/verifier.go` unconditionally dereferences `certs[0]` after `sd.GetCertificates()` without checking the slice length. A CMS/PKCS7 signed message with an empty certificate set is a structurally valid DER payload; `GetCertificates()` returns an empty slice with no error, causing an immediate index-out-of-range panic. On the `gitsign --verify` code path (the GPG-compatible mode invoked by `git verify-commit`), the panic is silently recovered by `internal/io/streams.go`&amp;#39;s `Wrap()` function, which returns `nil` instead of an error. `main.go` then exits with code 0, causing exit-code-only verification callers to interpret the failed verification as success.&lt;/p&gt;
&lt;p&gt;## Severity&lt;/p&gt;
&lt;p&gt;**Medium** (CVSS 3.1: 5.8)&lt;/p&gt;
&lt;p&gt;`CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L`&lt;/p&gt;
&lt;p&gt;- **Attack Vector:** Network — attacker pushes a commit carrying a crafted signature to any accessible repository, or delivers the signature file out-of-band
- **Attack Complexity:** Low — stripping certificates from a PKCS7 object requires only standard ASN.1 tooling
- **Privileges Required:** None — writing to an accessible repo (or creating a repo a victim clones) is sufficient
- **User Interaction:** Required — victim must run `git verify-commit`, `gitsign --verify`, or an equivalent verification step
- **Scope:** Unchanged
- **Confidentiality Impact:** None
- **Integrity Impact:** Low — exit-code-only callers (scripts, some CI pipelines) treat the panicked verification as success; git&amp;#39;s o…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-7c37-gx6w-8vc5</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-44310</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-44310</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. From 0.4.0 to before 0.15.0, CertVerifier.Verify() in pkg/git/verifier.go unconditionally dereferences certs[0] after sd.GetCertificates() without checking the slice length. A CMS/PKCS7 signed message with an empty certificate set is a structurally valid DER payload; GetCertificates() returns an empty slice with no error, causing an immediate index-out-of-range panic. On the gitsign --verify code path (the GPG-compatible mode invoked by git verify-commit), the panic is silently recovered by internal/io/streams.go&amp;#39;s Wrap() function, which returns nil instead of an error. main.go then exits with code 0, causing exit-code-only verification callers to interpret the failed verification as success. This vulnerability is fixed in 0.15.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. From 0.4.0 to before 0.15.0, CertVerifier.Verify() in pkg/git/verifier.go unconditionally dereferences certs[0] after sd.GetCertificates() without checking the slice length. A CMS/PKCS7 signed message with an empty certificate set is a structurally valid DER payload; GetCertificates() returns an empty slice with no error, causing an immediate index-out-of-range panic. On the gitsign --verify code path (the GPG-compatible mode invoked by git verify-commit), the panic is silently recovered by internal/io/streams.go&amp;#39;s Wrap() function, which returns nil instead of an error. main.go then exits with code 0, causing exit-code-only verification callers to interpret the failed verification as success. This vulnerability is fixed in 0.15.0.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-44310</guid>
    </item>
  </channel>
</rss>
