Os 3 Principais Incidentes de Segurança de Junho
Os três maiores incidentes de junho não tiveram origem em um único bug. Eles expuseram uma falha comum. Na superfície, uma garantia de segurança parecia intacta, mas por baixo ela nunca foi de fato aplicada. Um bot de MEV confiou em negociações que pareciam lucrativas sem confirmar que as permissões foram realmente consumidas. Dois rollups desativados aceitaram provas válidas em forma, mas que nunca estiveram vinculadas ao estado de liquidação que afirmavam representar. O código de assinatura de uma carteira descartou silenciosamente o único input secreto do qual sua segurança dependia, transformando um valor que deveria ser imprevisível em algo que qualquer pessoa poderia recalcular a partir de dados públicos. Nenhum desses sistemas foi comprometido por criptoanálise de força bruta. Eles foram comprometidos por uma suposição que ninguém jamais verificou.
JaredFromSubway: ~$15M
Em 20 de junho de 2026, JaredFromSubway, um operador de bot de MEV no Ethereum, foi drenado em aproximadamente $15M em um ataque de honeypot.
O atacante construiu um ambiente de negociação falso com tokens wrapper falsos e pools falsos no estilo Uniswap V2 que emitem eventos Swap / Sync realistas. Em um fluxo legítimo, a função wrapTo() do contrato wrapper deveria internamente chamar transferFrom() no token real subjacente, consumindo a permissão que o bot havia concedido anteriormente. No entanto, o contrato de token wrapper falso pulou essa etapa completamente, enquanto ainda retornava um pequeno lucro criado pelo atacante por meio de unwrap(). Como o bot não verificou se as permissões foram realmente consumidas nem revogou as aprovações residuais, permissões não consumidas foram acumuladas e posteriormente coletadas por meio de withdraw(). Uma carteira afetada perdeu aproximadamente 1.474,58 WETH, 2.870.573 USDC e 2.035.760 USDT. JaredFromSubway reportou posteriormente uma perda total de aproximadamente $15M entre as carteiras afetadas.
A lição é que bots de MEV precisam tratar código desconhecido de tokens e pools como hostil, mesmo quando as simulações parecem lucrativas. Estratégias automatizadas exigem listas de permissão rígidas para spenders, verificações de code-hash, verificação de permissões pós-negociação e limpeza de aprovações residuais.
Incidentes nos Rollups Legados da Aztec: ~$4,35M
Em junho de 2026, dois deployments legados separados da Aztec foram explorados, resultando juntos em aproximadamente $4,35M em perdas. Embora as causas raiz fossem diferentes, ambos os incidentes ocorreram na fronteira entre validade de prova e semântica de liquidação.
O primeiro incidente atingiu o RollupProcessorV3 do Aztec Connect em 14 de junho de 2026, causando aproximadamente $2,15M em perdas. O atacante definiu numTxs como 1 enquanto introduzia furtivamente um depósito real em um slot posterior decodificado, de modo que o caminho da prova creditava o valor internamente enquanto a lógica de liquidação L1 ignorava a invocação correspondente de decreasePendingDepositBalance(). O atacante então sacou o saldo sem lastro resultante por canais normais.
O segundo incidente atingiu um deployment separado legado de PrivateRollupBridge / RollupProcessor em 18 de junho de 2026, resultando em cerca de $2,2M em perdas. Esse deployment ainda expunha um caminho escapeHatch(bytes,bytes,bytes), e seu circuito nunca restringia a raiz de associação do join-split privado para corresponder ao oldDataRoot público consumido pelo L1. Isso permitiu ao atacante provar a propriedade de notas de alto valor em uma árvore privada falsa enquanto publicava o dataRoot real do L1 como raiz pública. O verificador aceitou a prova, e o contrato L1 executou o saque.
Juntos, esses incidentes mostram que a verificação de provas por si só não é suficiente. Cada valor que governa os limites de liquidação deve estar vinculado aos inputs públicos exatos que a prova verifica, e cada witness privada deve ser explicitamente restringida para corresponder ao estado público que a liquidação realmente consome.
SecondFi: ~$2,4M
Em 23 de junho de 2026, o SecondFi (anteriormente Yoroi), uma extensão de carteira para navegador desenvolvida pela EMURGO, divulgou uma falha crítica em sua implementação de assinatura Ed25519, afetando as versões v10.0.3 a v10.0.6.
O código vulnerável derivava o nonce de assinatura apenas a partir da mensagem pública da transação, omitindo um prefixo de nonce secreto obrigatório. Isso transformou a equação de assinatura em uma única incógnita, permitindo que qualquer pessoa recuperasse a chave privada de uma carteira diretamente de dados públicos on-chain. Dois atacantes exploraram a falha de forma independente, drenando aproximadamente $2,4M (16M ADA) de 374 carteiras antes que a EMURGO resgatasse outros 129M ADA.
A lição é que o código de assinatura de carteiras precisa do mesmo escrutínio que a criptografia em nível de protocolo. Omitir um único input secreto, mesmo que pareça menor, pode comprometer completamente chaves privadas; portanto, implementações personalizadas de Ed25519 devem passar por uma auditoria independente em vez de serem tratadas como uma biblioteca padrão.
Menção Honrosa: Bug de solidez do Zcash Orchard
Não entrou no ranking dos Top 3 porque nenhuma exploração foi confirmada, mas o bug de solidez do Zcash Orchard foi uma das divulgações mais significativas de junho. Divulgado publicamente em 4 de junho de 2026, o bug era uma restrição de igualdade ausente no circuito do pool protegido Orchard que poderia ter permitido que a mesma nota protegida produzisse diferentes nullifiers e fosse gasta mais de uma vez. A falha existia desde a ativação do Orchard em maio de 2022 e foi corrigida por meio da atualização de emergência NU6.2.
O incidente reafirma a lição mais profunda do caso Aztec. Em um sistema ZK, a segurança depende do que o circuito realmente restringe — não do que o protocolo ao redor assume que ele restringe.
Leia a análise do bug do Zcash Orchard
As informações acima são baseadas em dados até 00:00 UTC, 1º de julho de 2026.
Isso conclui o boletim de incidentes de segurança de fevereiro.
Saiba mais em nossa Biblioteca de Incidentes de Segurança.
Mantenha-se informado e mantenha-se seguro!
