Smart Contract Risks

What happened

An attacker exploited a broken access control check in New Market Trading’s custom Gnosis Safe module, SquidRouterModule. 88 user Safes were drained across Ethereum, Base, and Arbitrum in under 15 minutes. No flash loan, no phishing, no bridge exploit: the attacker read a public contract, copied a string, encoded a real delegate address from an open on-chain registry, and called a function that had been left unguarded for three months.

Amount Lost

$3.78 million (88 user Safes across Ethereum, Base, Arbitrum)

Parties

New Market Trading (victim), SquidRouterModule (custom Safe module), QuillAudits (post-hoc analysis)

Category

—

Technical Attack Vector

• The PermissionsManager contract storing each Safe’s registered delegate address was fully public on-chain: the attacker read it directly to enumerate real delegates per target Safe
• For each target Safe, the attacker crafted a call payload encoding the real delegate address, along with three chained actions: APPROVE, PERMIT2 authorization, and SWAP targeting attacker-controlled pools (amountOutMin set to 0)
• The module verified the caller with: require(sourceAddress == squidRouter), but sourceAddress was a parameter the caller supplied themselves, with no binding to msg.sender
• The module then ran: require(hasPermission(safe, delegate, APPROVE)), but the delegate address was decoded from the caller’s own payload, not derived from msg.sender
• The attacker passed the string “squidRouter” and encoded the real registered delegate. Both checks passed. The actual caller was never verified
• The single missing line that stops the entire attack: require(msg.sender == delegate)
• With both checks cleared, the module executed all three actions: approved token balance, authorized Permit2, then forced a full-balance swap through attacker’s Uniswap V3 pool into a worthless “u” token
• Attacker removed liquidity, consolidated cross-chain via Relay, and swept everything to a single holding wallet as DAI

Root cause

Confused deputy vulnerability in SquidRouterModule. The module inherited expressExecuteWithToken() from Axelar’s gateway interface (built for relayers, not for vault execution) and placed no additional access control behind it. The contract verified that a valid delegate existed. It never verified that the caller is that delegate. A documented, well-understood pattern entirely preventable with a single require check.

What happened

An attacker exploited KelpDAO’s LayerZero OFT (Omnichain Fungible Token) configuration by leveraging a critically weak DVN (Decentralized Verifier Network) setup: 1 required DVN, 0 optional DVNs, threshold 0. The single required DVN (LayerZero Labs) signed an attestation for a message that was never actually emitted on the source chain (Unichain). With no independent verifiers to contradict it, the forged message passed verification and triggered minting of 116,500 rsETH (~$290M) on Ethereum.

Amount Lost

~$290 million (116,500 rsETH)

Parties

Kelp DAO (victim), LayerZero Labs (compromised/faulty DVN), Tornado Cash (funding)

Category

—

DVN Configuration (On-Chain Visible)

• requiredDVNCount: 1
• requiredDVNNames: [LayerZero Labs]
• optionalDVNCount: 0
• optionalDVNThreshold: 0
• Destination OApp: rsETH OFT Adapter on Ethereum (0x85d456B2DfF1fd8245387C0BfB64Dfb700e98Ef3)

Technical Attack Vector

• Step 1: Attacker prepared infrastructure (funded via Tornado Cash months in advance)
• Step 2: Forged a cross-chain message that was never emitted on source chain (Unichain)
• Step 3: Single required DVN (LayerZero Labs) signed attestation for the non-existent packet
• Step 4: No optional DVNs or threshold to challenge the fraudulent attestation
• Step 5: Message passed verification: commitVerification → lzReceive → peer check → OFT decode → rsETH mint
• Result: 116,500 rsETH materialized on Ethereum with no corresponding lock on source chain

Root cause

A configuration failure, not a LayerZero protocol bug. KelpDAO chose a 1/1 DVN setup, the cross-chain equivalent of a 1-of-1 multisig on a treasury. LayerZero V2 is modular by design; projects pick their own X-of-Y-of-N security stack. The protocol provided the toolkit; KelpDAO failed to use it.

Secure OFT/OApp Configuration Baseline

