L'attaccante ha sfruttato un difetto di progettazione nella funzione swap() che consentiva chiamate arbitrarie all'esecutore, con conseguente furto dagli utenti che avevano concesso approvazioni illimitate.

Le chiavi di firma del validatore presumibilmente trapelate e un flash loan hanno permesso all'attaccante di ottenere un potere di voto esclusivo. Avendo il controllo sui validatori, l'attaccante ha utilizzato i fondi del bridge nello stesso blocco per acquistare BONE, delegarlo per il potere di validazione, firmare checkpoint fraudolenti e quindi rimborsare il "prestito" con gli asset rubati.

L'aggressore ha utilizzato una chiave privata compromessa di un account amministratore proxy per aggiornare un contratto intelligente a una versione dannosa. L'aggressore ha quindi utilizzato la versione dannosa del contratto intelligente per svuotare il saldo del contratto stesso, così come i portafogli degli utenti che avevano approvato tale contratto intelligente.

L'accesso non autorizzato all'API di Kiln, un partner di staking di SwissBorg, ha portato a un furto di $41.5 milioni dal programma di staking SOL Earn. Gli aggressori hanno manipolato le autorizzazioni degli account di staking senza la necessità di conferme multi-firma. Ciò ha permesso loro di trasferire l'autorità silenziosamente, mantenendo il ruolo di "Withdrawer", il che li ha aiutati a eludere gli strumenti di monitoraggio standard che si concentrano sugli eventi di prelievo. La violazione è stata un exploit API off-chain che ha dato agli aggressori il controllo sugli asset on-chain.

Uno sviluppatore di Nemo ha introdotto una nuova funzionalità non verificata nel codice dopo l'audit di sicurezza iniziale, ma prima che il rapporto finale rivisto fosse completato. Di conseguenza, una versione del contratto contenente questo codice non verificato è stata distribuita sulla rete principale (mainnet). La causa principale della governance è stata il fatto che il protocollo si basava su un indirizzo a firma singola per gli aggiornamenti, il che non è riuscito a impedire la distribuzione di codice che non aveva subito un'approfondita revisione della sicurezza. Inoltre, lo sviluppatore ha distribuito una versione del codice diversa da quella confermata dalla società di audit. Un attaccante ha sfruttato queste funzioni non verificate per manipolare lo stato interno ed è riuscito a sottrarre una quantità sostanziale di asset dal pool di liquidità.

Gli aggressori hanno utilizzato un client Zoom dannoso per ottenere privilegi sulla macchina della vittima. Hanno sfruttato questo accesso per indurre la vittima a inviare una transazione che approvava l'aggressore come delegato Venus valido per il proprio account, consentendo così all'aggressore di prendere e rimborsare prestiti per conto della vittima.

Gli aggressori hanno ottenuto l'accesso a un portafoglio multisig con 32 milioni di token AIO. I fondi sono stati spostati e scambiati per 2 milioni di dollari.

L'attaccante ha sfruttato una vulnerabilità nel contratto connettore, che converte automaticamente i token fruttiferi (come aUSDC) in USDC durante i prelievi. Utilizzando questo difetto, l'hacker ha eseguito un prelievo per conto di un altro utente e ha sottratto 427.000 USDC da Aave.

L'aggressore ha sfruttato la mancanza di una convalida adeguata per coniare token FAVOR non sicuri. Ha utilizzato un contratto intelligente falsificato come fornitore di liquidità (LP), quindi ha eseguito uno scambio in blocco per ottenere un bonus significativo che poteva essere convertito in denaro reale. L'auditor, zokyo, aveva precedentemente segnalato vulnerabilità direttamente collegate a questo attacco. Tuttavia, a causa di un'analisi approfondita insufficiente, la gravità di questi risultati è stata declassata a un livello basso.

L'exchange di criptovalute turco BTCTurk è stato vittima di un attacco da 48 milioni di dollari. L'attacco ha comportato la fuga di chiavi private, consentendo agli aggressori di prelevare fondi da hot wallet su sette diverse blockchain. L'exchange ha sospeso i servizi di criptovaluta.

