Nei primi sei mesi del 2026, l’industria crypto ha perso 939,86 milioni di dollari in 135 incidenti di sicurezza verificati. A prima vista, la spiegazione può sembrare semplice: i progetti continuano a distribuire su mainnet codice non verificato, esponendo le tesorerie dei protocolli a exploit già noti.

I dati, però, delineano un quadro più preoccupante.

Più della metà dei progetti colpiti, per oltre 721 milioni di dollari di perdite complessive, aveva completato un audit di sicurezza. Eppure, nel 94,4% di quei casi, l’exploit non derivava da un bug di reentrancy mancato in uno smart contract esaminato. Gli aggressori passavano invece attraverso aree che gli auditor non avevano analizzato:

• Chiavi private compromesse
• Script del front-end dirottati
• Infrastruttura cloud esposta
• Relayer off-chain non esaminati

Queste evidenze provengono da un report di sicurezza H1 2026 completo pubblicato da ack3, una società di cybersecurity AI-native precedentemente nota come Ackee Blockchain Security. Dal 2021, ack3 afferma di aver completato 237 review di protocolli e di aver osservato l’espansione del perimetro di sicurezza, passato da singoli file Solidity a intere architetture di protocollo. In risposta, la società combina revisione manuale, fuzzing basato su Wake, threat modeling off-chain e scansioni AI proprietarie progettate per mappare le dipendenze tra componenti.

Il report mette in luce una debolezza centrale nel modo in cui Web3 valuta il rischio: il settore spesso tratta “auditato” come uno stato binario permanente, mentre gli aggressori vedono le architetture di protocollo come servizi web interconnessi e in costante evoluzione.

“Un audit è un timestamp e un confine, non una garanzia a vita”, afferma Josef Gattermayer, Founder di ack3. “La vecchia domanda era: ‘È stato auditato?’ Le domande utili sono: ‘Che cosa è stato auditato esattamente, quando, e che cosa è cambiato da allora?’ Un report di contratto non può proteggere una chiave di firma trapelata, un front-end compromesso o una distribuzione legacy che non corrisponde più al codice esaminato.”

Il panorama delle perdite H1 2026

Nel primo semestre del 2026, l’ecosistema di sicurezza Web3 ha registrato 135 incidenti di sicurezza verificati, prosciugando 939,86 milioni di dollari da protocolli decentralizzati e dai loro utenti. Ogni exploit incluso nel dataset di ack3 ha superato un rigoroso standard di verifica su due fonti, coprendo sia violazioni on-chain sia off-chain.

Quando gli incidenti vengono raggruppati in base allo storico degli audit, la distribuzione appare relativamente equilibrata:

• Vittime auditate: 68 incidenti (50,4%) hanno colpito progetti con almeno una review di sicurezza completata e verificabile pubblicamente prima dell’attacco.
• Vittime non auditati: 35 incidenti (25,9%) hanno interessato protocolli privi di review di sicurezza formali da parte di terzi.
• Stato dell’audit sconosciuto: 32 incidenti (23,7%) hanno coinvolto progetti per i quali lo storico degli audit non poteva essere confermato alla soglia del dataset.

L’illusione dell’audit

A prima vista, i numeri potrebbero suggerire che le review di sicurezza offrano una protezione limitata. Ma quando gli incidenti vengono misurati in termini di danno finanziario anziché di conteggio, la portata del problema diventa più chiara.

I protocolli auditati hanno rappresentato 721,24 milioni di dollari dei 939,86 milioni persi in H1 2026, pari al 76,7% di tutto il capitale sottratto. I progetti non auditati e quelli con storico di audit sconosciuto hanno totalizzato insieme 218,62 milioni di dollari.

Questo divario mette in evidenza quella che ack3 definisce l’illusione dell’audit. Il capitale tende a fluire verso i progetti che mostrano badge di sicurezza. Allocatori istituzionali, yield farmer e trader retail trattano spesso un report di audit come un via libera, indirizzando liquidità verso protocolli con una postura di sicurezza rifinita.

Questo dinamismo crea un paradosso: gli audit attirano capitale, e il capitale trasforma i protocolli auditati in bersagli di valore più elevato. Sebbene una revisione accurata del codice possa scoraggiare gli attaccanti opportunisti in cerca di evidenti difetti Solidity, gli attori sofisticati non si fermano al badge di audit. Spostano l’attenzione dagli smart contract esaminati verso l’infrastruttura circostante che resta non monitorata.

Come ha mostrato H1 2026, gli aggressori non stanno più cercando di sfondare la porta principale del codice auditato. Entrano dalle porte laterali che non sono mai state esaminate.

Il divario di perimetro: dove sono scomparsi 680 milioni di dollari

Una delle idee sbagliate più pericolose nella sicurezza Web3 è equiparare un audit di smart contract a una protezione dell’intero sistema. In pratica, un audit copre di solito uno specifico commit hash e un insieme definito di file Solidity o Rust. Non copre l’ambiente di distribuzione, le workstation degli sviluppatori, l’infrastruttura cloud, i record DNS o le chiavi private usate per gestire i parametri del protocollo.