• Multiple required DVNs (3–4+) with independent providers
• Don’t stack correlated risk: use diverse DVN operators
• Add optional DVNs + threshold on top of required set
• Sane block confirmations for finality
• Verify any OApp’s config on layerzeroscan.com today

If your requiredDVNCount is 1 and optionalDVNCount is 0: Reconfigure before the market does it for you. Security is the application’s responsibility.

What happened

On April 1, 2026 at 16:05 UTC, an exploit worth approximately $285M struck Drift Protocol. The attacker used compromised multisig signers (2-of-5 Security Council) combined with Solana’s durable nonce mechanism to execute pre-signed malicious transactions. Over a 9-day timeline, the attacker created durable nonce accounts, adapted to a legitimate multisig migration on March 27, and obtained pre-signatures from legitimate signers through transaction misrepresentation. No seed phrase leaks or smart contract bugs were involved.

Amount Lost

$285 million (JLP, USDC, wETH, dSOL, cbBTC vaults)

Parties

Drift Protocol (victim), Switchboard (oracle infrastructure), Four Pillars (analysis)

Category

Private key compromise, Durable nonce

Attack Timeline (9-Day Reconnaissance)

• March 23 (T-9 days): Attacker created four durable nonce accounts: two for Drift Security Council signers, two attacker-controlled
• March 27 (T-5 days): Drift team executed planned multisig migration. Attacker adapted by creating new nonce account for signer (6UJbu9...Pvu924) on the updated multisig
• March 31 (T-1 day): Attacker re-established access to 2-of-5 signers on the migrated multisig
• April 1, 16:04 UTC: Drift team executed routine test withdrawal from insurance fund
• April 1, 16:05 UTC (~1 min later): Attacker executed two pre-signed durable nonce transactions in rapid succession

Technical Attack Vector

• Durable Nonce Mechanism: Solana feature allowing transactions to bypass standard blockhash expiration (~1 minute). Signatures collected in advance, executed later
• Social Engineering: Attacker obtained pre-signatures by misrepresenting actual transaction contents to legitimate signers
• Single Transaction Dismantled Three Defenses: In transaction 4a5962R...st82X, the attacker simultaneously:
  • Called initializeSpotMarket to create Spot Market #63 for CVT, setting initial_asset_weight and maintenance_asset_weight to maximum via bundled updateSpotMarketMarginWeights
  • Assigned attacker-controlled SwitchboardOnDemand oracle (oracle_source=11)
  • Called updateWithdrawGuardThreshold five times, raising limits on USDC, wETH, dSOL, JLP, and cbBTC markets to ~500 trillion (effectively infinite)
• Deposited ~785M CVT as collateral. Attacker-controlled oracle valued it at hundreds of millions; maxed weights recognized nearly full valuation as collateral
• Borrowed against inflated CVT collateral, draining real assets. JLP vault: 99.9997% drained (41.7M → 133 JLP)

Root cause

A 9-day social engineering campaign against a 2-of-5 multisig using durable nonces. But critically: the protocol’s privilege architecture allowed market creation, oracle assignment, weight configuration, and guard neutralization in a single transaction. The contracts functioned exactly as audited: initializeSpotMarket, updateWithdrawGuardThreshold, and oracle assignment all worked as designed. The flaw was architectural: no upper bounds on new market weights, no timelock for weight changes, no separation between market creation and risk parameter modification. This falls outside code auditing into privilege architecture and parameter constraints. Two transactions dismantled the entire security architecture.

What happened

Solv’s BitcoinReserveOffering (BRO) contract used ERC-3525 (semi-fungible token standard with NFT-like callbacks). The mint function triggered onERC721Received before updating state, allowing the attacker to re-enter and mint twice. The contract was unaudited and excluded from bug bounty coverage despite five audits on other Solv contracts.

Amount Lost

$2.73 million (38.05 SolvBTC)

Parties

Solv Protocol (victim), Quantstamp/Salus/OpenZeppelin (auditors of OTHER contracts), unaudited BRO contract

Category

Reentrancy, Audit scope gaps

Technical Attack Vector