Odin.fun, una piattaforma di lancio e scambio di memecoin basata su Bitcoin, ha subito un exploit. L'attacco ha sfruttato un difetto nello strumento di market-making automatizzato della piattaforma, introdotto nell'ultimo aggiornamento. Gli aggressori hanno attuato uno schema di manipolazione della liquidità aggiungendo token come SATOSHI per far salire i prezzi, quindi ritirando la loro liquidità per incassare in Bitcoin.

Un aggressore ha utilizzato il ruolo BRIDGE per emettere token senza una garanzia adeguata. Questi token sono stati poi usati come collaterale per prestiti in altri token. I fondi presi in prestito (garantiti dai token senza collaterale) sono stati prelevati e riciclati sulla rete Ethereum.

Il controllo di accesso nella funzione updateMerkleRoot() è stato configurato in modo errato. Invece di verificare che l'indirizzo chiamante SIA il proprietario, il codice verificava che NON FOSSE il proprietario. Questo errore di codifica nel contratto intelligente ha permesso a un attaccante di formare una falsa radice Merkle e di aggiornare il contratto intelligente con essa. La radice fabbricata ha permesso all'attaccante di prelevare token dal contratto intelligente.

Un attaccante ha compromesso il dispositivo di uno sviluppatore tramite un attacco di phishing. È stato ottenuto l'accesso all'ambiente di sviluppo. L'attaccante ha avviato il prelievo di fondi da 9 account utente.

L'incidente ha coinvolto l'accesso non autorizzato a un portafoglio operativo utilizzato per la fornitura di liquidità su un exchange partner.

Un attacco alla catena di approvvigionamento che ha compromesso la rete di produzione, consentendo agli aggressori di modificare la logica operativa dei server di controllo account e rischio.

Il protocollo disponeva di un sistema di interruzione del circuito che si è attivato quando è stato distribuito il contratto dannoso. Tuttavia, un meccanismo integrato progettato per impedire che il protocollo venisse messo in pausa indefinitamente è stato utilizzato dall'attaccante contro il protocollo stesso. Quando il team ha eseguito simulazioni con lo smart contract dannoso e non ha trovato percorsi di exploit possibili, ha riavviato il protocollo. Le azioni successive dell'attaccante non sono state interrotte a causa del limitatore sulla ri-pausa del protocollo descritto in precedenza. L'attaccante ha utilizzato prestiti flash e dati di chiamata (calldata) dannosi per svuotare gli account delle vittime. La causa principale dell'hack è stata la mancanza di convalida dei dati di chiamata.

È stata scoperta una backdoor critica in migliaia di contratti che utilizzano ERC1967Proxy. Un hacker è riuscito a precedere l'inizializzazione e installare un proxy hacker nel mezzo, rimanendo inosservato a causa di un bug negli esploratori di blocchi. L'hacker ha coniato 110.000 token K e ha iniziato l'attacco per svuotare sia il Morpho Vault che il pool Uniswap v4.

L'exploit ha avuto origine dal contratto intelligente malevolo creato dall'attaccante, che è stato utilizzato per creare e dirottare l'esecuzione durante l'evasione dell'ordine. La causa principale include l'assunto implicito in executeDecreaseOrder() che il parametro _account sia un account di proprietà esterna (EOA), quando in realtà può essere un contratto intelligente malevolo. Questa vulnerabilità ha portato a un sofisticato attacco multi-step in cui l'attaccante è stato in grado di gonfiare artificialmente l'AUM del protocollo e riscattare GLP per più asset di quanto meritato.

Un attaccante è riuscito a sfruttare la funzione di ribilanciamento del contratto Texture Vaults per attivare un trasferimento. L'attaccante ha fornito il proprio account token, che il Vault ha erroneamente riempito con token LP durante il ribilanciamento. L'attaccante ha quindi riscattato questi token LP per liquidità reale.