La ricerca di ack3 mostra che questa differenza — il “scope gap” — è il punto in cui scompare quasi tutto il capitale sottratto. Su 68 protocolli auditati violati in H1 2026, 46 sono stati colpiti tramite vettori d’attacco del tutto fuori dal perimetro dei loro audit pubblicati. Quei 46 incidenti hanno causato 680,97 milioni di dollari di perdite, pari al 94,4% del danno finanziario subito dalle vittime auditate.

Il divario tra conteggio e valore

La discrepanza diventa ancora più evidente confrontando il numero degli incidenti con le perdite effettive in dollari.

Gli incidenti in cui il percorso dell’exploit si trovava all’interno del codice auditato hanno rappresentato 20 dei 68 breach di protocolli auditati, cioè circa il 29,4% in termini di conteggio. Ma quei 20 exploit in perimetro hanno prodotto solo 35,21 milioni di dollari di perdite, appena il 4,9% delle perdite totali dei protocolli auditati.

L’implicazione è netta. Gli audit tradizionali del codice sembrano svolgere un lavoro ragionevole nell’individuare bug catastrofici degli smart contract, mantenendo le perdite in perimetro sotto il 5% del totale. Il problema più grande sta altrove: i team di protocollo lasciano aperta la porta sul retro e perdono il restante 94,4% a causa di violazioni infrastrutturali e operative.

Anatomia della superficie d’attacco moderna

Gli attaccanti hanno capito che gli smart contract sono spesso l’anello più forte della catena, quindi prendono sempre più di mira la superficie operativa attorno al codice.

ack3 ha individuato quattro vettori operativi ricorrenti alla base dei drenaggi fuori perimetro:

Chiavi private e autorità di firma compromesse: chiavi admin, signer multisig e hot wallet operativi restano la via più rapida per un drenaggio completo. Una volta che un’autorità di firma viene compromessa tramite phishing o cattiva gestione delle chiavi, l’attaccante può aggiornare i contratti, modificare i parametri o attivare mint di emergenza usando funzioni legittime del protocollo, aggirando completamente i controlli di logica on-chain.

Iniezioni di script nel front-end e DNS hijacking: invece di attaccare la logica on-chain, gli aggressori compromettono l’interfaccia di cui gli utenti si fidano. Prendendo il controllo dei record DNS o iniettando JavaScript malevolo tramite dipendenze web di terze parti, possono sostituire gli indirizzi di destinazione o indurre gli utenti ad approvare spenditori malevoli mentre interagiscono con quella che appare come una UI legittima.

Pipeline CI/CD e credenziali dell’infrastruttura cloud: i percorsi d’attacco transitano sempre più spesso attraverso GitHub Actions, variabili d’ambiente cloud e pipeline di build. Secret hardcoded o API key trapelate possono consentire agli aggressori di alterare gli artifact di build o accedere alle risorse infrastrutturali prima che il codice raggiunga la blockchain.

Prover off-chain, relayer e infrastruttura cross-chain non esaminati: i protocolli DeFi moderni fanno ampio affidamento su sistemi off-chain, inclusi prover, relayer oracle, sequencer zero-knowledge e bridge di messaggistica cross-chain. Questi servizi complessi restano fuori dagli audit standard dei contratti, eppure determinano gli input che attivano l’esecuzione on-chain. Quando un relayer o un prover off-chain fallisce, lo smart contract si limita a elaborare l’aggiornamento di stato errato come istruito.

Assurance puntuale e problema dell’invecchiamento

Anche quando un exploit colpisce codice che era esplicitamente incluso nel perimetro di un audit, i dati di ack3 indicano un’altra vulnerabilità nelle pratiche di sicurezza Web3: il decadimento dell’assurance.

Un report di audit non è uno scudo continuo. È un’istantanea statica di un sistema in un singolo momento. Eppure i protocolli spesso presentano report PDF vecchi di due anni come prova della sicurezza attuale. La ricerca di ack3 dimostra che il valore protettivo di una review storica si degrada nel tempo, anche se la logica sottostante dello smart contract rimane invariata.

Il tasso di decadimento della sicurezza

Tra i 20 incidenti in cui il percorso dell’attacco rientrava direttamente nel perimetro auditato di un protocollo, 17 si sono verificati almeno sei mesi dopo l’audit più pertinente. Il tempo mediano trascorso tra la data dell’audit e l’exploit è stato di 18 mesi, con intervalli che andavano da tre mesi fino a 56 mesi.

Solo tre protocolli hanno subito exploit in perimetro entro sei mesi dalla ricezione di un report di audit. La grande maggioranza dei fallimenti in perimetro si è verificata molto tempo dopo la review originale:

• Meno di 6 mesi: 3 incidenti (15% dei casi in perimetro)
• Da 6 a 24 mesi: 9 incidenti (45%)
• 24 mesi o più: 8 incidenti (40%)

Questa distribuzione evidenzia un punto fondamentale: la rilevanza di un report di audit decresce rapidamente in un ecosistema in rapido movimento. L’età, da sola, non causa un bug dello smart contract, ma misura per quanto tempo il codice resta esposto mentre tutto ciò che gli sta attorno cambia. Per questo è importante che i protocolli crypto completino audit multipli con frequenza e non facciano affidamento su un audit vecchio di 2 anni.

