<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-03T23:48:29.598975+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-161791</id>
    <title>EUVD-2026-161791</title>
    <updated>2026-10-03T23:48:29.664599+00:00</updated>
    <content>EUVD-2026-161791</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-161791"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2024-45039</id>
    <title>fkie_cve-2024-45039</title>
    <updated>2026-10-03T23:48:29.664636+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>gnark is a fast zk-SNARK library that offers a high-level API to design circuits. Versions prior to 0.11.0 have a soundness issue - in case of multiple commitments used inside the circuit the prover is able to choose all but the last commitment. As gnark uses the commitments for optimized non-native multiplication, lookup checks etc. as random challenges, then it could impact the soundness of the whole circuit. However, using multiple commitments has been discouraged due to the additional cost to the verifier and it has not been supported in the recursive in-circuit Groth16 verifier and Solidity verifier. gnark's maintainers expect the impact of the issue be very small - only for the users who have implemented the native Groth16 verifier or are using it with multiple commitments. We do not have information of such users. The issue has been patched in version 0.11.0. As a workaround, users should follow gnark maintainers' recommendation to use only a single commitment and then derive in-circuit commitments as needed using the `std/multicommit` package.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2024-45039"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-q3hw-3gm4-w5cr</id>
    <title>GHSA-q3hw-3gm4-w5cr — gnark's Groth16 commitment extension unsound for more than one commitment</title>
    <updated>2026-10-03T23:48:29.664715+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Go: github.com/consensys/gnark</p>
<p>### Description</p>
<p>The summary is that the proof of knowledge associated to a commitment is crucial to bind the commitment to the actual circuit variables that were supposed to be committed. However, the same σ is used for all proofs of knowledge for the commitments, which allows mixing between them, making it possible to fix the value of all but one commitment before choosing the circuit variable assignments.</p>
<p>In more detail:
To simplify notation, let us consider the case of two commitments, each to only a single variable. Let's say the basis elements for those commitments are `K_0` and `K_1`. Then the proving key will contain `K_0` and `K_1`, and also `σ*K_0` and `σ*K_1` for the proof of knowledge. The honest prover assigning a to the first circuit variable and b to the second will then produce commitments
`D_0 = a*K_0`
`D_1 = b*K_1`
Out of the two D's, a challenge r for the commitment folding will be generated. The folded commitment will then be
`D_folded = D_0 + r*D_1 = a*K_0 + r*b*K_1`
The honest prover will supply a fitting proof of knowledge
`P = a*(σ*K_0) + r*b*(σ*K_1)`</p>
<p>Now the verifier will only use all of this in two ways:
1. In the check of the Groth16 proof itself, where only the sum `D_0 + D_1` is used.
2. In the proof of knowledge check, where it will be verified that P is indeed `σ*(D_0 + r*D_1)`, with r calculated from `D_0` and `D_1` as before.</p>
<p>This has the following implications. In the following, a malicious prover's points will have an apostrophe appended…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-q3hw-3gm4-w5cr"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2024:14599-1</id>
    <title>openSUSE-SU-2024:14599-1 — govulncheck-vulndb-0.0.20241213T205935-1.1 on GA media</title>
    <updated>2026-10-03T23:48:29.664785+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>govulncheck-vulndb-0.0.20241213T205935-1.1 on GA media</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2024:14599-1"/>
  </entry>
</feed>