Un pool a bassa liquidità è stato utilizzato da un utente come oracolo durante la configurazione di un pod. L'attaccante è stato in grado di manipolare questo pool utilizzando un prestito flash, e quindi è stato contratto un prestito sottocollateralizzato.

L'attaccante ha preso di mira il contratto ResupplyPair che utilizza il tasso manipolato, poche ore dopo il suo deployment. La causa principale è stata un bug di manipolazione del tasso di cambio innescato tramite un classico attacco alla vault ERC4626 di "prima donazione", che ha portato a uno scenario di divisione per un valore elevato che ha fatto crollare l'exchangeRate a zero. Questo tasso manipolato è stato utilizzato per calcolare l'LTV del mutuatario nel controllo _isSolvent(). Poiché ltv = 0 quando exchangeRate = 0, l'attaccante ha aggirato il controllo di solvibilità e ha preso in prestito 10 milioni di reUSD utilizzando solo 1 wei di collaterale.

L'exploit si riferiva a un contratto intelligente per una funzionalità di leva finanziaria non ancora rilasciata, implementata per scopi di test. Ha preso di mira un contratto periferico utilizzando fillQuote per chiamare silo.borrow(), manipolando i parametri per colpire un portafoglio di test del team Silo Core.

Il bridge Hacken è stato sfruttato. Una chiave privata associata a un account con diritti di conio è stata esposta, consentendo agli attaccanti di coniare enormi quantità di token HAI e quindi di venderli rapidamente su scambi decentralizzati. La chiave privata era associata ai ruoli di conio sulle reti Ethereum e BNB Chain. Gli attaccanti sono stati in grado di coniare circa 900 milioni di token HAI.

L'attaccante ha sfruttato una vulnerabilità critica di integer underflow nella funzione BankrollNetworkStack.sell() per manipolare la contabilità dei dividendi e prelevare fondi dagli utenti che avevano precedentemente interagito con o approvato il contratto.

Nobitex, il più grande exchange di criptovalute iraniano, è stato l'obiettivo di un significativo attacco informatico rivendicato dal gruppo di hacking pro-Israele Gonjeshke Darande, noto anche come Predatory Sparrow. Il gruppo ha affermato che Nobitex supportava le attività militari iraniane e aiutava gli utenti a eludere le sanzioni internazionali, inquadrando l'atto come un messaggio simbolico legato all'escalation delle tensioni tra Israele e Iran. L'attacco ha comportato il furto di criptovalute dai wallet caldi di Nobitex su più blockchain compatibili con Ethereum Virtual Machine (EVM) e Tron. Il gruppo di hacking sembra aver bruciato le criptovalute, distruggendole di fatto anziché prelevarle per i propri profitti.

La vulnerabilità derivava dalla mancata sovrascrittura o restrizione della funzione base mint() esposta pubblicamente ereditata dallo standard OpenZeppelin ERC4626Upgradeable, il che ha permesso agli attaccanti di coniare 9701 mpETH senza fornire alcun ETH.

L'exploit ha avuto origine da una vulnerabilità all'interno della logica di verifica della funzione di auto-listing. L'attaccante ha sfruttato una falla critica nella logica di verifica della funzione create2 facendo riferimento a una transazione fallita, consentendo a un token dannoso di aggirare i controlli e trasferire fondi dai pool di liquidità.

L'attaccante ha eseguito un attacco alla catena di approvvigionamento per esfiltrare le chiavi private. Le chiavi trapelate sono state quindi utilizzate per sbloccare i fondi dai contratti intelligenti del bridge. L'attacco alla catena di approvvigionamento ha preso di mira il codice del validatore; il codice malevolo è stato iniettato nell'immagine Docker in fase di compilazione.

Un contratto di migrazione da Mendi a Malda è stato sfruttato. Il contratto permetteva di passare dinamicamente l'indirizzo del Controllore Mendi, piuttosto che essere codificato. L'attaccante ha utilizzato una funzionalità progettata esclusivamente per consentire agli utenti del protocollo Mendi di migrare direttamente a Malda. L'attaccante ha distribuito un contratto Controllore Mendi falso, permettendogli di creare una posizione Malda fraudolenta e prelevare fondi contro di essa.

