3 HACK in 5 mesi per questo protocollo DeFi: l’AI non basta ad evitare il disastro

Tripletta per Moonwell, piattaforma lending market del settore DeFi che in appena 5 mesi ha subito la bellezza di 3 hack, in tutti i casi per colpa di una gestione e configurazione errata dell’oracolo che fornisce i feed di prezzo. L’ultimo incidente è avvenuto il 15 febbraio ed ha portato alla perdita di $1,78 milioni attraverso la formazione di bad debt. 

La cosa più incredibile di questa storia è che nell’ultimo exploit l’errore che ha causato il problema nasce da un commit co-firmato da un assistente AI, cosa che ha fatto non poco discutere la community. In realtà però non è propriamente responsabilità dell’intelligenza artificiale, quanto più della mancanza di supervisione esterna e di protezioni contro possibili falle di questo tipo. Vediamo meglio cosa è successo.

Moonwell: ennesimo hack per il protocollo DeFI, formazione di bad debt

Moonwell è un classico money market DeFi, ossia una piattaforma che consente di prendere in prestito asset crypto in cambio di un collaterale fornito a garanzia delle operazioni. Tutti gli hack subiti dal progetto derivano dallaformazione di“bad debt”, ossia un debito causato da un mispricing interno degli asset forniti a liquidità e dal fatto che in un determinato momento qualcuno abbia potuto prendere in prestito più valore di quanto il collaterale depositato fosse realmente in grado di coprire. 

Si tratta di una delle maggiori vulnerabilità che i protocolli di lending devono affrontare, soprattutto in occasione di forte volatilità sui prezzi degli asset (evento che potrebbe scombussolare tutti i calcoli interni). L’intero sistema si basa infatti sull’affidabilità dei feed di prezzo utilizzati per valutare il collaterale e quanto debito possa essere generato sulla base della metrica LTV: se quel valore risulta errato, di conseguenza la piattaforma potrebbe erogare più credito del normale e causare grossi crediti inesigibili, ergo perdite per la piattaforma e per gli utenti.

Se volete approfondire questo argomento, vi consigliamo di guardare a come i maggiori protocolli DeFi si muovono in genere: qui spieghiamo come Aave si copre normalmente dal rischio di bad debt

3 hack in 5 mesi: errori di configurazione e risk management

Tutti e 3 gli hack subiti da Moonwell partono dallo stesso presupposto, ossia da un mispricing dell’oracolo che fornisce dati di prezzi al protocollo, il quale permesso di formare erroneamente bad debt. Nella pratica gli incidenti sono stati scatenati da diversi catalizzatori, in condizioni di mercato differenti, e resi possibili a causa di una pessima supervisione e di parametri di rischio inadeguati. In ogni caso, il protocollo ha bruciato milioni di dollari. Andando in ordine temporale

• 10 ottobre 2025: data che conosciamo tutti, in cui c’è stato un sell-off violentissimo su tutti i crypto asset, con una volatilità che ha mandato in tilt tanti sistemi di oracoli, tra cui anche quello utilizzato da Moonwell che forniva feed di token come AERO, VIRTUAL e MORPHO. L’errore però in questo caso è stato offrire un LTV molto alto (circa 85%) su token volatili, cosa che è stata sfruttata con ripetuti flash loan. $1,7 milioni di perdite

• 4 novembre 2025: neanche un mese dopo, per colpa di un exploit parallelo su Balancer che ha causato un forte disallineamento del token rsETH (utilizzato come riferimento anche da Moonwell), qualcuno ha preso in prestito un valore molto più elevato rispetto al collaterale fornito, per poi farsi liquidare e generare $3,7 milioni di bad debt. Il problema qui è stato non avere un feed realistico, basato solo sul prezzo del derivato e non sul controvalore di conversione.

• 15 febbraio 2026: l’episodio più banale di tutti, dove un’errata configurazione del prezzo della moneta cbETH e della formula che esplicita il suo controvalore ha causato perdite per $1,78 milioni. Un utente ha sfruttato la falla tramite flash loan, facendosi liquidare per oltre 1000 cbETH.

L’importanza di avere un feed di prezzo veritiero e con security check in DeFi

Al di là della causa scatenante i diversi hack di Moonwell, il vero problema è a monte. Quando si gestisce un protocollo di lending, che rischia di essere drainato qualora i feed di prezzo degli oracoli non forniscono riferimenti precisi, bisogna prestare massima attenzione ed optare per delle configurazioni di sicurezza.

In particolare, la volatilità è il primo nemico dei money market: se i prezzi si muovono troppo velocemente, anche un oracolo serio ed affidabile come Chainlink potrebbe fornire prezzi errati. In questo caso lo scudo è applicare LTV bassi a token volatili, ed avere un cuscinetto di liquidità per compensare gli eventi estremi.

Poi, per il resto l’unica vera preoccupazione è impostare una formula corretta che permetta all’oracolo di restituire un valore il più vicino possibile a quello reale, anche in caso di manipolazioni di fonti esterne. Il punto è che in certi casi occorre impostare dei “sanity check”, ossia meccanismi di sicurezza che consentono di sospendere l’emissione di credito qualora i valori forniti dall’oracolo risultano sproporzionati rispetto alle medie storiche.

Del caso Moonwell si è parlato di problemi dell’oracolo, quando invece l’errore è propria nell’impostazione e nel risk management delle piattaforma. Si è parlato anche in realtà di responsabilità dell’AI, visto che l’ultimo hack nasce da una modifica al codice eseguita da Claude Opus 4.6.

Uno dei primi casi di hack di codice assistito da AI

Ciò che ha fatto molto discutere dell’ultimo hack di Moonwell è il fatto che l’AI abbia contribuito a scrivere il codice, senza rilevare il problema nella configurazione del pricing. Nel dettaglio, l’errore è stato impostare il prezzo di cbETH come il risultato del rapporto cbETH/ETH, senza esplicitare poi il controvalore di ogni singola unità di ETH.

Questioni tecniche anche abbastanza semplici per chi naviga in questi ambienti, e che un’AI avrebbe dovuto quantomeno evidenziare. Il problema è che l’intelligenza artificiale non conosce il contesto delle richieste che vi si fanno e non sa se la formula fornita è adeguata in ottica di risk management, a meno che tutto non venga specificato prima nel prompt.

L’errore non è chiaramente dell’AI, che invece avrebbe verosimilmente semplificato di molto il lavoro dello sviluppatore, che in mancanza di Claude avrebbe dovuto spendere molte più ore a scrivere manualmente ogni riga di codice. Il punto è che tutto il codice deve poi essere ricontrollato nel dettaglio dal dev, implementando anche parametri di sicurezza.

A maggior ragione, quando si gestiscono milioni di dollari (di altri utenti) è ancora più imprescindibile eseguire un rigido double check e non lasciare che sia un AI a dirti se la logica economica del protocollo sia corretta. Altrimenti, sarebbe più opportuno parlare di deficienza artificiale.