• Contract used doSafeTransferIn() to receive NFT deposits during minting
• This triggered onERC721Received callback in attacker’s contract
• Callback minted BRO tokens BEFORE execution returned to original mint()
• Original mint() then minted BRO tokens again
• Same deposit minted twice (double-mint)
• Attacker started with 135 BRO, ended with 567 million BRO after 22 loops
• Swapped BRO for 38.05 SolvBTC (~$2.73M), exited via Tornado Cash

Root cause

Missing reentrancy guard and improper ordering of state updates vs. external calls. The BRO contract was unaudited and explicitly excluded from bug bounty coverage (which only covered Web2 infrastructure and Solana contracts). Security theater: five audits on other contracts created false confidence while the new product shipped without review.

What happened

An attacker spent 9 months accumulating THE tokens, then bypassed Venus’s supply cap via direct ERC-20 transfers (donations) to inflate the vToken exchange rate. This allowed borrowing against collateral that exceeded protocol limits, ultimately leaving $2.15M in bad debt. Code4rena had flagged this exact vector in May 2023; Venus dismissed it as “supported behavior with no negative side effects.”

Amount Lost

$3.7 million extracted, $2.15M bad debt remaining (1.18M CAKE + 1.84M THE)

Parties

Venus Protocol (victim, 4th exploit in 5 years), Thena (token), Code4rena (flagged M-10 in May 2023, dismissed)

Category

Oracle manipulation, Supply cap bypass

Technical Attack Vector

• Supply cap enforced only in mint() function, not in direct transfer()
• Attacker accumulated 84% of supply cap via normal deposits (12.2M THE)
• Transferred 49.5M THE directly to vTHE contract (bypassing cap)
• Exchange rate inflated 3.81x because contract balance increased without new vTokens minted
• Same position now represented $12M+ in collateral vs original $3.3M
• Borrowed against inflated collateral in recursive loop
• Pumped THE price via buy pressure, borrowed more as oracle caught up
• Got greedy, liquidation triggered, $30M nominal collateral → $0

Root cause

Supply cap only checked in mint(), bypassable via direct ERC-20 transfers. Code4rena flagged this in May 2023 as M-10; Venus dismissed as “supported behavior with no negative side effects.” February 2025 exploit on ZKSync deployment (same vector) was not patched on BNB Chain. This is the 4th Venus exploit in 5 years: institutional memory failure.

What happened

A malicious actor gained unauthorized access to Resolv infrastructure through a compromised private key, minting approximately $80M of tokens. No circuit breakers existed to pause minting when abnormal volumes were detected. A single SERVICE_ROLE key had unilateral mint authority.

Amount Lost

$25M+ (attacker minted $80M, portion recovered)

Parties

Resolv (victim), compromised SERVICE_ROLE key holder, no circuit breaker in place

Category

Missing circuit breakers

Technical Attack Vector

• Attacker compromised infrastructure access (likely via phishing/social engineering)
• Gained control of SERVICE_ROLE key with unilateral mint authority
• No multi-sig requirement on mint function: single key could mint unlimited supply
• No circuit breaker to auto-pause when mint volume exceeded thresholds
• No anomaly detection on mint rate (historical avg vs. attack volume)
• Minted ~$80M in tokens before manual intervention stopped the drain

Root cause

Single point of failure in key management (no SERVICE_ROLE redundancy) combined with complete absence of circuit breakers. The protocol relied entirely on manual monitoring and response, which was too slow to prevent massive dilution.

What happened

Aave’s Correlated Asset Price Oracle (CAPO) had a stale snapshot ratio from 2024. When Chaos Labs’ automated risk engine pushed an update, a rate limiter prevented the ratio from catching up to market rates, causing the oracle to undervalue wstETH by 2.85% and trigger liquidation of healthy positions. 34 accounts were liquidated for a configuration error they had no part in.

Amount Lost

$27.78 million (10,938 wstETH liquidated from 34 accounts)

Parties

Aave (victim), Chaos Labs (risk oracle provider), 34 liquidated users

Category

Oracle manipulation

Technical Attack Vector