Il problema centrale dietro l'exploit deriva da due difetti critici nel protocollo Cork. In primo luogo, il contratto di configurazione del protocollo (CorkConfig) consentiva agli utenti di creare mercati con asset di riscatto (RA) arbitrari, consentendo all'aggressore di designare DS come RA. In secondo luogo, la funzione beforeSwap del contratto CorkHook mancava di un controllo di accesso e di una convalida dell'input adeguati, consentendo a chiunque di invocarla con dati di hook personalizzati per le operazioni CorkCall. Sfruttando queste debolezze, l'aggressore ha creato un mercato malevolo utilizzando DS come RA e ha utilizzato token DS validi da un mercato legittimo per depositarli in questo mercato falso. In cambio, hanno ricevuto sia token DS che CT. A causa dell'assenza di restrizioni sui tipi di RA e di una convalida insufficiente del chiamante e dei dati di input, l'aggressore è stato in grado di manipolare la liquidità ed eseguire riscatti non autorizzati, prosciugando il mercato originale. Questa manipolazione ha permesso loro di acquisire una grande quantità di derivati, che alla fine hanno riscattato per 3,761 wstETH. La causa fondamentale dell'exploit risiede nel fallimento del protocollo nel convalidare rigorosamente i dati forniti dall'utente e nell'imporre restrizioni adeguate sulla creazione di mercati.

L'attaccante ha sfruttato una vulnerabilità situazionale nel percorso di deposito della vault usUSDS++, una vault beta costruita sul protocollo Sky. La vulnerabilità era incentrata sul processo di "unwrap", in cui USD0++ viene convertito in USD0 durante i depositi. Manipolando la rotta di deposito della vault, in particolare la conversione limitata e con tetto massimo da USD0++ a USD0, l'attaccante ha eseguito una strategia di arbitraggio e ha realizzato un profitto di circa $42.800. La vault è stata sottoposta a 4 audit di sicurezza negli ultimi mesi. L'exploit non è stato dovuto a una logica difettosa. Invece, ha sfruttato un caso limite comportamentale nel sistema.

La mancanza di convalida dei feed di prezzo di Chainlink Oracle ha permesso all'attaccante di utilizzare una firma di prezzo vecchia, ma comunque crittograficamente valida, per aprire una posizione. L'attaccante ha utilizzato un prezzo ETH significativamente obsoleto di circa $1.816, mentre il prezzo di mercato reale era più vicino a $2.520. La differenza nei prezzi degli asset è stata estratta come profitto.

Un bug nel metodo di controllo del overflow degli interi ha permesso a un attaccante di coniare SUI non garantiti.

Un contratto smart con bug e deprecato era ancora utilizzato come oracolo per il prezzo del token prima dell'attacco. L'attaccante ha usato la donazione per sfruttare la vulnerabilità nel codice e ha gonfiato artificialmente il prezzo di dGLP. L'attaccante ha quindi utilizzato il dGLP sopravvalutato come garanzia per il prestito.

La sequenza di attacco si è basata sull'ottenimento di estesi privilegi amministrativi. Un ruolo di amministratore è stato concesso all'indirizzo di un attaccante dal portafoglio di distribuzione del protocollo Zunami. Successivamente, l'attaccante ha eseguito l'exploit chiamando direttamente la funzione withdrawStuckToken() sulla strategia di Zunami, una funzione progettata per i prelievi di emergenza. Questa singola chiamata ha permesso all'attaccante di trasferire 296.456 token LP, che rappresentano la garanzia per zunUSD e zunETH, direttamente al proprio indirizzo.

Lo smart contract non revisionato conteneva un semplice errore logico che ha permesso all'attaccante di prosciugare tutta la liquidità. La causa principale era l'eccesso del moltiplicatore 1e18 nella funzione di valutazione del deposito.