L’AI come moltiplicatore dell’attacco e il passaggio all’assurance continuo

Gli strumenti AI specializzati hanno modificato in modo permanente velocità e scala della ricerca di sicurezza. Sebbene il dataset H1 2026 di ack3 non attribuisca alcun singolo incidente ad agenti AI autonomi, il report evidenzia uno spostamento nel panorama delle minacce: gli aggressori stanno usando l’AI come moltiplicatore operativo.

Il nuovo realismo della minaccia

Individuare un bug di reentrancy complesso in un contratto Solidity ampiamente revisionato richiede ancora tempo e competenze significative. Trovare una chiave enclave esposta in un repository off-chain non indicizzato o identificare uno script di terze parti non pinnato in una pipeline di build front-end richiedeva in passato una noiosa ricognizione manuale.

I modelli AI hanno ridotto quel costo temporale quasi a zero.

Gli aggressori ora usano tool AI per assimilare rapidamente interi ecosistemi di protocollo, mappare relazioni tra repository, tracciare i flussi di parametri dall’off-chain all’on-chain e sondare le giunture non monitorate tra infrastruttura cloud, reti di delivery del front-end e smart contract.

Con benchmark come EVMbench che misurano attivamente gli agenti AI su rilevamento di vulnerabilità, patch automatiche e sintesi di exploit, il vantaggio asimmetrico va a chi scansiona la superficie più ampia nel minor tempo. Se i difensori limitano la propria visione a una directory di smart contract, gli aggressori assistiti dall’AI individueranno con regolarità prima le vulnerabilità operative circostanti.

Sostituire il PDF come artefatto

L’abitudine del settore di trattare un report di audit statico in PDF come una credenziale di sicurezza permanente è ora, secondo ack3, un rischio esistenziale. Un documento statico non può avvisare un team quando uno sviluppatore commette un secret API in un repository pubblico, né può valutare come si comporta uno smart contract dopo che un liquidity pool upstream modifica la propria struttura commissionale.

Per sopravvivere in un ecosistema in cui i vettori d’attacco attraversano i confini tra componenti a velocità guidata dall’AI, i protocolli devono passare dalle review puntuali a un’assurance continuo. ack3 delinea tre pilastri fondamentali per questa transizione:

1. Sostituire gli elenchi statici dei contratti con un registro attivo e in tempo reale dell’intera superficie del sistema, tracciando continuamente:

   • Deploy on-chain degli smart contract e indirizzi proxy
   • Infrastruttura off-chain, relayer, prover e pipeline oracle
   • Ruoli amministrativi, signer multisig e schemi di gestione delle chiavi
   • Dipendenze web, CDN e pipeline di build del front-end

2. Non rinnovare l’assurance secondo un calendario annuale rigido e non considerarla permanente. I protocolli hanno bisogno di trigger operativi espliciti che segnalino immediatamente codice o infrastruttura per una ri-review mirata, tra cui:

   • Deploy di nuove implementazioni proxy o aggiornamenti dei parametri
   • Rotazione delle chiavi, trasferimenti di ruoli amministrativi o modifiche alle soglie multisig
   • Integrazione di nuovi bridge cross-chain, feed oracle o protocolli di liquidità upstream
   • Scoperta di nuove classi di attacco o nuovi vettori di exploit in protocolli peer

3. Usare in tandem analisi automatica ed esperienza umana prima e dopo il deploy su mainnet. Gli scanner AI automatizzati e i motori di fuzzing basati su Wake sono adatti alla ricerca su larga scala, al tracciamento delle dipendenze tra componenti, al rilevamento del logic drift e al monitoraggio dell’infrastruttura live per cambiamenti di stato inattesi. Gli ingegneri di sicurezza umani intervengono poi per verificare l’exploitability, valutare i modelli di minaccia economica e validare la logica di business.

L’obiettivo non è eliminare gli audit, ma fare in modo che l’assurance tenga il passo con i cambiamenti del sistema. In questo modello, l’etichetta binaria “auditato” diventa ciò che avrebbe sempre dovuto essere: un processo continuo e non un badge statico.

Conclusione: ripensare la postura di sicurezza in Web3

I 940 milioni di dollari persi in H1 2026 rendono chiaro un punto: trattare un audit storico puntuale come un via libera permanente è negligenza operativa. Gli smart contract non esistono in un vuoto. Un audit che copre file Solidity ma ignora dipendenze del front-end, chiavi di firma amministrative, infrastruttura cloud e prover off-chain non costituisce una garanzia di sicurezza completa.

Con la maturazione dell’allocazione del capitale in Web3, i meccanismi di valutazione del rischio stanno passando dalle review puntuali al monitoraggio dell’intero sistema. Il futuro della sicurezza Web3 appartiene ai team che trattano l’assurance come una disciplina operativa attiva. Chi continua a nascondersi dietro report PDF statici resterà semplicemente il bersaglio di maggior valore sulla lavagna.