<?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 sightings.</title>
    <link>https://db.gcve.eu</link>
    <description>Contains only the most 10 recent sightings.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Mon, 04 May 2026 06:39:24 +0000</lastBuildDate>
    <item>
      <title>290bd76d-b046-444e-a063-39cedb67608e</title>
      <link>https://db.gcve.eu/sighting/290bd76d-b046-444e-a063-39cedb67608e/export</link>
      <description>{"uuid": "290bd76d-b046-444e-a063-39cedb67608e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "GHSA-C873-WFHP-WX5M", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/3203", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: GHSA-c873-wfhp-wx5m\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In SP1\u2019s STARK verifier, the prover provided `chip_ordering` is used to fetch the index of the chips that have preprocessed columns. Prior to v4.0.0, the validation that this `chip_ordering` correctly provides these indexes was missing. In v4.0.0, this was fixed by adding a check that the indexed chip\u2019s name is equal to the name stored in the verifying key\u2019s chip information. \n\nIn the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. \n\nThis code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers.\n\nFurthermore, in the recursive verifier, the `is_complete` boolean flag is used to flag a proof of complete execution. Prior to v4.0.0, this flag was underconstrained in parts of our recursive verifier, such as the first layer of the recursion. In v4.0.0, this bug was fixed by adding appropriate calls to the `assert_complete` function, which constrains the correctness of the `is_complete` flag. This code was a part of the audit for v3.0.0. This bug affects the soundness of the Rust SDK for verifying compressed proofs, and the soundness of on-chain verifier for deferred proofs. \n\nThis issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. \n\nLastly, SP1\u2019s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3.\n\nThis bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production.\n\ud83d\udccf Published: 2025-01-15T21:25:54Z\n\ud83d\udccf Modified: 2025-01-28T02:03:05Z\n\ud83d\udd17 References:\n1. https://github.com/succinctlabs/sp1/security/advisories/GHSA-c873-wfhp-wx5m\n2. https://github.com/succinctlabs/sp1", "creation_timestamp": "2025-01-28T02:09:05.000000Z"}</description>
      <content:encoded>{"uuid": "290bd76d-b046-444e-a063-39cedb67608e", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "2a075640-a300-48a4-bb44-bc6130783b9b", "vulnerability": "GHSA-C873-WFHP-WX5M", "type": "published-proof-of-concept", "source": "https://t.me/DarkWebInformer_CVEAlerts/3203", "content": "\ud83d\udd17 DarkWebInformer.com - Cyber Threat Intelligence\n\ud83d\udccc CVE ID: GHSA-c873-wfhp-wx5m\n\ud83d\udd25 CVSS Score: N/A\n\ud83d\udd39 Description: In SP1\u2019s STARK verifier, the prover provided `chip_ordering` is used to fetch the index of the chips that have preprocessed columns. Prior to v4.0.0, the validation that this `chip_ordering` correctly provides these indexes was missing. In v4.0.0, this was fixed by adding a check that the indexed chip\u2019s name is equal to the name stored in the verifying key\u2019s chip information. \n\nIn the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. \n\nThis code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers.\n\nFurthermore, in the recursive verifier, the `is_complete` boolean flag is used to flag a proof of complete execution. Prior to v4.0.0, this flag was underconstrained in parts of our recursive verifier, such as the first layer of the recursion. In v4.0.0, this bug was fixed by adding appropriate calls to the `assert_complete` function, which constrains the correctness of the `is_complete` flag. This code was a part of the audit for v3.0.0. This bug affects the soundness of the Rust SDK for verifying compressed proofs, and the soundness of on-chain verifier for deferred proofs. \n\nThis issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. \n\nLastly, SP1\u2019s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3.\n\nThis bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production.\n\ud83d\udccf Published: 2025-01-15T21:25:54Z\n\ud83d\udccf Modified: 2025-01-28T02:03:05Z\n\ud83d\udd17 References:\n1. https://github.com/succinctlabs/sp1/security/advisories/GHSA-c873-wfhp-wx5m\n2. https://github.com/succinctlabs/sp1", "creation_timestamp": "2025-01-28T02:09:05.000000Z"}</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/sighting/290bd76d-b046-444e-a063-39cedb67608e/export</guid>
      <pubDate>Tue, 28 Jan 2025 02:09:05 +0000</pubDate>
    </item>
  </channel>
</rss>
