Attacco Balancer V2: drenati 118 milioni di euro con errore di arrotondamento. Cosa è successo?

di Redazione
0 commenti

Un sofisticato attacco contro Balancer V2 ha permesso a un attore malevolo di drenare 118 milioni di euro in meno di 30 minuti, sfruttando una vulnerabilità di arrotondamento aritmetico nei contratti ComposableStablePool. L’incidente, rilevato dai sistemi di Check Point Research il 3 novembre 2025, coinvolge sei blockchain e rappresenta uno dei più gravi exploit matematici mai registrati nel settore DeFi, dimostrando come anche errori minimi nella gestione delle precisioni possano generare impatti devastanti.

Architettura Balancer V2 e origine della vulnerabilità

Il framework Balancer V2 si basa su un Vault centralizzato che gestisce tutti i token depositati, separando la logica dei pool dallo storage. Questa architettura riduce i costi di gas e aumenta l’efficienza del capitale, ma concentra anche il rischio: una singola vulnerabilità può compromettere l’intero sistema.

image 115
Attacco Balancer V2: drenati 118 milioni di euro con errore di arrotondamento. Cosa è successo? 7

Il contratto Vault (indirizzo 0xBA12222222228d8Ba445958a75a0704d566BF2C8) coordina il bilancio interno degli utenti attraverso la mappatura _internalTokenBalance, che consente transazioni multiple senza trasferimenti ERC20 esterni. L’attaccante ha sfruttato proprio questa struttura per accumulare fondi nel bilancio interno del Vault, poi estratti in un secondo momento verso un indirizzo controllato. Il difetto principale risiede nella funzione _upscaleArray, utilizzata per scalare i bilanci dei token prima del calcolo dell’invariante del pool. Questa funzione impiega la moltiplicazione FixedPoint.mulDown, che arrotonda sempre verso il basso, generando perdite di precisione proporzionali al numero di operazioni. Con bilanci estremamente piccoli — nell’ordine di 8-9 wei — l’errore relativo può superare il 10%. Il design dei ComposableStablePools, basato sulla formula StableSwap di Curve, amplifica queste discrepanze. Ogni calcolo invariante dipende da valori scalati: quando questi vengono sottostimati, il prezzo dei token BPT risulta artificiosamente ridotto, aprendo spazio per cicli di arbitraggio ripetuti che generano profitti netti per l’attaccante.

Meccanismo dell’exploit: precisione manipolata e cicli atomici

L’attacco si articola in tre fasi atomiche, tutte racchiuse in transazioni batchSwap eseguite in un unico costruttore di contratto: Nella fase uno, l’attaccante porta i bilanci di alcuni token ai limiti di precisione, regolando manualmente le quantità per raggiungere le soglie critiche di 8-9 wei. In questa condizione, anche un piccolo errore di arrotondamento diventa significativo. Durante la fase due, vengono eseguiti micro-swap iterativi — oltre 65 operazioni consecutive — che amplificano la perdita di precisione. Ogni swap induce un lieve calo nell’invariante D, determinando una sottostima cumulativa del valore del pool e quindi un prezzo BPT più basso. Infine, nella fase tre, l’attaccante acquista BPT a prezzi artificialmente depressi, per poi riscattarli immediatamente contro gli asset sottostanti a valore pieno. Questa sequenza di mint e redeem genera profitti puri e ripetibili finché i bilanci restano in stato di errore. La natura atomica dell’operazione — eseguita all’interno di un’unica transazione non interrompibile — ha impedito qualsiasi intervento di mitigazione in tempo reale. Gli effetti si sono accumulati nello stato condiviso del Vault, causando perdite su più pool simultaneamente.

Architettura del contratto di attacco