• CAPO initialized in 2024 with snapshotRatio of ~1.15 for wstETH/stETH
• Off-chain engine computed correct update: snapshotRatio ~1.2282, timestamp 7 days ago
• On-chain rate limiter capped single updates at 3% per 3 days
• Ratio could only update to ~1.1919, but timestamp updated to 7 days ago
• Formula extrapolated from wrong base: computed ceiling ~1.1939 vs market ~1.2285
• Aave priced wstETH 2.85% below actual value
• E-Mode (high leverage) positions liquidated despite being healthy in real markets
• Similar misconfiguration nearly triggered a month earlier but agent wasn’t connected

Root cause

Configuration mismatch between snapshotRatio and snapshotTimestamp parameters. Rate limiter prevented correction as effectively as it prevented manipulation. Stale 2024 anchor couldn’t catch up to two years of yield growth. Near-miss a month earlier wasn’t investigated thoroughly: institutional memory failure.

What happened

An attacker exploited a community-managed Blend V2 pool by manipulating the price of USTRY, a yield-bearing stablebond with effectively zero market depth. A single trade pumped USTRY 100x on the Stellar DEX, which the VWAP oracle dutifully reported as truth, allowing the attacker to borrow $10.97M against collateral worth ~$160K.

Amount Lost

$10.97 million (1M USDC + 61M XLM)

Parties

YieldBlox/Script3 (victim), Reflector (oracle), Code4rena/Certora (auditors of Blend V2)

Category

Oracle manipulation, Audit scope gaps

Technical Attack Vector

• USTRY/USDC market on SDEX had <$1 in hourly volume, effectively a ghost town
• Attacker placed sell offer for 1.2 USTRY at 107 USDC (100x real price)
• Bought 0.05 USTRY against their own offer: that 50¢ trade became the VWAP
• Reflector oracle reported $106.74 (poisoned) vs real $1.06
• Deposited 153K USTRY (~$160K real) as collateral worth $16M per oracle
• Borrowed 1M USDC + 61M XLM against inflated collateral
• No circuit breaker fired; no deviation check; no staleness flag on dead market

Root cause

Four stacked failures: (1) Illiquid collateral listed without liquidity thresholds, (2) Single-source VWAP oracle with no median/deviation checks, (3) Oracle adapter passed raw last price without validation, (4) No circuit breakers for dead markets. Auditors checked contract logic but never scoped the economic reality of the collateral market.

What happened

An attacker obtained the owner key to IoTeX’s ioTube bridge validator contract. With unchecked upgrade authority, they pushed a malicious contract version, seized control of the TokenSafe and MinterPool, drained $4.4M in real assets, and minted 821M CIOTX tokens. A single EOA held the keys to everything.

Amount Lost

$4.4 million + 821M CIOTX minted (86% frozen by team)

Parties

IoTeX (victim), ioTube bridge (compromised), Specter/PeckShield (on-chain analysts)

Category

Private key compromise

Technical Attack Vector

• Attacker compromised validator owner EOA (0x6dd...148e) after 6-18 months of reconnaissance
• Called upgrade() on TransferValidatorWithPayload contract
• Deployed malicious contract with all validation checks stripped
• No multisig, no timelock, no second signature required for upgrade
• With ownership secured, transferred TokenSafe and MinterPool control
• Drained 9 tokens from reserves: USDC, USDT, WBTC, WETH, IOTX, DAI, PAXG, BUSD, UNI
• Minted 821M CIOTX across 10 transactions via MinterPool

Root cause

Single EOA held unchecked upgrade authority over contracts custodying millions. No multisig requirement, no timelock, no circuit breaker. Architecture assumed the key would never be compromised. IIP-55 (decentralized validator set) was drafted in December 2025, two months before the hack, but not prioritized until after the vault emptied.

What happened

An attacker compromised Step Finance executive devices through a phishing/social engineering attack. Using the stolen keys, they transferred stake authorization to their own wallet, unstaked 261,854 SOL ($27.3M), and drained the treasury. The smart contracts worked flawlessly. The humans failed.

Amount Lost

$27.3 million (261,854 SOL)

Parties

Step Finance (victim), executive team (compromised), CertiK (auditor of contracts)

Category

Private key compromise

Technical Attack Vector

