Vulnerability-Lookup

CVE-2024-45039 (GCVE-0-2024-45039)

Vulnerability from cvelistv5 – Published: 2024-09-06 12:56 – Updated: 2024-09-06 13:59

Title

gnark's Groth16 commitment extension unsound for more than one commitment

Summary

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.

Severity

6.2 (Medium)


                        
                          CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

SSVC

Exploitation: poc Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2024-09-06 13:58 UTC

CWE

CWE-200 - Exposure of Sensitive Information to an Unauthorized Actor

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 7993 records in the last 180 days details

References

2 references

URL	Tags
https://github.com/Consensys/gnark/security/advis…	x_refsource_CONFIRM
https://github.com/Consensys/gnark/commit/e7c66b0…	x_refsource_MISC

Impacted products

2 products

Vendor	Product	Version	CPE status
Consensys	gnark	Affected: < 0.11.0	guessed
consensys	gnark	Affected: 0 , < 0.11.0 (custom) cpe:2.3:a:consensys:gnark::::::::

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "affected": [
          {
            "cpes": [
              "cpe:2.3:a:consensys:gnark:*:*:*:*:*:*:*:*"
            ],
            "defaultStatus": "unknown",
            "product": "gnark",
            "vendor": "consensys",
            "versions": [
              {
                "lessThan": "0.11.0",
                "status": "affected",
                "version": "0",
                "versionType": "custom"
              }
            ]
          }
        ],
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2024-45039",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-06T13:58:43.116066Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2024-09-06T13:59:16.727Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "gnark",
          "vendor": "Consensys",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.11.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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\u0027s 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\u0027 recommendation to use only a single commitment and then derive in-circuit commitments as needed using the `std/multicommit` package."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "LOCAL",
            "availabilityImpact": "NONE",
            "baseScore": 6.2,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "NONE",
            "integrityImpact": "HIGH",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-200",
              "description": "CWE-200: Exposure of Sensitive Information to an Unauthorized Actor",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2024-09-06T12:56:15.080Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/Consensys/gnark/security/advisories/GHSA-q3hw-3gm4-w5cr",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/Consensys/gnark/security/advisories/GHSA-q3hw-3gm4-w5cr"
        },
        {
          "name": "https://github.com/Consensys/gnark/commit/e7c66b000454f4d2a4ae48c005c34154d4cfc2a2",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/Consensys/gnark/commit/e7c66b000454f4d2a4ae48c005c34154d4cfc2a2"
        }
      ],
      "source": {
        "advisory": "GHSA-q3hw-3gm4-w5cr",
        "discovery": "UNKNOWN"
      },
      "title": "gnark\u0027s Groth16 commitment extension unsound for more than one commitment"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2024-45039",
    "datePublished": "2024-09-06T12:56:15.080Z",
    "dateReserved": "2024-08-21T17:53:51.330Z",
    "dateUpdated": "2024-09-06T13:59:16.727Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.1",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2024-45039",
      "date": "2026-11-07",
      "epss": "0.0019",
      "percentile": "0.08706"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "product": "gnark",
                "vendor": "Consensys",
                "versions": [
                  {
                    "status": "affected",
                    "version": "\u003c 0.11.0"
                  }
                ]
              }
            ],
            "source": "security-advisories@github.com"
          },
          {
            "affectedData": [
              {
                "cpes": [
                  "cpe:2.3:a:consensys:gnark:*:*:*:*:*:*:*:*"
                ],
                "defaultStatus": "unknown",
                "product": "gnark",
                "vendor": "consensys",
                "versions": [
                  {
                    "lessThan": "0.11.0",
                    "status": "affected",
                    "version": "0",
                    "versionType": "custom"
                  }
                ]
              }
            ],
            "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0"
          }
        ],
        "configurations": [
          {
            "nodes": [
              {
                "cpeMatch": [
                  {
                    "criteria": "cpe:2.3:a:consensys:gnark-crypto:*:*:*:*:*:*:*:*",
                    "matchCriteriaId": "622EAC41-6FA3-4B4A-948D-81E243DEFAA7",
                    "versionEndExcluding": "0.11.0",
                    "vulnerable": true
                  }
                ],
                "negate": false,
                "operator": "OR"
              }
            ]
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "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\u0027s 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\u0027 recommendation to use only a single commitment and then derive in-circuit commitments as needed using the `std/multicommit` package."
          },
          {
            "lang": "es",
            "value": "gnark es una librer\u00eda zk-SNARK r\u00e1pida que ofrece una API de alto nivel para dise\u00f1ar circuitos. Las versiones anteriores a la 0.11.0 tienen un problema de solidez: en caso de que se utilicen m\u00faltiples compromisos dentro del circuito, el probador puede elegir todos los compromisos excepto el \u00faltimo. Como gnark utiliza los compromisos para la multiplicaci\u00f3n no nativa optimizada, las comprobaciones de b\u00fasqueda, etc. como desaf\u00edos aleatorios, podr\u00eda afectar la solidez de todo el circuito. Sin embargo, se ha desaconsejado el uso de m\u00faltiples compromisos debido al coste adicional para el verificador y no se ha admitido en el verificador recursivo Groth16 en circuito ni en el verificador Solidity. Los mantenedores de gnark esperan que el impacto del problema sea muy peque\u00f1o: solo para los usuarios que han implementado el verificador nativo Groth16 o lo est\u00e1n utilizando con m\u00faltiples compromisos. No tenemos informaci\u00f3n de dichos usuarios. El problema se ha solucionado en la versi\u00f3n 0.11.0. Como workaround, los usuarios deben seguir la recomendaci\u00f3n de los mantenedores de gnark de usar solo un \u00fanico compromiso y luego derivar compromisos en circuito seg\u00fan sea necesario utilizando el paquete `std/multicommit`."
          }
        ],
        "id": "CVE-2024-45039",
        "lastModified": "2026-06-17T07:53:28.500",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "NONE",
                "baseScore": 6.2,
                "baseSeverity": "MEDIUM",
                "confidentialityImpact": "NONE",
                "integrityImpact": "HIGH",
                "privilegesRequired": "NONE",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
                "version": "3.1"
              },
              "exploitabilityScore": 2.5,
              "impactScore": 3.6,
              "source": "security-advisories@github.com",
              "type": "Secondary"
            },
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "NONE",
                "baseScore": 6.2,
                "baseSeverity": "MEDIUM",
                "confidentialityImpact": "NONE",
                "integrityImpact": "HIGH",
                "privilegesRequired": "NONE",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
                "version": "3.1"
              },
              "exploitabilityScore": 2.5,
              "impactScore": 3.6,
              "source": "nvd@nist.gov",
              "type": "Primary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2024-45039",
                "options": [
                  {
                    "exploitation": "poc"
                  },
                  {
                    "automatable": "no"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2024-09-06T13:58:43.116066Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2024-09-06T13:15:04.400",
        "references": [
          {
            "source": "security-advisories@github.com",
            "tags": [
              "Broken Link"
            ],
            "url": "https://github.com/Consensys/gnark/commit/e7c66b000454f4d2a4ae48c005c34154d4cfc2a2"
          },
          {
            "source": "security-advisories@github.com",
            "tags": [
              "Third Party Advisory"
            ],
            "url": "https://github.com/Consensys/gnark/security/advisories/GHSA-q3hw-3gm4-w5cr"
          }
        ],
        "sourceIdentifier": "security-advisories@github.com",
        "vulnStatus": "Analyzed",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-200"
              }
            ],
            "source": "security-advisories@github.com",
            "type": "Secondary"
          },
          {
            "description": [
              {
                "lang": "en",
                "value": "NVD-CWE-noinfo"
              }
            ],
            "source": "nvd@nist.gov",
            "type": "Primary"
          }
        ]
      }
    },
    "redhat_vex": {
      "current_release_date": "2025-05-28T22:02:31+00:00",
      "cve": "CVE-2024-45039",
      "id": "CVE-2024-45039",
      "initial_release_date": "2024-01-01T00:00:00+00:00",
      "product_status:known_not_affected": "1",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "gnark\u0027s Groth16 commitment extension unsound for more than one commitment",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2024/cve-2024-45039.json",
      "version": "3"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "affected": [
              {
                "cpes": [
                  "cpe:2.3:a:consensys:gnark:*:*:*:*:*:*:*:*"
                ],
                "defaultStatus": "unknown",
                "product": "gnark",
                "vendor": "consensys",
                "versions": [
                  {
                    "lessThan": "0.11.0",
                    "status": "affected",
                    "version": "0",
                    "versionType": "custom"
                  }
                ]
              }
            ],
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2024-45039",
                    "options": [
                      {
                        "Exploitation": "poc"
                      },
                      {
                        "Automatable": "no"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2024-09-06T13:58:43.116066Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2024-09-06T13:59:10.880Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "product": "gnark",
              "vendor": "Consensys",
              "versions": [
                {
                  "status": "affected",
                  "version": "\u003c 0.11.0"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "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\u0027s 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\u0027 recommendation to use only a single commitment and then derive in-circuit commitments as needed using the `std/multicommit` package."
            }
          ],
          "metrics": [
            {
              "cvssV3_1": {
                "attackComplexity": "LOW",
                "attackVector": "LOCAL",
                "availabilityImpact": "NONE",
                "baseScore": 6.2,
                "baseSeverity": "MEDIUM",
                "confidentialityImpact": "NONE",
                "integrityImpact": "HIGH",
                "privilegesRequired": "NONE",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
                "version": "3.1"
              }
            }
          ],
          "problemTypes": [
            {
              "descriptions": [
                {
                  "cweId": "CWE-200",
                  "description": "CWE-200: Exposure of Sensitive Information to an Unauthorized Actor",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2024-09-06T12:56:15.080Z",
            "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
            "shortName": "GitHub_M"
          },
          "references": [
            {
              "name": "https://github.com/Consensys/gnark/security/advisories/GHSA-q3hw-3gm4-w5cr",
              "tags": [
                "x_refsource_CONFIRM"
              ],
              "url": "https://github.com/Consensys/gnark/security/advisories/GHSA-q3hw-3gm4-w5cr"
            },
            {
              "name": "https://github.com/Consensys/gnark/commit/e7c66b000454f4d2a4ae48c005c34154d4cfc2a2",
              "tags": [
                "x_refsource_MISC"
              ],
              "url": "https://github.com/Consensys/gnark/commit/e7c66b000454f4d2a4ae48c005c34154d4cfc2a2"
            }
          ],
          "source": {
            "advisory": "GHSA-q3hw-3gm4-w5cr",
            "discovery": "UNKNOWN"
          },
          "title": "gnark\u0027s Groth16 commitment extension unsound for more than one commitment"
        }
      },
      "cveMetadata": {
        "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "assignerShortName": "GitHub_M",
        "cveId": "CVE-2024-45039",
        "datePublished": "2024-09-06T12:56:15.080Z",
        "dateReserved": "2024-08-21T17:53:51.330Z",
        "dateUpdated": "2024-09-06T13:59:16.727Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.1"
    }
  }
}

FKIE_CVE-2024-45039

Vulnerability from fkie_nvd - Published: 2024-09-06 13:15 - Updated: 2026-06-17 07:53

Severity

6.2 (Medium) - CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
6.2 (Medium) - CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Summary

References

	URL	Tags
	security-advisories@github.com	https://github.com/Consensys/gnark/commit/e7c66b000454f4d2a4ae48c005c34154d4cfc2a2	Broken Link
	security-advisories@github.com	https://github.com/Consensys/gnark/security/advisories/GHSA-q3hw-3gm4-w5cr	Third Party Advisory

Impacted products

	Vendor	Product	Version
	consensys	gnark-crypto	*

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "product": "gnark",
          "vendor": "Consensys",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 0.11.0"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    },
    {
      "affectedData": [
        {
          "cpes": [
            "cpe:2.3:a:consensys:gnark:*:*:*:*:*:*:*:*"
          ],
          "defaultStatus": "unknown",
          "product": "gnark",
          "vendor": "consensys",
          "versions": [
            {
              "lessThan": "0.11.0",
              "status": "affected",
              "version": "0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:consensys:gnark-crypto:*:*:*:*:*:*:*:*",
              "matchCriteriaId": "622EAC41-6FA3-4B4A-948D-81E243DEFAA7",
              "versionEndExcluding": "0.11.0",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "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\u0027s 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\u0027 recommendation to use only a single commitment and then derive in-circuit commitments as needed using the `std/multicommit` package."
    },
    {
      "lang": "es",
      "value": "gnark es una librer\u00eda zk-SNARK r\u00e1pida que ofrece una API de alto nivel para dise\u00f1ar circuitos. Las versiones anteriores a la 0.11.0 tienen un problema de solidez: en caso de que se utilicen m\u00faltiples compromisos dentro del circuito, el probador puede elegir todos los compromisos excepto el \u00faltimo. Como gnark utiliza los compromisos para la multiplicaci\u00f3n no nativa optimizada, las comprobaciones de b\u00fasqueda, etc. como desaf\u00edos aleatorios, podr\u00eda afectar la solidez de todo el circuito. Sin embargo, se ha desaconsejado el uso de m\u00faltiples compromisos debido al coste adicional para el verificador y no se ha admitido en el verificador recursivo Groth16 en circuito ni en el verificador Solidity. Los mantenedores de gnark esperan que el impacto del problema sea muy peque\u00f1o: solo para los usuarios que han implementado el verificador nativo Groth16 o lo est\u00e1n utilizando con m\u00faltiples compromisos. No tenemos informaci\u00f3n de dichos usuarios. El problema se ha solucionado en la versi\u00f3n 0.11.0. Como workaround, los usuarios deben seguir la recomendaci\u00f3n de los mantenedores de gnark de usar solo un \u00fanico compromiso y luego derivar compromisos en circuito seg\u00fan sea necesario utilizando el paquete `std/multicommit`."
    }
  ],
  "id": "CVE-2024-45039",
  "lastModified": "2026-06-17T07:53:28.500",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "NONE",
          "baseScore": 6.2,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.5,
        "impactScore": 3.6,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      },
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "NONE",
          "baseScore": 6.2,
          "baseSeverity": "MEDIUM",
          "confidentialityImpact": "NONE",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
          "version": "3.1"
        },
        "exploitabilityScore": 2.5,
        "impactScore": 3.6,
        "source": "nvd@nist.gov",
        "type": "Primary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2024-45039",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2024-09-06T13:58:43.116066Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2024-09-06T13:15:04.400",
  "references": [
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Broken Link"
      ],
      "url": "https://github.com/Consensys/gnark/commit/e7c66b000454f4d2a4ae48c005c34154d4cfc2a2"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Third Party Advisory"
      ],
      "url": "https://github.com/Consensys/gnark/security/advisories/GHSA-q3hw-3gm4-w5cr"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-200"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    },
    {
      "description": [
        {
          "lang": "en",
          "value": "NVD-CWE-noinfo"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}

GHSA-Q3HW-3GM4-W5CR

Vulnerability from github – Published: 2024-09-06 19:53 – Updated: 2024-11-20 19:26

Summary

gnark's Groth16 commitment extension unsound for more than one commitment

Details

Description

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.

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)

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.

This has the following implications. In the following, a malicious prover's points will have an apostrophe appended, and we keep D_0 etc. for the legitimate values: 1. A malicious prover is only forced to provide D'_0 and D'_1 such that the sum is correct. So they can use arbitrary D'_0 as long as they set D'_1 = D_0 + D_1 - D'_0. 2. After choosing D'_0 and D'_1, the prover can always calculate r. Evaluating σ*(D'_0 + r*D'_1) is then possible as long as both D'_0 and D'_1 are linear combinations of basis elements for which σ times that basis element is known. In particular, this works as long as D'_0 and D'_1 are linear combinations of K_0 and K_1.

The upshot is that a malicious prover can choose arbitrary a' and b', and then set D'_0 = a'*K_0 + b'*K_1 D'_1 = (a - a')*K_0 + (b - b')*K_1 Then they calculate r for this, and set P = (a' + r*(a-a'))*(σ*K_0) + (b' + r*(b-b'))*(σ*K_1) This will then be accepted as a valid proof. Yet the first commitment point can be chosen completely independently of a and b, so in particular the malicious prover can use a constant for this, so that they will know the in-circuit challenge that will be added to the public inputs before they have to choose the witness assignments. For most use cases of such challenges (for proving things with Fiat-Shamir, random linear combinations etc.) this causes a critical soundness problem.

The problem generalizes to more than two commitments and commitments to more than one circuit variable each; one can freely choose all but one commitment as arbitrary linear combinations of the basis elements for all commitments, and then must choose the one remaining commitment in such a way that the sum is correct.

The root cause of the issue is that the σ used for the proofs of knowledge is the same, allowing to mix between the basis elements, as one has σ times them available for all of them. So the fix is to have a separate σ for each commitment. So in our example above, the proving key would have the basis elements K_0 and K_1, and for the proofs of knowledge now σ_0*K_0 and σ_1*K_1. Folding the commitments would not be possible in the same way now, so the verifier will have to do more pairings. The prover could still provide a folded proof of knowledge however. With D_0 = a*K_0 D_1 = b*K_1 the proof of knowledge would be P = a*(σ_0*K_0) + r*b*(σ_1*K_1) For later, let us use notation for the unfolded proofs of knowledge P_0 = a*(σ_0*K_0) P_1 = b*(σ_1*K_1) so that P = P_0 + r*P_1

The verifying key would need G and σ_0*G and σ_1*G. To check the two unfolded proofs of knowledge would be the checks e(P_0, G) = e(D_0, σ_0*G) e(P_1, G) = e(D_1, σ_1*G) As r is a challenge derived from D_0 and D_1, we may instead check e(P_0, G) + r*e(P_1, G) = e(D_0, σ_0*G) + r*e(D_1, σ_1*G) The left hand side is e(P_0, G) + r*e(P_1, G) = e(P_0 + r*P_1, G) = e(P, G) So the prover can just provide P and then the verifier checks e(P, G) = e(D_0, σ_0*G) + r*e(D_1, σ_1*G) Unfortunately, the right hand side can't be folded as before, as there isn't a side of the pairing that is kept constant between the pairings as before. So the verifier will need to have a pairing for each commitment on the right hand side.

Impact

It is a soundness issue - in case of multiple commitments used inside the circuit the prover is able to choose all but the last commitment. As we use 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. So we 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.

Patches

The issue has been patched in e7c66b000454f4d2a4ae48c005c34154d4cfc2a2

Workarounds

The recommendation has been to use only a single commitment and then derive in-circuit commitments as needed using std/multicommit package.

References

See the correspondence above.

Severity

6.2 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.10.0"
      },
      "package": {
        "ecosystem": "Go",
        "name": "github.com/consensys/gnark"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.11.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-45039"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-06T19:53:20Z",
    "nvd_published_at": "2024-09-06T13:15:04Z",
    "severity": "MODERATE"
  },
  "details": "### Description\n\nThe 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 \u03c3 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.\n\nIn more detail:\nTo simplify notation, let us consider the case of two commitments, each to only a single variable. Let\u0027s 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 `\u03c3*K_0` and `\u03c3*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\n`D_0 = a*K_0`\n`D_1 = b*K_1`\nOut of the two D\u0027s, a challenge r for the commitment folding will be generated. The folded commitment will then be\n`D_folded = D_0 + r*D_1 = a*K_0 + r*b*K_1`\nThe honest prover will supply a fitting proof of knowledge\n`P = a*(\u03c3*K_0) + r*b*(\u03c3*K_1)`\n\nNow the verifier will only use all of this in two ways:\n1. In the check of the Groth16 proof itself, where only the sum `D_0 + D_1` is used.\n2. In the proof of knowledge check, where it will be verified that P is indeed `\u03c3*(D_0 + r*D_1)`, with r calculated from `D_0` and `D_1` as before.\n\nThis has the following implications. In the following, a malicious prover\u0027s points will have an apostrophe appended, and we keep `D_0` etc. for the legitimate values:\n1. A malicious prover is only forced to provide `D\u0027_0` and `D\u0027_1` such that the sum is correct. So they can use arbitrary `D\u0027_0` as long as they set `D\u0027_1 = D_0 + D_1 - D\u0027_0`.\n2. After choosing `D\u0027_0` and `D\u0027_1`, the prover can always calculate r. Evaluating `\u03c3*(D\u0027_0 + r*D\u0027_1)` is then possible as long as both `D\u0027_0` and `D\u0027_1` are linear combinations of basis elements for which \u03c3 times that basis element is known. In particular, this works as long as `D\u0027_0` and `D\u0027_1` are linear combinations of `K_0` and `K_1`.\n\nThe upshot is that a malicious prover can choose arbitrary a\u0027 and b\u0027, and then set\n`D\u0027_0 = a\u0027*K_0 + b\u0027*K_1`\n`D\u0027_1 = (a - a\u0027)*K_0 + (b - b\u0027)*K_1`\nThen they calculate r for this, and set\n`P = (a\u0027 + r*(a-a\u0027))*(\u03c3*K_0) + (b\u0027 + r*(b-b\u0027))*(\u03c3*K_1)`\nThis will then be accepted as a valid proof. Yet the first commitment point can be chosen completely independently of a and b, so in particular the malicious prover can use a constant for this, so that they will know the in-circuit challenge that will be added to the public inputs before they have to choose the witness assignments. For most use cases of such challenges (for proving things with Fiat-Shamir, random linear combinations etc.) this causes a critical soundness problem.\n\nThe problem generalizes to more than two commitments and commitments to more than one circuit variable each; one can freely choose all but one commitment as arbitrary linear combinations of the basis elements for all commitments, and then must choose the one remaining commitment in such a way that the sum is correct.\n\nThe root cause of the issue is that the \u03c3 used for the proofs of knowledge is the same, allowing to mix between the basis elements, as one has \u03c3 times them available for all of them.\nSo the fix is to have a separate \u03c3 for each commitment. So in our example above, the proving key would have the basis elements `K_0` and `K_1`, and for the proofs of knowledge now `\u03c3_0*K_0` and `\u03c3_1*K_1`. Folding the commitments would not be possible in the same way now, so the verifier will have to do more pairings. The prover could still provide a folded proof of knowledge however. With\n`D_0 = a*K_0`\n`D_1 = b*K_1`\nthe proof of knowledge would be\n`P = a*(\u03c3_0*K_0) + r*b*(\u03c3_1*K_1)`\nFor later, let us use notation for the unfolded proofs of knowledge\n`P_0 = a*(\u03c3_0*K_0)`\n`P_1 = b*(\u03c3_1*K_1)`\nso that\n`P = P_0 + r*P_1`\n\nThe verifying key would need `G` and `\u03c3_0*G` and `\u03c3_1*G`. To check the two unfolded proofs of knowledge would be the checks\n`e(P_0, G) = e(D_0, \u03c3_0*G)`\n`e(P_1, G) = e(D_1, \u03c3_1*G)`\nAs r is a challenge derived from D_0 and D_1, we may instead check\n`e(P_0, G) + r*e(P_1, G) = e(D_0, \u03c3_0*G) + r*e(D_1, \u03c3_1*G)`\nThe left hand side is\n`e(P_0, G) + r*e(P_1, G) = e(P_0 + r*P_1, G) = e(P, G)`\nSo the prover can just provide P and then the verifier checks\n`e(P, G) = e(D_0, \u03c3_0*G) + r*e(D_1, \u03c3_1*G)`\nUnfortunately, the right hand side can\u0027t be folded as before, as there isn\u0027t a side of the pairing that is kept constant between the pairings as before. So the verifier will need to have a pairing for each commitment on the right hand side.\n\n### Impact\n\nIt is a soundness issue - in case of multiple commitments used inside the circuit the prover is able to choose all but the last commitment. As we use the commitments for optimized non-native multiplication, lookup checks etc. as random challenges, then it could impact the soundness of the whole circuit.\n\nHowever, 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. So we 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.\n\n### Patches\n\nThe issue has been patched in e7c66b000454f4d2a4ae48c005c34154d4cfc2a2\n\n### Workarounds\n\nThe recommendation has been to use only a single commitment and then derive in-circuit commitments as needed using [std/multicommit](https://pkg.go.dev/github.com/consensys/gnark/std/multicommit) package.\n\n### References\n\nSee the correspondence above.\n",
  "id": "GHSA-q3hw-3gm4-w5cr",
  "modified": "2024-11-20T19:26:02Z",
  "published": "2024-09-06T19:53:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Consensys/gnark/security/advisories/GHSA-q3hw-3gm4-w5cr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45039"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Consensys/gnark/commit/e7c66b000454f4d2a4ae48c005c34154d4cfc2a2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Consensys/gnark"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2024-3122"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "gnark\u0027s Groth16 commitment extension unsound for more than one commitment"
}

OPENSUSE-SU-2024:14599-1

Vulnerability from csaf_opensuse - Published: 2024-12-18 00:00 - Updated: 2026-09-20 21:22

Summary

govulncheck-vulndb-0.0.20241213T205935-1.1 on GA media

Severity

Moderate

Scope

21 vulnerabilities in this advisory, including CVE-2024-45039.

CVE-2024-45039

6.2 (Medium)


                
                  CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N

Recommended: 4 products

Open the full advisory

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

CVE-2024-45039 (GCVE-0-2024-45039)

FKIE_CVE-2024-45039

GHSA-Q3HW-3GM4-W5CR

Description

Impact

Patches

Workarounds

References

OPENSUSE-SU-2024:14599-1

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour