← Back to the live CVE advisory feed

CVE-2026-48100: Product identification pending

Severity

8.7 (HIGH)

Affected versions

Before 1.3.0

Fixed version

1.3.0.

Patch status

Patched

Published

2026-09-28T17:17:49.547

Modified

2026-09-28T18:17:22.120

Why it matters

High-severity vulnerability requiring prioritized review.

Recommended admin actions

• Review and patch based on exposure, asset criticality, and business impact.
• Compare installed versions against the affected version range in the advisory.

Technical summary

Payy is an Ethereum L2 zk-rollup for privacy preserving and regulatory compliant transactions. Prior to version 1.3.0, agg_agg 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 agg_final 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.

View the official NVD record for CVE-2026-48100

CVE data is sourced from NVD/CNA records and optional enrichment. Validate against the vendor advisory before taking production action.