L'incidente è stato ricondotto a uno sviluppatore assunto inconsapevolmente dal team, che si è rivelato essere un lavoratore IT sotto copertura della RPDC. Questo individuo/team ha avuto accesso illecito alle chiavi amministrative del progetto e ha eseguito una serie di transazioni non autorizzate. L'attaccante aveva distribuito una versione modificata dei contratti AToken e VariableDebtToken. In questa versione, il modificatore di controllo degli accessi onlyPool è stato alterato per consentire non solo al contratto Pool, ma anche a qualsiasi indirizzo con il ruolo di amministratore del Pool, di eseguire funzioni che erano originariamente limitate. L'attaccante ha utilizzato il wallet del deployer compromesso per avviare lo svuotamento di tutti i pool.

Durante un aggiornamento interno dell'oracolo tETH, è stata introdotta una discrepanza nella precisione decimale tra i componenti dell'oracolo. Questa inconsistenza ha causato output di prezzo errati per tETH. Un liquidatore anonimo ha eseguito liquidazioni durante il periodo in cui il prezzo errato di tETH era attivo.

Loopscale è stato bersaglio di un attacco che ha sfruttato la logica di prezzo del protocollo per i token emessi da RateX. Manomettendo i programmi di mercato RateX PT, l'aggressore è riuscito a ottenere una serie di prestiti sottocollateralizzati. Il percorso del codice sfruttato è stato implementato come parte di una nuova integrazione con RateX e non aveva ancora subito un audit formale di terze parti.

Sfruttando un codice di protocollo difettoso, l'attaccante ha creato un pool di liquidità lontano dal prezzo corrente e ha generato commissioni sostanziali tramite wash swap. Queste commissioni sono state quindi utilizzate per gonfiare la valutazione della garanzia, sfruttando una matematica del contratto intelligente difettosa. L'attaccante ha successivamente preso in prestito contro questa garanzia sopravvalutata. Tuttavia, il reinvestimento ha in seguito ridotto il valore della garanzia, causando un debito sottocollateralizzato. Questo debito è stato quindi ristrutturato senza liquidazione, consentendo all'attaccante di conservare i fondi illeciti.

Il wallet del deployer di Oxya Origin sembra essere stato compromesso, con il conseguente trasferimento della proprietà del token $OXYZ a un indirizzo sospetto (0x2a00d9941ab583072bcf01ec2e644679e4579272). L'attaccante ha mintato 9 miliardi di $OXYZ, ha scambiato 45.000 $ e ha trasferito i fondi tramite Stargate.

Una vulnerabilità nella funzione overPaper dello smart contract BTCMapp ha permesso a un attaccante di estrarre 1.311 ETH, equivalenti a $2.228.700.

L'aggressore ha manipolato il prezzo del token $NUMA, aprendo contemporaneamente grandi posizioni corte e lunghe, rimuovendo il collaterale depositato auto-liquidandosi e uscendo tramite il caveau.

Lo sviluppatore malevolo aveva iniettato codice nello smart contract di staking, consentendogli di eseguire un prelievo di emergenza dal pool di liquidità, con il conseguente furto di token per un valore di circa 490 ETH.

La vulnerabilità ha avuto origine nel contratto TrustedForwarder, che ereditava da MinimalForwarderUpgradeable di OpenZeppelin ma non sovrascriveva il metodo execute. Di conseguenza, il metodo è rimasto senza permessi ed esposto a usi impropri. L'attaccante ha sfruttato questa svista chiamando direttamente la funzione execute originale da MinimalForwarderUpgradeable. In una singola transazione, l'attaccante ha aperto una posizione a un prezzo artificialmente basso e l'ha poi chiusa a un prezzo più alto, generando un profitto illegittimo tramite questo exploit.

L'attaccante ha utilizzato un account amministratore compromesso per coniare i token rimanenti non reclamati dai distributori Merkle di token ZK utilizzati per l'airdrop ZKsync del 17 giugno 2024. L'hacker ha preso con successo il controllo di 111.881.122 token ZK.

Le chiavi private sono state compromesse. L'attaccante ha quindi utilizzato queste chiavi per aggiornare una funzione nel contratto con una dannosa, consentendogli di prelevare fondi.