L’exploit che colpisce il pool yETH di Yearn Finance rappresenta uno degli attacchi più efficienti nella storia della DeFi, dove un attaccante trasforma 16 wei in un furto da 8,25 milioni di euro sfruttando una vulnerabilità nello storage cached dei bilanci virtuali. Il rapporto di Check Point Research, pubblicato il 2 dicembre 2025, ricostruisce con precisione la sequenza tecnica che porta alla creazione di 235 settillion di token yETH, minati a partire da un deposito minimo considerato dal protocollo come un nuovo ciclo di liquidità. La falla si manifesta perché il pool non azzera correttamente i valori cached dopo un prelievo totale, generando bilanci fantasma che l’attaccante accumula attraverso cicli multi-transazione assistiti da flash loan. Il protocollo, basato su un design stableswap ponderato, interpreta erroneamente la situazione come stato iniziale e permette un mint anomalo che drena completamente gli asset sottostanti, tra cui WETH, rETH, wstETH, ETHx, cbETH, sfrxETH, apxETH, wOETH e mETH. L’operazione dura alcune ore il 30 novembre 2025, coinvolge interazioni con Balancer, Aave, Uniswap V3 e Tornado Cash e rivela criticità strutturali nella gestione dello stato nei protocolli complessi, dove ottimizzazioni del gas introducono debolezze non riconosciute dai test standard.
Cosa leggere
Vulnerabilità nello storage cached di yETH
La vulnerabilità nasce dal modo in cui il pool yETH implementa un modello stableswap ponderato ispirato a Balancer e Curve. Gli sviluppatori utilizzano bilanci virtuali calcolati come balance_i × rate_i / PRECISION, con i rate forniti da oracoli per gli asset LSD. Per ridurre il consumo di gas, il pool conserva questi valori nella struttura packed_vbs, caricandoli e aggiornandoli senza ricalcolarli ogni volta. Il problema risiede nel fatto che la funzione remove_liquidity decrementa questi valori, ma non li resetta esplicitamente a zero quando la total supply diventa zero dopo un drenaggio completo del pool. Il protocollo assume che supply zero coincida automaticamente con uno stato pristino, ma la cache contiene ancora residui generati da arrotondamenti e da calcoli precedenti. Questi residui diventano bilanci fantasma che non dovrebbero esistere e che l’attaccante interpreta come punto di leva.
Il flusso interno di add_liquidity legge il contenuto di packed_vbs all’interno della funzione _calc_vb_prod_sum e presume che per un primo deposito i valori siano pari a zero. Quando supply zero convive con valori cached non azzerati, l’algoritmo considera il deposito minimo come un nuovo ciclo iniziale, e genera token LP sulla base dei residui, non sui saldi reali. Questo meccanismo, combinato con rate variabili degli LSD come wstETH ≈ 1,15 ETH e rETH ≈ 1,08 ETH, amplifica ulteriormente l’effetto del bug. Il risultato è un mint sproporzionato, totalmente incoerente con il valore reale degli asset depositati.
Meccanismo dell’exploit passo per passo
L’attacco si basa sulla capacità di manipolare lo stato tramite cicli multipli di deposito e prelievo, finanziati tramite flash loan, senza necessità di capitale proprio. L’attaccante ottiene subito grandi quantità di WETH, wstETH, rETH, ETHx e cbETH attraverso prestiti flash da Balancer e Aave, così da poter avvelenare lo stato del pool. Con questi asset esegue una serie di cicli in cui deposita e preleva immediatamente liquidità, lasciando residui aritmetici nella cache packed_vbs. Ogni ciclo aumenta l’entità dei bilanci fantasma. Una volta terminata la fase di state poisoning, l’attaccante ritira tutta la liquidità e brucia gli LP token, azzerando la supply. A questo punto packed_vbs conserva però gran parte dei valori accumulati. L’attaccante quindi deposita 16 wei distribuiti su otto token diversi. Il protocollo interpreta questo passo come un deposito iniziale e, leggendo la cache stantia, minta 235 settillion di yETH, un valore astronomico a 41 cifre, completamente scollegato dalla quantità realmente depositata. Con questi token sintetici, l’attaccante effettua il passaggio successivo: scambia yETH con asset sottostanti tramite Balancer, ritira gli asset veri, li converte in ETH attraverso DEX come Uniswap V3 e ripaga i prestiti flash. Parte degli ETH rubati transita attraverso Tornado Cash, rendendo complesso il tracciamento on-chain. L’intera sequenza richiede il coordinamento di più contratti, un timing preciso e una conoscenza approfondita delle invarianti matematiche del sistema. L’uso ripetuto di flash loan consente inoltre di mantenere costi contenuti e massimizzare l’efficacia del bug, dimostrando come vulnerabilità apparentemente marginali possano avere effetti devastanti nei framework DeFi complessi.
Impatto finanziario e operativo dell’attacco
L’attacco provoca una perdita di 8,25 milioni di euro dal pool yETH, che viene completamente svuotato degli asset sottostanti. Gli utenti legittimi che detenevano quote del pool si ritrovano con LP token privi di valore, mentre Yearn Finance affronta un’improvvisa erosione della fiducia, dovuta alla natura del bug e alla facilità con cui la vulnerabilità può emergere in condizioni non comuni. L’inflazione estrema dei token yETH distrugge ogni relazione tra supply e valore reale, compromettendo la funzionalità del protocollo e imponendo l’interruzione immediata del pool. La conversione degli asset rubati in ETH influenza temporaneamente la liquidità degli LSD e produce oscillazioni sui tassi di cambio nei DEX coinvolti, dato il volume improvviso delle transazioni. Il lavaggio tramite Tornado Cash genera difficoltà aggiuntive per analisti e società di sicurezza nell’identificare i flussi post-attacco. L’impatto si estende anche sul piano operativo: Yearn deve sospendere il pool, analizzare il bug, proporre fix rapidi e rassicurare la community DeFi già scossa da precedenti attacchi simili. La vicenda mette in evidenza quanto la gestione dello stato, soprattutto in protocolli multi-asset, sia determinante per prevenire exploit complessi. La rete Ethereum registra un numero elevato di transazioni correlate alla sequenza dell’attacco, con costi di gas significativi. Gli auditor e gli sviluppatori iniziano rapidamente un’analisi comparata di protocolli con logiche simili, poiché l’incidente suggerisce che vulnerabilità legate a caching, arrotondamenti e mancate inizializzazioni potrebbero essere più diffuse di quanto apparisse in precedenza. A lungo termine, l’attacco spinge l’intero ecosistema a rivalutare l’adozione di meccanismi di sicurezza preventiva, soprattutto per quanto riguarda i reset espliciti dello stato.
Sistemi e asset colpiti dall’exploit
L’attacco coinvolge direttamente il pool yETH, il suo token LP e l’intera struttura di gestione dei bilanci virtuali. Gli asset LSD utilizzati nel pool includono WETH, sfrxETH, wstETH, ETHx, cbETH, rETH, apxETH, wOETH e mETH, ciascuno con un proprio tasso di conversione fornito da rate provider esterni. Gli oracoli non risultano compromessi, poiché l’exploit riguarda unicamente la logica interna del pool e la gestione dello storage. I protocolli esterni coinvolti risultano essenziali per l’esecuzione del piano. I flash loan provengono da Balancer e Aave, mentre gli swap avvengono su Balancer e Uniswap V3. I fondi vengono poi trasferiti su Tornado Cash per completare la fase di offuscamento. Nessun layer 2 viene coinvolto e il problema rimane confinato alla Ethereum mainnet, dove la complessità delle interazioni amplifica l’esposizione del sistema a comportamenti non previsti. La combinazione di asset LSD, rate dinamici, caching ottimizzato, strutture packed e invarianti complesse rende il pool yETH particolarmente sensibile a errori di gestione dello stato. Le funzioni chiave del contratto, tra cui _calc_vb_prod_sum, remove_liquidity e add_liquidity, risultano al centro dell’analisi post-attacco, poiché la loro interazione rivela un percorso non previsto dagli sviluppatori ma sfruttabile da chi dispone della capacità di modellare l’evoluzione dello stato su più transazioni.
Dettagli tecnici e cause radice
La radice del problema risiede nell’assunzione implicita che supply zero equivalga sempre a cache zero, una condizione che non viene verificata a runtime. L’omissione di un reset esplicito nella funzione remove_liquidity genera una discrepanza logica tra lo stato reale del pool e quello percepito dal meccanismo di mint. Le oltre mille linee di codice del contratto, unite alle ottimizzazioni gas-oriented, creano uno scenario in cui gli sviluppatori testano principalmente i percorsi standard, trascurando edge case come la sequenza di prelievi totali ripetuti. Il layout della memoria utilizza vettori packed, dove i valori virtuali vengono compressi per minimizzare lo spazio occupato. Questo design, vantaggioso in condizioni normali, amplifica però il rischio quando i valori non vengono inizializzati o azzerati correttamente. L’attaccante sfrutta esattamente questa mancanza di coerenza interna, costruendo un percorso transazionale che alimenta progressivamente i residui in packed_vbs fino a ottenere un vantaggio sufficiente per generare una quantità sproporzionata di token. Gli sviluppatori identificano la falla come state management flaw, una tipologia di errore comune in protocolli avanzati. L’interazione tra asset multipli, oracoli esterni e funzioni multi-transazione crea un ambiente in cui le assunzioni implicite diventano vulnerabilità. Un’analisi più accurata rivela come il minting anomalo sia una conseguenza diretta della lettura non validata della cache. In presenza di supply zero, il contratto avrebbe dovuto confrontare lo stato attuale con i valori cached o eseguire un reset automatico degli stessi.
Misure di mitigazione e fix proposti
Le misure proposte dagli sviluppatori prevedono l’introduzione di un reset esplicito della struttura packed_vbs quando la supply raggiunge zero, impedendo l’accumulo di valori non autorizzati. Viene proposta anche una validazione runtime all’interno di add_liquidity, che verifica la coerenza della cache in caso di depositi minimi e blocca l’esecuzione quando emergono anomalie. Sviluppatori e auditor concordano sulla necessità di simulazioni complete dei cicli multi-transazione, soprattutto in protocolli che integrano funzioni di caching e ottimizzazioni. La comunità governance spinge per aggiornamenti rapidi del pool yETH e per un rafforzamento delle misure di sicurezza anche in protocolli simili. Viene considerata essenziale l’introduzione di controlli pre-esecuzione che intercettano comportamenti anomali, come minting eccessivo o accumuli non lineari di bilanci virtuali. I test futuri dovranno includere scenari di prelievo totale e cicli ripetuti, così da anticipare eventuali punti di rottura.