Il contratto exploit, distribuito dall’indirizzo 0x506D1f9EFe24f0d47853aDca907EB8d89AE03207, contiene la logica completa dell’attacco all’interno del costruttore. Il codice principale è stato deploiato su 0x54B53503c0e2173Df29f8da735fBd45Ee8aBa30d, con un terzo indirizzo, 0xAa760D53541d8390074c61DEFeaba314675b8e3f, designato per il ritiro dei fondi. Durante il deployment, il contratto esegue batchSwap multipli su due pool principali (osETH/wETH-BPT e wstETH-WETH-BPT), rubando circa 58 milioni di euro in una prima fase. Gli eventi InternalBalanceChanged registrano incrementi precisi nei bilanci interni: +4,623 WETH, +6,851 osETH e +4,259 wstETH, che vengono poi consolidati e ritirati con una successiva chiamata alla funzione 0x8a4f75d6. Questa funzione interagisce direttamente con il Vault tramite manageUserBalance, richiedendo trasferimenti verso l’indirizzo dell’exploiter 2. Poiché il Vault riconosce il contratto exploit come legittimo titolare dei fondi interni, i trasferimenti risultano validi e non vengono bloccati da alcuna regola di sicurezza.

Vulnerabilità matematica e amplificazione dell’errore

Il cuore dell’exploit è un problema di perdita di precisione aritmetica nei calcoli a virgola fissa di Solidity. La funzione FixedPoint.mulDown riduce il risultato di ogni moltiplicazione al numero intero inferiore, un comportamento generalmente innocuo che diventa critico quando i valori sono molto piccoli e vengono ripetuti in loop. Gli effetti cumulativi di questi arrotondamenti, normalmente invisibili in transazioni singole, si sommano in operazioni batch atomiche, generando disallineamenti significativi nei parametri invarianti. Poiché Balancer non implementava controlli di validazione sugli scostamenti del valore D dopo operazioni multiple, l’attaccante ha potuto sfruttare il meccanismo senza ostacoli. In pratica, la matematica interna del protocollo è stata weaponizzata: un errore marginale, moltiplicato per decine di iterazioni, ha prodotto una distorsione abbastanza grande da alterare la logica economica dei pool e consentire l’estrazione di valore diretto.

Analisi tecnica e pattern dell’attacco

L’indagine di Check Point Research individua un pattern coerente tra le due transazioni principali. La prima, 0x6ed07db1a9fe5c0794d44cd36081d6a6df103fab868cdd75d581e3bd23bc9742, riguarda il deployment e il drenaggio iniziale. La seconda, 0xd155207261712c35fa3d472ed1e51bfcd816e616dd4f517fa5959836f5b48569, effettua il ritiro finale. Il contratto sfrutta eventi di fee decrescenti — da 0,414 osETH a valori prossimi allo zero — come traccia numerica del compounding degli errori. I trasferimenti generati dal costruttore e registrati nel Protocol Fees Collector evidenziano un ciclo iterativo sistematico, confermando che l’attacco è stato automatizzato e parametrizzato per massimizzare l’efficienza. La precisione dei calcoli, unita all’uso di operazioni atomiche, indica un alto livello di competenza tecnica. L’attacco ha colpito sei reti blockchain, sfruttando la natura cross-chain del Vault e dimostrando come la condivisione dello stato tra pool possa diventare un moltiplicatore di vulnerabilità.

Implicazioni per la sicurezza DeFi

L’exploit di Balancer evidenzia una nuova frontiera della minaccia DeFi: la manipolazione economico-matematica dei protocolli. A differenza di bug di sicurezza classici, questi attacchi sfruttano proprietà numeriche e comportamenti marginali del linguaggio Solidity per generare vantaggi finanziari sistematici. Gli audit tradizionali si concentrano su vulnerabilità logiche o accessi non autorizzati, ma spesso ignorano gli effetti cumulativi di operazioni batch. L’evento del 3 novembre spinge il settore a considerare nuovi approcci, come le modellazioni economiche adversariali, i test di precisione a livello invarianti e le validazioni continue on-chain. Balancer ha già annunciato piani di aggiornamento per introdurre safeguard di arrotondamento e controlli di overflow nei contratti V2. Altri protocolli basati su StableSwap stanno rivalutando i propri modelli matematici per prevenire casi simili. Check Point Research raccomanda l’adozione di sistemi di monitoraggio comportamentale in tempo reale e la collaborazione tra progetti per identificare pattern di exploit. L’incidente dimostra che anche la più piccola perdita di precisione può trasformarsi, in contesti DeFi ad alta automazione, in un meccanismo di drenaggio sistemico.