GHSA-7P92-X423-VWJ6

Plonk verifier KZG multi point verification

Workarounds

In the function batch_verify_multi_points, the variable random (corresponding to u in the paper, step 12 of the plonk 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).

The 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.

Note that the impact is limited to the PlonK verifier smart contract.

Kodem intelligence

Already deployed Kodem?

We still use a hash function on some data to have a pseudo rng, but instead of hashing the first 32 bytes of the state (
let random := mod(keccak256(state, 0x20), r_mod) )

we hash the whole state at this point of the verifier as if it was a Fiat Shamir transcript:

        mstore(mPtr, mload(add(state, STATE_FOLDED_DIGESTS_X)))
        mstore(add(mPtr, 0x20), mload(add(state, STATE_FOLDED_DIGESTS_Y)))
        mstore(add(mPtr, 0x40), calldataload(add(aproof, PROOF_BATCH_OPENING_AT_ZETA_X)))
        mstore(add(mPtr, 0x60), calldataload(add(aproof, PROOF_BATCH_OPENING_AT_ZETA_Y)))
        mstore(add(mPtr, 0x80), calldataload(add(aproof, PROOF_GRAND_PRODUCT_COMMITMENT_X)))
        mstore(add(mPtr, 0xa0), calldataload(add(aproof, PROOF_GRAND_PRODUCT_COMMITMENT_Y)))
        mstore(add(mPtr, 0xc0), calldataload(add(aproof, PROOF_OPENING_AT_ZETA_OMEGA_X)))
        mstore(add(mPtr, 0xe0), calldataload(add(aproof, PROOF_OPENING_AT_ZETA_OMEGA_Y)))
        mstore(add(mPtr, 0x100), mload(add(state, STATE_ZETA)))
        mstore(add(mPtr, 0x120), mload(add(state, STATE_GAMMA_KZG)))
        let random := staticcall(gas(), 0x2, mPtr, 0x140, mPtr, 0x20)

1. What is GHSA-7P92-X423-VWJ6? GHSA-7P92-X423-VWJ6 is a critical-severity security vulnerability in github.com/consensys/gnark (go), affecting versions < 0.9.1. It is fixed in 0.9.1.
2. Which versions of github.com/consensys/gnark are affected by GHSA-7P92-X423-VWJ6? github.com/consensys/gnark (go) versions < 0.9.1 is affected.
3. Is there a fix for GHSA-7P92-X423-VWJ6? Yes. GHSA-7P92-X423-VWJ6 is fixed in 0.9.1. Upgrade to this version or later.
4. Is GHSA-7P92-X423-VWJ6 exploitable, and should I be worried? Whether GHSA-7P92-X423-VWJ6 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether GHSA-7P92-X423-VWJ6 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix GHSA-7P92-X423-VWJ6? Upgrade github.com/consensys/gnark to 0.9.1 or later.

Other vulnerabilities in github.com/consensys/gnark