• Attacker gained access to executive team devices (likely via phishing email)
• Transferred stake authorization from Step’s treasury wallets to attacker-controlled address
• Unstaked 261,854 SOL (requires direct wallet permissions on Solana)
• Withdrew all SOL to attacker wallet in single transaction
• Bridge-hopped funds via THORChain to Bitcoin (66.77 BTC parked in 4 wallets)
• Step recovered $4.7M via Token22 protections on Remora assets

Root cause

Weak key management with insufficient access controls. No multi-sig requirement for treasury operations. Single points of failure in signing authority. No monitoring/offline alerting during APAC hours when attack occurred.

What happened

An attacker exploited a 5-year-old unaudited contract with unverified bytecode. By passing astronomical values to the minting function, they triggered an integer overflow in an unprotected addition operation, minting 240M+ TRU tokens for essentially zero cost, then burning them for ETH at a 12.5% buyback rate.

Amount Lost

$26.2 million (8,535 ETH)

Parties

Truebit Protocol (victim), no auditors (code unverified), Banteg (flagged risk in 2021)

Category

Legacy code

Technical Attack Vector

• Target: 5-year-old contract with unverified bytecode (Solidity v0.5.3)
• Attacker reverse-engineered bytecode to find overflow vulnerability
• Called getPurchasePrice() with absurdly large mint amounts
• Unprotected addition overflowed, wrapping to near-zero
• Cost to mint 240M TRU: essentially zero ETH
• Burned tokens for ETH at 12.5% buyback rate (bonding curve mechanic)
• Five iterations in single transaction extracted 8,535 ETH

Root cause

Pre-Solidity 0.8.x compiler without automatic overflow protection. Unverified bytecode meant no community audit. Contract sat dormant for 5 years: a “relic hunter” target. No supply cap or per-transaction limits.

What happened

An attacker compromised Bybit’s Gnosis Safe multisig through a sophisticated supply chain attack. The attacker gained access to the Safe Wallet developer infrastructure, injected malicious JavaScript into the frontend, and intercepted signing requests. When Bybit signers approved what appeared to be legitimate transactions, the malicious code altered the transaction parameters to send funds to attacker-controlled addresses.

Amount Lost

$1.5 billion in ETH and staked ETH derivatives (largest crypto theft in history)

Parties

Bybit (victim), Safe Wallet (compromised infrastructure), Gnosis Safe (multisig contracts)

Category

—

Technical Attack Vector

• Attacker compromised Safe Wallet developer machine or build pipeline
• Injected malicious JavaScript into Safe Wallet web application
• JavaScript intercepted legitimate signing requests from Bybit signers
• Displayed fake transaction details to signers while altering actual payload
• Signers approved what appeared to be routine transfers
• Malicious code substituted attacker addresses in final signed transaction
• Multiple signers approved without detecting the parameter manipulation

Root cause

Supply chain compromise of trusted frontend infrastructure. No code vulnerability in Gnosis Safe contracts: the attack was at the application layer where user interface was compromised to mislead signers about what they were approving.

What happened

A compiler bug in Vyper (versions 0.2.15, 0.2.16, 0.3.0) caused the @nonreentrant decorator to fail when raw_call was used with default_return_value. This allowed reentrancy attacks against multiple Curve pools simultaneously.

Amount Lost

$70+ million (pETH-ETH, msETH-ETH, alETH-ETH, CRV/ETH pools)

Parties

Curve Finance (victim), Vyper compiler (bug source), multiple pool LPs

Category

Reentrancy

Technical Attack Vector

• Attacker identified Curve pools written in Vyper using affected compiler versions
• Vyper’s raw_call with default_return_value had a bug in @nonreentrant
• First call triggered external call to token contract
• Compiler bug: reentrancy lock was not properly set on revert with default return value
• Attacker re-entered pool contract before first call completed
• Manipulated balance calculations during reentrancy window
• Withdrew more than deposited

Root cause

Vyper compiler bug affecting all contracts compiled with versions 0.2.15-0.3.0 using raw_call with default_return_value and @nonreentrant. The reentrancy guard state was reset before external call completed.

What happened

