{"id":"GHSA-7p92-x423-vwj6","aliases":["GO-2023-2119"],"status":"published","title":"Plonk verifier KZG multi point verification","description":"### Impact\n\nThe vulnerability allows a third party to derive a valid proof from a valid initial tuple {proof, public_inputs}, corresponding to the same public inputs as the initial proof. It is due to a randomness being generated using a small part of the scratch memory describing the state, allowing for degrees of freedom in the transcript.\n\nNote that the impact is limited to the PlonK verifier smart contract.\n\n### Patches\n\nWe still use a hash function on some data to have a pseudo rng, but instead of hashing the first 32 bytes of the state (\n` let random := mod(keccak256(state, 0x20), r_mod)` )\n\nwe hash the whole state at this point of the verifier as if it was a Fiat Shamir transcript:\n```\n        mstore(mPtr, mload(add(state, STATE_FOLDED_DIGESTS_X)))\n        mstore(add(mPtr, 0x20), mload(add(state, STATE_FOLDED_DIGESTS_Y)))\n        mstore(add(mPtr, 0x40), calldataload(add(aproof, PROOF_BATCH_OPENING_AT_ZETA_X)))\n        mstore(add(mPtr, 0x60), calldataload(add(aproof, PROOF_BATCH_OPENING_AT_ZETA_Y)))\n        mstore(add(mPtr, 0x80), calldataload(add(aproof, PROOF_GRAND_PRODUCT_COMMITMENT_X)))\n        mstore(add(mPtr, 0xa0), calldataload(add(aproof, PROOF_GRAND_PRODUCT_COMMITMENT_Y)))\n        mstore(add(mPtr, 0xc0), calldataload(add(aproof, PROOF_OPENING_AT_ZETA_OMEGA_X)))\n        mstore(add(mPtr, 0xe0), calldataload(add(aproof, PROOF_OPENING_AT_ZETA_OMEGA_Y)))\n        mstore(add(mPtr, 0x100), mload(add(state, STATE_ZETA)))\n        mstore(add(mPtr, 0x120), mload(add(state, STATE_GAMMA_KZG)))\n        let random := staticcall(gas(), 0x2, mPtr, 0x140, mPtr, 0x20)\n```\n\n### Workarounds\n\nIn the function `batch_verify_multi_points`, the variable `random` (corresponding to `u` in the paper, step 12 of the [plonk](https://eprint.iacr.org/2019/953.pdf) verification process) should depend on `state_folded_digests_x`, `state_folded_digests_y`, `proof_grand_product_commitment_x`, `proof_grand_product_commitment_y` and `state_zeta` (by hashing those values for instance).","facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"published":"2023-10-17T14:24:16Z","modified":"2024-05-20T16:03:47Z","fixes":[{"ecosystem":"Go","package":"github.com/consensys/gnark","fixed_in":["0.9.1"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Go","package":"github.com/consensys/gnark","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0.9.1"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/consensys/gnark","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.9.1"}]}]},{"source":"osv","ecosystem":"Go","package":"github.com/consensys/gnark","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"0.9.1"}]}]}],"references":[{"url":"https://github.com/Consensys/gnark/security/advisories/GHSA-7p92-x423-vwj6","tags":["web","advisory"]},{"url":"https://github.com/Consensys/gnark/commit/3421eaa7d544286abf3de8c46282b8d4da6d5da0","tags":["web","fix"]},{"url":"https://github.com/advisories/GHSA-7p92-x423-vwj6"},{"url":"https://github.com/Consensys/gnark","tags":["package"]}],"sources":{"ghsa":[{"id":"GHSA-7p92-x423-vwj6","title":"Plonk verifier KZG multi point verification","description":"### Impact\n\nThe vulnerability allows a third party to derive a valid proof from a valid initial tuple {proof, public_inputs}, corresponding to the same public inputs as the initial proof. It is due to a randomness being generated using a small part of the scratch memory describing the state, allowing for degrees of freedom in the transcript.\n\nNote that the impact is limited to the PlonK verifier smart contract.\n\n### Patches\n\nWe still use a hash function on some data to have a pseudo rng, but instead of hashing the first 32 bytes of the state (\n` let random := mod(keccak256(state, 0x20), r_mod)` )\n\nwe hash the whole state at this point of the verifier as if it was a Fiat Shamir transcript:\n```\n        mstore(mPtr, mload(add(state, STATE_FOLDED_DIGESTS_X)))\n        mstore(add(mPtr, 0x20), mload(add(state, STATE_FOLDED_DIGESTS_Y)))\n        mstore(add(mPtr, 0x40), calldataload(add(aproof, PROOF_BATCH_OPENING_AT_ZETA_X)))\n        mstore(add(mPtr, 0x60), calldataload(add(aproof, PROOF_BATCH_OPENING_AT_ZETA_Y)))\n        mstore(add(mPtr, 0x80), calldataload(add(aproof, PROOF_GRAND_PRODUCT_COMMITMENT_X)))\n        mstore(add(mPtr, 0xa0), calldataload(add(aproof, PROOF_GRAND_PRODUCT_COMMITMENT_Y)))\n        mstore(add(mPtr, 0xc0), calldataload(add(aproof, PROOF_OPENING_AT_ZETA_OMEGA_X)))\n        mstore(add(mPtr, 0xe0), calldataload(add(aproof, PROOF_OPENING_AT_ZETA_OMEGA_Y)))\n        mstore(add(mPtr, 0x100), mload(add(state, STATE_ZETA)))\n        mstore(add(mPtr, 0x120), mload(add(state, STATE_GAMMA_KZG)))\n        let random := staticcall(gas(), 0x2, mPtr, 0x140, mPtr, 0x20)\n```\n\n### Workarounds\n\nIn the function `batch_verify_multi_points`, the variable `random` (corresponding to `u` in the paper, step 12 of the [plonk](https://eprint.iacr.org/2019/953.pdf) verification process) should depend on `state_folded_digests_x`, `state_folded_digests_y`, `proof_grand_product_commitment_x`, `proof_grand_product_commitment_y` and `state_zeta` (by hashing those values for instance).\n","status":"published","published":"2023-10-17T14:24:16Z","modified":"2024-01-26T16:17:15Z","updated_at":"2026-11-02T14:37:33.019154Z"}],"osv":[{"id":"GHSA-7p92-x423-vwj6","title":"Plonk verifier KZG multi point verification","description":"### Impact\n\nThe vulnerability allows a third party to derive a valid proof from a valid initial tuple {proof, public_inputs}, corresponding to the same public inputs as the initial proof. It is due to a randomness being generated using a small part of the scratch memory describing the state, allowing for degrees of freedom in the transcript.\n\nNote that the impact is limited to the PlonK verifier smart contract.\n\n### Patches\n\nWe still use a hash function on some data to have a pseudo rng, but instead of hashing the first 32 bytes of the state (\n` let random := mod(keccak256(state, 0x20), r_mod)` )\n\nwe hash the whole state at this point of the verifier as if it was a Fiat Shamir transcript:\n```\n        mstore(mPtr, mload(add(state, STATE_FOLDED_DIGESTS_X)))\n        mstore(add(mPtr, 0x20), mload(add(state, STATE_FOLDED_DIGESTS_Y)))\n        mstore(add(mPtr, 0x40), calldataload(add(aproof, PROOF_BATCH_OPENING_AT_ZETA_X)))\n        mstore(add(mPtr, 0x60), calldataload(add(aproof, PROOF_BATCH_OPENING_AT_ZETA_Y)))\n        mstore(add(mPtr, 0x80), calldataload(add(aproof, PROOF_GRAND_PRODUCT_COMMITMENT_X)))\n        mstore(add(mPtr, 0xa0), calldataload(add(aproof, PROOF_GRAND_PRODUCT_COMMITMENT_Y)))\n        mstore(add(mPtr, 0xc0), calldataload(add(aproof, PROOF_OPENING_AT_ZETA_OMEGA_X)))\n        mstore(add(mPtr, 0xe0), calldataload(add(aproof, PROOF_OPENING_AT_ZETA_OMEGA_Y)))\n        mstore(add(mPtr, 0x100), mload(add(state, STATE_ZETA)))\n        mstore(add(mPtr, 0x120), mload(add(state, STATE_GAMMA_KZG)))\n        let random := staticcall(gas(), 0x2, mPtr, 0x140, mPtr, 0x20)\n```\n\n### Workarounds\n\nIn the function `batch_verify_multi_points`, the variable `random` (corresponding to `u` in the paper, step 12 of the [plonk](https://eprint.iacr.org/2019/953.pdf) verification process) should depend on `state_folded_digests_x`, `state_folded_digests_y`, `proof_grand_product_commitment_x`, `proof_grand_product_commitment_y` and `state_zeta` (by hashing those values for instance).\n","status":"published","published":"2023-10-17T14:24:16Z","modified":"2023-11-08T04:16:55.230519Z","updated_at":"2026-11-02T15:46:41.349637Z"},{"id":"GO-2023-2119","title":"Proof forgery due to insufficient randomness in github.com/consensys/gnark","description":"A a third party may derive a valid proof from a valid initial tuple {proof, public_inputs}, corresponding to the same public inputs as the initial proof. This vulnerability is due to randomness being generated using a small part of the scratch memory describing the state, allowing for degrees of freedom in the transcript. Note that the impact is limited to the PlonK verifier smart contract.","status":"published","published":"2023-10-24T20:27:47Z","modified":"2024-05-20T16:03:47Z","updated_at":"2026-11-02T15:47:01.185262Z"}]}}