Ajna v2 perde circa 775.000 dollari in un attacco senza manipolare un oracle

Ajna v2 è stato sfruttato il 29 agosto 2026 in un attacco che avrebbe sottratto circa 775.000 dollari da sette pool di lending su Ethereum. L’operazione non avrebbe richiesto la manipolazione di un feed di prezzo esterno: le informazioni disponibili indicano invece un intervento sul sistema interno di contabilità delle liquidazioni, usato dal protocollo per determinare garanzie, debito e condizioni di liquidazione. 1311

Le fonti pubbliche permettono di identificare la tipologia dell’attacco e i pool colpiti, ma non offrono ancora una ricostruzione forense completa, transazione per transazione. La sequenza esatta delle operazioni attribuite all’aggressore va quindi considerata provvisoria fino alla pubblicazione di un’analisi tecnica definitiva.

Che cosa è successo nell’exploit di Ajna v2?

Secondo le segnalazioni, l’attacco ha coinvolto i pool syrupUSDC, wstETH, rETH, cbETH, WBTC, WETH/USDC e sDAI. Le perdite complessive sono state stimate inizialmente in circa 775.000 dollari, mentre una ricostruzione successiva ha indicato un totale vicino a 775.400 dollari. Il pool syrupUSDC avrebbe subito la perdita singola più consistente, pari a circa 173.700 dollari. 1913

Ajna ha dichiarato di stare indagando su movimenti anomali dei fondi e ha invitato gli utenti a:

• ritirare i fondi in quote token;
• rimborsare i prestiti ancora in essere;
• smettere di interagire con il protocollo. 111435

L’avviso rifletteva il rischio immediato che nuove operazioni potessero interagire con le condizioni contabili sotto esame.

L’obiettivo era la contabilità delle liquidazioni, non un oracle di prezzo

Ajna è stato progettato per funzionare senza oracle esterni. Invece di affidarsi a un servizio come Chainlink per stabilire il prezzo delle garanzie, il protocollo utilizza l’attività interna dei pool e un sistema di contabilità basato sui cosiddetti bucket. 333

Nel normale processo di liquidazione, debito e garanzia vengono rimossi dai bucket. Questo modifica parametri interni, tra cui il Lowest Utilized Price, o LUP, il prezzo minimo utilizzato dal pool. La liquidabilità dei prestiti viene valutata anche attraverso il Threshold Price (TP) e il Neutral Price (NP) della posizione. 3437

Questa architettura elimina una delle superfici d’attacco più note della finanza decentralizzata, ma non elimina la necessità di una contabilità economica affidabile. Le ricostruzioni disponibili sull’incidente del 29 agosto sostengono che l’aggressore abbia manipolato il percorso interno delle liquidazioni, facendo sì che il trattamento di garanzie, debito e prezzi di liquidazione non rappresentasse più correttamente la copertura economica dei pool. 1311

Il limite delle informazioni attuali è importante: i resoconti descrivono l’exploit a livello generale, ma non verificano in modo indipendente l’intera sequenza di depositi, prestiti, liquidazioni, rimborsi e prelievi che avrebbe prodotto la perdita finale. È quindi più corretto dire che l’aggressore sembra aver sfruttato la contabilità interna delle liquidazioni, senza presentare una ricostruzione transazionale non ancora provata come un fatto definitivo.

“Senza oracle” non significa “a prova di attacco”

L’incidente mette in evidenza una distinzione fondamentale:

Eliminare i feed di prezzo esterni riduce il rischio legato agli oracle, ma non elimina il rischio di una valutazione errata dei prezzi.

Ajna ha concentrato ipotesi economiche cruciali nella propria struttura di mercato e nelle regole di liquidazione. Se queste regole consentono di spostare o sfruttare la rappresentazione interna di garanzie, debito o prezzi di liquidazione, l’effetto economico può assomigliare a quello di un attacco a un oracle, anche quando nessun feed di terze parti viene manipolato. 111

La lezione riguarda l’intero settore del lending DeFi. Le verifiche di sicurezza devono considerare non solo il codice e le dipendenze esterne, ma anche se lo stato contabile del protocollo continua a corrispondere al valore economico reale durante combinazioni anomale di prestiti, liquidazioni e rimborsi.

L’immutabilità ha complicato la risposta all’emergenza

Ajna v2 è stato descritto come un sistema immutabile: senza un organo di governance, un percorso di aggiornamento, una chiave amministrativa o un meccanismo centralizzato in grado di fermare i contratti coinvolti. 9

Questa scelta limita l’intervento discrezionale e riduce alcuni rischi legati alla governance o agli aggiornamenti arbitrari. Ma introduce un compromesso operativo netto: se il meccanismo già distribuito presenta un problema, il team potrebbe non essere in grado di metterlo in pausa o correggerlo mentre l’attacco è in corso.

Defimon Alerts ha dichiarato di aver individuato un attacco preparato più di un’ora prima della prima transazione di exploit e di aver avvisato Ajna attraverso il canale Discord del progetto. La società di monitoraggio ha inoltre sostenuto che il team non avrebbe reagito. Si tratta però della ricostruzione di Defimon, non di un accertamento indipendente: tempistiche e risposta restano quindi da verificare. 816

Che cosa rivela il caso Ajna sui rischi della DeFi

L’ammontare sottratto ad Ajna è relativamente contenuto rispetto ai più grandi furti nel settore crypto. L’episodio è tuttavia significativo perché mostra come la frequenza degli attacchi e la struttura dei protocolli possano essere importanti quanto la cifra riportata nei titoli.

TRM Labs ha registrato 207 hack ed exploit crypto nei primi sei mesi del 2026, il numero più alto mai rilevato in un periodo di sei mesi dal suo dataset. Gli exploit degli smart contract hanno rappresentato circa 125 incidenti. 1829

Separatamente, The Defiant ha riportato circa 70 exploit DeFi e 746 milioni di dollari di perdite nel secondo trimestre del 2026. I diversi tracker adottano criteri di inclusione differenti, perciò i dati non sono direttamente comparabili. Nel loro insieme, però, descrivono un ambiente particolarmente attivo dal punto di vista delle minacce. 23

Il caso Ajna aggiunge un avvertimento preciso: un’architettura può fare a meno degli oracle esterni e mantenere comunque una dipendenza economica critica al proprio interno. L’assenza di oracle, l’immutabilità e la decentralizzazione possono ridurre alcuni rischi, ma aumentarne altri, soprattutto quando non esiste un controllo d’emergenza da attivare dopo l’inizio di un’anomalia contabile.