An attacker exploited Euler’s donateToReserves() function combined with liquidation logic. The donation function failed to update the user’s health factor, allowing the attacker to donate away their collateral, become artificially insolvent, then liquidate themselves for profit. All funds later returned by attacker.

Amount Lost

$200 million (all funds returned)

Parties

Euler Finance (victim), Omniscia (auditor), Aave (flash loan source)

Category

Supply cap bypass

Technical Attack Vector

• Flash borrowed 30M DAI from Aave V2
• Deposited into Euler to receive eDAI, then borrowed 10x via leverage
• Called donateToReserves() to donate leveraged eDAI to protocol reserves
• Function failed to update attacker’s health score/accounting
• Attacker now “underwater” according to Euler’s accounting
• Self-liquidated their own position: liquidation awarded massive collateral at discount
• Cycle repeated across multiple assets (DAI, WETH, USDC, stETH)

Root cause

donateToReserves() failed to update user health factor after donation. Created path where attacker could donate away debt collateral (but not their debt), then liquidate themselves for profit on collateral they never truly lost.

What happened

An attacker used a flash loan to acquire majority voting power and passed an emergency governance proposal that drained the protocol treasury. The key vulnerability was that governance tokens were not locked and voting + execution could happen in the same transaction.

Amount Lost

$181 million (attacker kept ~$76M)

Parties

Beanstalk (victim), Omniscia (auditor), Aave/Uniswap/SushiSwap (flash loan sources)

Category

—

Technical Attack Vector

• Flash loaned $1B+ in stablecoins from Aave
• Added liquidity to BEAN Curve pools, acquiring 32M BEAN governance tokens
• Voted on malicious BIP-18 proposal (submitted 1 day earlier)
• Called emergencyCommit() to execute immediately in same transaction
• Proposal transferred all protocol assets to attacker
• Removed liquidity, repaid flash loans, kept ~$76M profit

Root cause

No vote-escrow locking mechanism; governance tokens could be flash-borrowed. Voting and execution in same block allowed atomic governance takeover.

What happened

An attacker exploited Harvest Finance’s yield vaults by manipulating the price of stablecoins within Curve pools. Using a $50 million flash loan, the attacker artificially inflated the price of USDT during deposits and deflated it during withdrawals, extracting more value than deposited.

Amount Lost

$33.8 million (24,830 ETH)

Parties

Harvest Finance (victim), PeckShield / Haechi Labs / CertiK (auditors), Curve Finance (external dependency)

Category

Oracle manipulation

Technical Attack Vector

• The vault calculated share prices using on-chain DEX prices that could be manipulated
• Attacker swapped $11M USDC → USDT on Curve, inflating USDT price
• Deposited 60.6M USDT into vault at inflated price (receiving fewer shares)
• Swapped back, deflating USDT price
• Withdrew at deflated price, receiving more USDT than deposited (~$500K profit per cycle)
• Repeated 32 times in 7 minutes

Root cause

Using manipulable on-chain price sources (Curve’s get_virtual_price) for vault share calculations without sufficient slippage tolerance checks.

What happened

An attacker exploited a reentrancy vulnerability in The DAO’s splitDAO function to recursively drain ether from the contract before the balance could be updated. The attacker called the withdraw function repeatedly before the state change, extracting 3.6M ETH (~$60M at the time). This exploit led to the Ethereum hard fork that created Ethereum Classic.

Amount Lost

3.6M ETH (~$60 million at time of attack, ~$50M+ recovered later)

Parties

The DAO (victim), no formal auditors, Ethereum Foundation (emergency response)

Category

—

Technical Attack Vector

• Attacker identified reentrancy in splitDAO() function
• Created a malicious child DAO contract with fallback function
• Called splitDAO() to withdraw ETH to child DAO
• Child DAO fallback function recursively called splitDAO() again
• Each recursive call transferred ETH before parent call updated balance
• Repeated ~46 times per transaction, draining ~50M ETH per block
• Attacker also recruited others to use same exploit simultaneously

Root cause

Contract sent ETH before updating internal accounting (checks-effects-interactions pattern violation). No reentrancy guards. Fallback functions in child DAO enabled recursive calls back into parent.