CVE-2026-48100: Payy: agg_agg trailing message slots are unconstrained and allow forged burn messages
Payy is an Ethereum L2 zk-rollup for privacy preserving and regulatory compliant transactions. Prior to version 1.3.0, aggagg forwards the compacted message stream from its inner proofs into a public messages: [Field; 1000] array, but it never checks that the unused tail of the outer array is zero. A registered prover can build a valid aggfinal proof for an approved rollup block while inserting an extra burn message after the real messages. RollupV1.verifyRollup() then parses that public input as a normal burn and transfers USDC from the rollup contract to the attacker. This is a severe circuit soundness failure: the proof system accepts a public statement whose messages array is not fully derived from the verified inner proofs. On the current deployment, verifyRollup() is restricted to the existing allowlisted prover, so a fresh public caller cannot submit the invalid proof directly. That gate limits who can reach L1 today; it does not make the circuit statement sound. The issue becomes permissionless under the prover model described in the Payy whitepaper. Section 3.3.2 states: "To join as a prover, the prover is required to submit a small stake", and Section 3.3.1 states that if a prover fails to submit, "other nodes can submit the block proof instead." In that model, an attacker only needs to become a registered prover and use public validator approval data for an already approved block. This issue has been patched in version 1.3.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Payy agg_aggto a version that resolves this vulnerability.Fixed in 1.3.0
Event History
Frequently Asked Questions
Which deployments should be considered affected?
Payy deployments running a version earlier than 1.3.0 are affected. The issue concerns the rollup proof verification path that processes the public messages array.
Can an arbitrary external account exploit the current deployment?
Not directly. RollupV1.verifyRollup() is restricted to the existing allowlisted prover, so a fresh public caller cannot submit the invalid proof to L1; however, this restriction does not correct the unsound circuit statement.
What access would an attacker need to turn this into a withdrawal?
On the current deployment, the attacker would need access to the existing allowlisted prover capability to submit the forged proof. Under the permissionless prover model described in the whitepaper, a prover can join by submitting a small stake, which would broaden the set of parties able to reach this path.
What is the potential impact if exploitation succeeds?
A valid-looking proof can contain an extra forged burn message after the legitimate messages. The rollup contract then interprets it as a normal burn and transfers USDC from the rollup contract to the attacker.