CVE-2026-48100 in Payy
Sumário
de VulDB • 28/09/2026
Payy é um zk-rollup de camada 2 (L2) para Ethereum voltado à preservação da privacidade e ao cumprimento das normas regulatórias nas transações. Antes da versão 1.3.0, a função `agg_agg` encaminha o fluxo de mensagens compactadas dos seus proofs internos para uma array pública do tipo `[Field; 1000]`, mas nunca verifica se a parte não utilizada (o "tail") da array externa é zero. Um prover registrado pode construir um proof válido de `agg_final` para um bloco rollup aprovado, inserindo uma mensagem extra de queima ("burn message") após as mensagens reais. A função `RollupV1.verifyRollup()` então analisa esse input público como uma queima normal e transfere USDC do contrato do rollup para o atacante.
Trata-se de uma falha grave na integridade (soundness) do circuito: o sistema de provas aceita um enunciado público cuja array de mensagens não é totalmente derivada dos proofs internos verificados. Na implantação atual, `verifyRollup()` está restrito ao prover já incluído na lista permitida (allowlisted), portanto, um chamador público novo não pode submeter a prova inválida diretamente. Essa restrição limita quem pode atingir o L1 hoje; no entanto, ela não torna o enunciado do circuito correto (sound). O problema torna-se sem permissão (permissionless) sob o modelo de prover descrito na whitepaper da Payy. A Seção 3.3.2 afirma: "Para se juntar como um prover, é necessário que este submeta uma pequena stake", e a Seção 3.3.1 estabelece que, caso um prover falhe em submeter, "outros nós podem submeter o proof do bloco em seu lugar". Nesse modelo, um atacante precisa apenas tornar-se um prover registrado e usar os dados de aprovação dos validadores públicos para um bloco já aprovado. Esta questão foi corrigida na versão 1.3.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.