2024 EVM Contract Vulnerability Incidents Classification & Analysis.

This database uses the BWC to classify Contract Vulnerability Incidents. Note off-chain issues have been excluded they're the most prevalent and resulted in more values lost. Humans remains to be the weakest point human stupidity or ingenuity(depending on how you look at it) could be infinite. It's unfeasible to track it.

2024-11-10 - 3

  • Date: 2024-11-10
  • Project: BGM Token
  • Value Lost: Unknown (Liquidity Pool Drained)
  • Chain: BSC
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.4.2: Flawed Incentive Structures
    • Secondary Classification: BWC 1.3.8: Sybil Attacks, BWC 5.2.1: Price Manipulation
  • Description: The BGM token was exploited due to a flawed "transfer reward" mechanism. The protocol rewarded users for every transfer, allocating claims to the sender, recipient, and referrers, funded by the project's liquidity pool. An attacker exploited this by conducting a Sybil attack, creating numerous accounts and executing artificial transfers between them to farm rewards. After inflating their BGM holdings, the attacker withdrew the rewards and sold them into the pool, draining the USDT liquidity.
  • References:

2024-11-24 - 2

  • Date: 2024-11-24 (Disclosure Date)
  • Project: Zyfy (PermissionlessPaymaster)
  • Value Lost: $0 (Vulnerability Disclosure)
  • Chain: zkSync
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.2.5: Broken State Adjustment
    • Secondary Classification: BWC 5.1.2: Back-Running
  • Description:
    • A vulnerability was identified in Zyfy's Paymaster contract on zkSync regarding gas refund accounting.
    • The Mechanism: On zkSync, unused gas is refunded to the paymaster. The contract tracked the intended recipient of this pending refund in a state variable called previousManager.
    • The Flaw: The selfRevokeSigner function allowed a user to update previousManager immediately without checking if a refund was pending for a different manager.
    • The Exploit: An attacker could back-run a transaction sponsored by a legitimate manager. By calling selfRevokeSigner immediately after the sponsored transaction (but before the refund logic was finalized by updateRefund in the next interaction), the attacker overwrote previousManager with their own address. Consequently, the gas refund generated by the legitimate manager's transaction was incorrectly credited to the attacker.
  • References:

2024-11-16 - 1

  • Date: 2024-11-16
  • Project: Polter Finance
  • Value Lost: ~$8,700,000
  • Chain: Fantom
  • BWC:
    • Broader Classification: BWC 4: Input & Data Validation Vulnerabilities
    • Primary Classification: BWC 4.2.2: Oracle Manipulation
    • Secondary Classification: BWC 5.2.1: Price Manipulation
  • Description:
    • Polter Finance suffered a classic oracle manipulation attack due to its reliance on spot prices for asset valuation.
    • The Flaw: The protocol determined the price of BOO tokens by averaging the spot prices from SpookySwap V2 and V3 pools. It lacked robust mechanisms like Time-Weighted Average Price (TWAP) or external Chainlink feeds for validation.
    • The Exploit: An attacker used flash loans to massively skew the reserves in the underlying SpookySwap pools, artificially inflating the spot price of BOO. Because Polter's oracle blindly accepted this manipulated data, the system valued the attacker's small BOO deposit at an astronomical rate. This allowed the attacker to borrow effectively all assets held by the protocol against this inflated collateral.
  • References:

2024-10-24 - 6

  • Date: 2024-10-24
  • Project: Ramses Exchange
  • Value Lost: ~$93,000
  • Chain: Arbitrum
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.4.2: Flawed Incentive Structures
    • Secondary Classification: BWC 3.2.5: Broken State Adjustment
  • Description:
    • Ramses Exchange was exploited due to multiple failures in its reward distribution logic for veNFTs.
    • State Adjustment Failure: The protocol failed to decrease the tokenTotalSupplyByPeriod variable when rewards were claimed. This allowed the attacker to claim rewards without reducing the tracked supply, enabling repeated claims.
    • Token ID Manipulation: The attacker bypassed claim limits by minting new veNFTs with new Token IDs, effectively resetting their claim status while using the same underlying capital.
    • Missing Validation: The getPeriodReward function failed to validate that the requested reward period matched the current block timestamp, allowing the attacker to claim rewards for past periods.
  • References:

2024-10-28 - 5

  • Date: 2024-10-28 (Audit Disclosure)
  • Project: Royco Protocol
  • Value Lost: $0 (Critical Audit Finding)
  • Chain: Ethereum, Arbitrum, Base
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.2.8: Faulty Array & List Handling
  • Description:
    • A critical vulnerability was identified in the Royco Protocol's RecipeKernel during a security review.
    • The Flaw: The protocol allowed Incentive Providers (IPs) to create offers with an array of reward tokens (incentivesOffered). However, the system failed to sanitize this array for duplicate token addresses.
    • The Exploit: An attacker could create an offer where the same reward token was listed multiple times (e.g., [USDC, USDC]). When an Action Provider (AP) filled the offer, the contract iterated through this array to distribute rewards. Because the tracking mechanism (incentiveAmountsOffered) summed the total rewards correctly but the distribution loop iterated over the duplicate keys, the system would pay out the full reward amount for each occurrence of the token in the array. This resulted in the AP receiving multiples of the intended reward (e.g., double the amount if listed twice), allowing them to drain funds from the kernel.
  • References:

2024-10-31 - 4

  • Date: 2024-10-31 (Disclosure Date)
  • Project: DeFi Wonderland (opUSDC Bridge)
  • Value Lost: $0 (Vulnerability Disclosure)
  • Chain: OP Stack Chains
  • BWC:
    • Broader Classification: BWC 8: Denial of Service (DoS) Vulnerabilities
    • Primary Classification: BWC 8.8: DoS in Cross-Chain Messaging Protocols
    • Secondary Classification: BWC 10.4: Protocol Upgrade-Induced Vulnerabilities
  • Description:
    • A critical DoS vulnerability was identified in the opUSDC bridging standard, specifically regarding the migration path from "Bridged USDC" to "Native USDC."
    • The Mechanism: Bridging involves locking USDC on L1 and minting it on L2. If the L2 mint fails (e.g., Out Of Gas), the message is queued and can be replayed later.
    • The Flaw: The protocol allows for a "Migration" event where the L2 USDC token ownership is transferred to Circle to become native. Crucially, this revokes the Bridge Adapter's permission to mint.
    • The Lock: If a user has a pending/failed L2 mint transaction at the moment the migration occurs, the Bridge Adapter loses its minting rights before the user can replay the transaction. The replay will permanently revert (due to missing permissions), leaving the user's funds irretrievably locked in the L1 bridge contract.
  • References:

2024-10-05 - 3

  • Date: 2024-10-05
  • Project: AIZPT (AIZPT314)
  • Value Lost: ~$20,000
  • Chain: BSC
  • BWC:
    • Broader Classification: BWC 6: Arithmetic & Numeric Vulnerabilities
    • Primary Classification: BWC 6.4: Calculation Errors
    • Secondary Classification: BWC 5.2.1: Price Manipulation
  • Description:
    • The AIZPT314 token contract was exploited due to a fundamental mathematical error in its custom trading logic.
    • The Flaw: The protocol implemented a flawed pricing formula (token0Out = token1In * token0InContract / (token1In + token1InContract)) for swapping BNB for AIZPT. This implementation effectively used a quote-like or simplified formula that did not correctly account for slippage or align with the sell-side formula (which used standard Uniswap V2 logic).
    • The Exploit: This discrepancy created a massive arbitrage opportunity. An attacker flashloaned BNB, bought AIZPT at the undervalued "linear" rate defined by the flawed buy formula, and then sold it back using the standard curve logic (or simply traded back and forth), extracting the contract's liquidity.
  • References:

2024-10-10 - 2

  • Date: 2024-10-10
  • Project: HYDT
  • Value Lost: ~$5,800
  • Chain: BSC
  • BWC:
    • Broader Classification: BWC 5: Economic & Game-Theoretic Vulnerabilities
    • Primary Classification: BWC 5.2.1: Price Manipulation
    • Secondary Classification: BWC 4.2.1: Insufficient Oracle Validation
  • Description: The HYDT token system was exploited via a price manipulation attack on its InitialMint contract. The contract allowed users to mint HYDT tokens by depositing BNB, with the exchange rate determined directly by the WBNB/USDT spot price on PancakeSwap. An attacker utilized a flash loan to borrow USDT and buy a large amount of WBNB, drastically skewing the spot price. They then deposited BNB into the InitialMint contract at this manipulated rate to mint an inflated amount of HYDT tokens, which were subsequently sold for a profit.
  • References:

2024-10-15 - 1

  • Date: 2024-10-15
  • Project: Uniswap V4 Core
  • Value Lost: $0 (Critical Audit Finding)
  • Chain: Celo (and EVM chains where Native Token = ERC20)
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.3.1: Double EntryPoint Tokens
    • Secondary Classification: BWC 3.3.3: Improper Handling of Native Tokens
  • Description:
    • A critical vulnerability was uncovered during the audit of Uniswap V4 involving chains where the native currency also exists as an ERC-20 token (Double EntryPoint), such as CELO on Celo.
    • The Mechanism: The protocol's settle function calculates debt (deltas) differently for native assets (using msg.value) and ERC-20 tokens (using balanceNow - balanceBefore).
    • The Exploit: An attacker could exploit this dual nature by first calling sync to snapshot balances, then calling settle sending native value (increasing the delta via msg.value). Crucially, this action also increases the contract's ERC-20 balance. The attacker could then immediately call settle again using the token's ERC-20 address. The contract would interpret the previous msg.value deposit as a new ERC-20 transfer (since balanceNow > balanceBefore), effectively crediting the user twice for the same funds.
    • Impact: This accounting flaw would allow an attacker to inflate their balance artificially and drain the pool's liquidity without transferring the corresponding assets.
  • References:

2024-09-25 - 7

  • Date: 2024-09-25 (Disclosure Date)
  • Project: Fuel Network (Fuel VM)
  • Value Lost: $0 (Critical Vulnerability Disclosure)
  • Chain: Fuel
  • BWC:
    • Broader Classification: BWC 7: Low-Level & EVM-Specific Vulnerabilities
    • Primary Classification: BWC 7.4.1: Incorrect VM Gas Charges
    • Secondary Classification: BWC 8.4: DoS via Numeric Calculation (Resource Exhaustion)
  • Description:
    • A critical vulnerability was identified in the Fuel VM's CCP (Code Copy) instruction during the Fuel Attackathon.
    • The Flaw: The CCP instruction copies code from a contract into memory but charged gas based solely on the size of the source contract's bytecode, not the actual number of bytes copied or the memory region affected. Furthermore, if the destination memory region exceeded the source bytecode size, the instruction would zero-fill the excess area.
    • The Exploit: An attacker could manipulate the offset and length parameters to trigger a massive memory zero-filling operation (a resource-intensive task) while paying a negligible gas fee calculated only on the small contract size. This discrepancy allowed for "cheap" memory clearing, leading to potential network resource exhaustion and Denial of Service (DoS) attacks by underpricing computational work.
  • References:

2024-09-10 - 6

  • Date: 2024-09-10
  • Project: Pythia Finance
  • Value Lost: ~$53,000
  • Chain: Ethereum Mainnet
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.4.2: Flawed Incentive Structures
    • Secondary Classification: BWC 6.4: Calculation Errors
  • Description: The Pythia Finance staking contract contained a critical logic error in its reward calculation. The formula calculated rewards by simply multiplying the user's current balance by an accumulating rewards-per-share global variable. Crucially, it failed to subtract the "debt" (rewards accumulated before the user staked), effectively acting as if the user had been staking since the protocol's inception. This allowed an attacker to deposit a large amount, immediately claim massive rewards proportional to the protocol's lifetime history, and exit.
  • References:

2024-09-03 - 5

  • Date: 2024-09-03
  • Project: Penpie
  • Value Lost: ~$27,000,000
  • Chain: Ethereum, Arbitrum
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.1.1: Standard Reentrancy
    • Secondary Classification: BWC 4.1.1: Insufficient Input Validation
  • Description:
    • Penpie, a yield optimizer built on Pendle Finance, was exploited via a sophisticated reentrancy attack enabled by the permissionless registration of new markets.
    • The Setup: The attacker registered a valid Pendle market but linked it to a malicious custom token (SY contract). They then triggered batchHarvestMarketRewards.
    • The Reentrancy: This function calculated rewards by checking token balances before and after calling redeemRewards. During the redeemRewards call, the malicious token's transfer logic handed execution control back to the attacker.
    • The Exploit: Inside this reentrancy window, the attacker called depositMarket to deposit a large amount of funds. This legitimate deposit increased the protocol's token balance. When the execution returned to the harvest function, it read the now-inflated "after" balance. The protocol incorrectly interpreted the difference (which included the attacker's deposit) as massive rewards earned, distributing them to the attacker.
  • References:

2024-09-26 - 4

  • Date: 2024-09-26
  • Project: Onyx Protocol
  • Value Lost: ~$3,800,000
  • Chain: Ethereum Mainnet
  • BWC:
    • Broader Classification: BWC 6: Arithmetic & Numeric Vulnerabilities
    • Primary Classification: BWC 6.2: Precision Loss & Rounding Errors
    • Secondary Classification: BWC 4.1.1: Insufficient Input Validation
  • Description:
    • Onyx Protocol, a fork of Compound V2, was exploited in a repeat of the "empty market" attack.
    • Precision Loss (Inflation): The protocol launched a new, low-liquidity market (VUSD) without burning initial liquidity ("dead shares"). An attacker exploited the known Compound V2 exchange rate calculation vulnerability by continuously minting and redeeming tiny amounts of shares. This process manipulated the exchange rate due to rounding errors, allowing the attacker to borrow assets worth far more than their collateral.
    • Input Validation Failure: Additionally, the attacker exploited a vulnerability in Onyx's custom NFTLiquidation contract. The contract failed to validate input parameters during the liquidation process, allowing the attacker to use a fake token or manipulated data to self-liquidate positions and claim inflated rewards, exacerbating the loss.
  • References:

2024-09-01 - 3

  • Date: 2024-09-01 (Incident Month)
  • Project: Maia DAO
  • Value Lost: $0 (Funds Rescued / ~$1.2M At Risk)
  • Chain: Arbitrum, Metis (Multichain)
  • BWC:
    • Broader Classification: BWC 2: Access Control Vulnerabilities
    • Primary Classification: BWC 2.1.1: Missing Access Control
    • Secondary Classification: BWC 3.2.7: Broken Invariant via Function Overriding
  • Description:
    • A critical vulnerability was discovered in Maia DAO's CoreBranchRouter contract. The flaw stemmed from a failure to override a virtual function (callOut) in the deployed contract. The parent contract's default implementation of this function lacked the specific access controls required for the live system, as it was intended to be overridden by the child contract with proper restrictions.
    • The Exploit Vector: This "missing override" oversight meant the public, unsecured parent function was exposed. It would have allowed an attacker to call the function and impersonate a trusted CoreBranchRouter, enabling them to bypass security checks and drain funds from the CoreRootRouter or brick the system.
    • Outcome: The vulnerability was identified by a whitehat hacker, and the Maia DAO team successfully executed a rescue operation to secure the ~$1.2M at risk before any malicious exploitation occurred.
  • References:

2024-09-23 - 2

  • Date: 2024-09-23
  • Project: Bankroll Network
  • Value Lost: ~$235,000
  • Chain: BSC
  • BWC:
    • Broader Classification: BWC 4: Input & Data Validation Vulnerabilities
    • Primary Classification: BWC 4.1.1: Insufficient Input Validation
    • Secondary Classification: BWC 6.1: Integer Overflow & Underflow
  • Description: The BankrollNetworkStack contract was exploited due to a critical input validation failure in the buyFor function. The function allowed users to purchase shares on behalf of another address (_customerAddress) but failed to validate that this address was not the vault contract itself. An attacker exploited this by repeatedly calling buyFor with the vault's address as the customer, using the vault's own balance to simulate "buys". This artificially inflated the profitPerShare and the dividends attributed to the attacker (via the "divs" mechanism), allowing them to withdraw an inflated amount of WBNB, draining the pool.
  • References:

2024-09-27 - 1

  • Date: 2024-09-27
  • Project: Bedrock (uniBTC)
  • Value Lost: ~$1,700,000
  • Chain: Ethereum
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.3.3: Improper Handling of Native Tokens
    • Secondary Classification: BWC 3.2.2: Faulty Contract Checks
  • Description:
    • The Bedrock protocol was exploited due to a critical flaw in how it handled native tokens on non-Bitcoin chains (e.g., ETH on Ethereum).
    • The Mechanism: The system allowed minting uniBTC at a 1:1 ratio against BTC-equivalent assets. To prevent minting against non-equivalent assets (like ETH), the protocol set a cap of 0 for those assets.
    • The Flaw: The totalSupply function, used to enforce this cap, mistakenly returned 0 for the NATIVE_BTC address because the native token was not properly registered in the SigmaSupplier contract.
    • The Exploit: This logic error meant the check totalSupply <= cap evaluated to 0 <= 0 (True), bypassing the restriction. An attacker was able to deposit ETH (valued much lower than BTC) and mint uniBTC at a 1:1 ratio, effectively buying Bitcoin for the price of Ether and draining the protocol's liquidity.
  • References:

2024-08-06 - 6

  • Date: 2024-08-06
  • Project: Ronin Bridge
  • Value Lost: ~$12,000,000 (Returned by Whitehats)
  • Chain: Ethereum / Ronin
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.2.1: Improper Initialization
    • Secondary Classification: BWC 2.1.1: Missing Access Control
  • Description:
    • The Ronin Bridge was exploited due to a critical initialization failure during a contract upgrade.
    • The Flaw: The development team upgraded the bridge proxy from version 2 to version 4 but neglected to call the intermediate initializeV3 function. This function was responsible for initializing the _totalOperatorWeight variable.
    • The Impact: Because the initialization was skipped, _totalOperatorWeight defaulted to 0. The bridge's logic checked if the weight of provided signatures met the threshold derived from this variable. With the threshold effectively set to zero, the contract accepted empty or invalid signatures as valid authorization for withdrawals. This allowed an MEV bot (acting as a whitehat) to front-run an attack and withdraw ~$12M in ETH and USDC, effectively bypassing the bridge's multi-signature security.
  • References:

2024-08-13 - 5

  • Date: 2024-08-13
  • Project: VOW
  • Value Lost: ~$1,200,000
  • Chain: Ethereum Mainnet
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.2.5: Broken State Adjustment
    • Secondary Classification: BWC 5.1.2: Back-Running
  • Description:
    • The VOW token was exploited due to a critical operational security failure involving non-atomic testing in production.
    • The Flaw: The development team attempted to test a configuration change by sending a transaction to modify a critical parameter (setting the usd variable to the vow token address) with the intention of reverting it in a subsequent transaction. This created a temporal gap where the contract was live on mainnet in an invalid, vulnerable state.
    • The Exploit: An attacker monitored the mempool, observed the configuration change, and back-ran the transaction. Within the window before the team could revert the change, the attacker exploited the "abnormal" state—where the system treated VOW as the stable peg—to mint 100 million vUSD tokens, which were then dumped for profit.
  • References:

2024-08-30 - 4

  • Date: 2024-08-30 (Audit Disclosure)
  • Project: Uniswap V4 Periphery
  • Value Lost: $0 (Critical Audit Finding)
  • Chain: EVM (Uniswap V4)
  • BWC:
    • Broader Classification: BWC 8: Denial of Service (DoS) Vulnerabilities
    • Primary Classification: BWC 8.11: DoS via Front-Running (Griefing)
    • Secondary Classification: BWC 5.1.1: Front-Running
  • Description:
    • A Denial of Service vulnerability was identified in the Uniswap V4 Periphery contracts regarding the integration of Permit2 within multicalls.
    • The Flaw: The contracts allowed users to bundle a Permit2 signature approval (permit) alongside other actions (like addLiquidity or swap) in a single multicall transaction. The code expected the permit call to execute successfully.
    • The Exploit: An attacker could observe the pending multicall transaction, extract the valid Permit2 signature, and front-run the transaction by submitting the signature directly to the Permit2 contract. This consumes the signature's nonce. When the user's multicall transaction attempts to execute the permit, it reverts because the nonce has already been used. Since the multicall relies on all sub-calls succeeding, the entire transaction (including the intended swap or deposit) fails.
  • References:

2024-08-29 - 3

  • Date: 2024-08-29 (Disclosure Date)
  • Project: Alchemix Finance
  • Value Lost: $0 (Critical Vulnerability Disclosure)
  • Chain: Ethereum
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.2.8: Faulty Array & List Handling
  • Description:
    • A critical vulnerability was identified in Alchemix's VotingEscrow contract regarding how it handled historical data lookups.
    • The Flaw: The protocol used a binary search algorithm to retrieve historical voting power or supply from a pointHistory array based on timestamps. However, the system allowed multiple checkpoints to be created with the exact same timestamp (e.g., within the same block). The binary search implementation was not designed to handle these duplicate keys; it would stop at the first match it found rather than the latest (right-most) entry.
    • The Exploit: An attacker could strategically create multiple checkpoints at a specific timestamp to insert duplicate entries. By manipulating which entry the binary search returned (due to its non-deterministic handling of duplicates), the attacker could force the contract to use stale or manipulated data, potentially inflating their voting power or influencing governance outcomes.
  • References:

2024-08-30 - 2

  • Date: 2024-08-30 (Audit Disclosure)
  • Project: Superposition AMM
  • Value Lost: $0 (Critical Audit Finding)
  • Chain: Superposition (EVM)
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.3.5: EIP Standard Non-Compliance
    • Secondary Classification: BWC 2.2.1: Unsafe Token Approvals
  • Description:
    • A critical vulnerability was identified in the OwnershipNFTs.sol contract during an audit.
    • The Flaw: The contract implemented a custom version of the ERC-721 standard but failed to adhere to a specific requirement: clearing the getApproved address (token level approval) upon a token transfer.
    • The Exploit: An attacker (Token Owner) could approve the NFT to a secondary address they control, sell the NFT to a victim, and then—because the approval was not revoked during the transfer—use the secondary address to call transferFrom and steal the NFT back from the buyer immediately.
  • References:

2024-08-30 - 1

  • Date: 2024-08-30 (Audit Disclosure)
  • Project: Uniswap V4 Periphery
  • Value Lost: $0 (Critical Audit Finding)
  • Chain: EVM (Uniswap V4)
  • BWC:
    • Broader Classification: BWC 6: Arithmetic & Numeric Vulnerabilities
    • Primary Classification: BWC 6.3: Unsafe Type Casting
    • Secondary Classification: BWC 4.1.1: Insufficient Input Validation
  • Description:
    • A high-severity vulnerability was identified in the Uniswap V4 Periphery during an audit. The flaw existed in the validateMinOut function, which is responsible for enforcing slippage protection.
    • The Flaw: The function performed an unsafe cast from int128 (liquidity delta) to uint128. In Uniswap V4, hooks can return a negative liquidityDelta. When a negative value is cast directly to an unsigned integer, it underflows and wraps around to a massive positive number (e.g., casting -1 results in 2^128 - 1).
    • The Exploit: An attacker could exploit this by interacting with a hook that returns a negative delta. The unsafe cast would incorrectly interpret this as a massive liquidity increase, bypassing the minimum output check (slippage protection) because the system would believe the user received a huge amount of assets.
    • Mitigation: The issue was resolved by using SafeCast.toUint128, which correctly reverts if the value is negative.
  • References:

2024-07-23 - 2

  • Date: 2024-07-23
  • Project: Delta Prime
  • Value Lost: ~$1,000,000
  • Chain: Arbitrum
  • BWC:
    • Broader Classification: BWC 7: Low-Level & EVM-Specific Vulnerabilities
    • Primary Classification: BWC 7.2.1: Unsafe Storage Use
    • Secondary Classification: BWC 3.2.1: Improper Initialization
  • Description:
    • Delta Prime was exploited due to a critical storage collision vulnerability inherent in its proxy architecture, compounded by a forgotten initialization function.
    • The Architecture: The project used a DiamondBeaconProxy pattern. User "Prime Accounts" were clones that delegatecalled to a DiamondBeacon, which then delegated to implementation facets.
    • The Flaw: Both the Prime Account proxy and the Diamond contract utilized the same storage slot to store the owner address. However, they used different storage slots to track their initialized status. Additionally, the developers failed to remove or protect the init function on the DiamondBeacon after deployment.
    • The Exploit: An attacker invoked the init function on other users' Prime Accounts. This call was delegated to the Diamond's init logic. Because the Diamond checked a different initialized storage slot (which was empty in the context of the Proxy), the check passed. The function then overwrote the owner storage slot—which was shared by the Proxy—granting the attacker full control over the victims' Prime Accounts and allowing them to drain funds.
  • References:

2024-07-23 - 4

  • Date: 2024-07-23
  • Project: Spectra Finance
  • Value Lost: ~$73,000
  • Chain: Ethereum Mainnet
  • BWC:
    • Broader Classification: BWC 2: Access Control Vulnerabilities
    • Primary Classification: BWC 2.2.4: Composable Arbitrary Calls
    • Secondary Classification: BWC 2.2.1: Unsafe Token Approvals
  • Description:
    • Spectra Finance was exploited due to an arbitrary call vulnerability within its router's swap logic.
    • The Flaw: The protocol allowed users to execute trades via KyberSwap, but failed to validate the kyberRouter address and the targetData payload passed to the _dispatch function (command type 0x12).
    • The Exploit: An attacker exploited this by passing the asdCRV token address as the kyberRouter and encoding a transferFrom call in the targetData. Since the Spectra router executed this call as itself, and users had previously approved the Spectra router to spend their asdCRV tokens, the attacker was able to drain funds from user wallets directly to their own.
  • References:

2024-07-16 - 3

  • Date: 2024-07-16
  • Project: Li.Fi (Jumper Exchange)
  • Value Lost: ~$11,600,000
  • Chain: Ethereum, Arbitrum
  • BWC:
    • Broader Classification: BWC 2: Access Control Vulnerabilities
    • Primary Classification: BWC 2.2.4: Composable Arbitrary Calls
    • Secondary Classification: BWC 2.2.1: Unsafe Token Approvals
  • Description:
    • The Li.Fi DEX aggregator was exploited due to a critical arbitrary call vulnerability in a newly deployed facet.
    • The Flaw: The protocol introduced a feature allowing users to deposit tokens and specify a route for swapping. However, the contract failed to sanitize the target address and callData provided by the user.
    • The Exploit: An attacker crafted a malicious route where the target was a popular token contract (e.g., USDT, USDC) and the callData was a transferFrom call. Since the Li.Fi contract executed this call, and many users had granted infinite approvals to the Li.Fi contract, the attacker was able to use the protocol as a "confused deputy" to drain tokens directly from users' wallets into their own.
  • References:

2024-07-12 - 2

  • Date: 2024-07-12
  • Project: Dough Finance
  • Value Lost: ~$1,800,000
  • Chain: Ethereum Mainnet
  • BWC:
    • Broader Classification: BWC 2: Access Control Vulnerabilities
    • Primary Classification: BWC 2.3.1: Missing Validation in Callbacks
    • Secondary Classification: BWC 4.1.1: Insufficient Input Validation
  • Description: The ConnectorDeleverageParaswap contract was exploited due to a critical validation failure in its flashloan callback execution. Users could initiate a flashloan via flashloanReq and provide a swapData parameter, intended to specify trade details for a ParaSwap interaction. This data was passed through to the executeOperation callback. However, the callback logic (deloopAllCollaterals) failed to validate or sanitize this user-supplied data. This allowed an attacker to craft malicious swapData that, instead of executing a swap, triggered a direct WETH.transferFrom call, stealing assets that users had approved to the contract.
  • References:

2024-07-24 - 1

  • Date: 2024-07-24
  • Project: Compound DAO
  • Value Lost: $0 (Governance Takeover Averted; ~$25M Assets at Risk)
  • Chain: Ethereum
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.4.1: DAO Governance Attacks
    • Secondary Classification: BWC 1.3.1: Social Engineering Exploits
  • Description:
    • The Compound DAO faced a hostile governance takeover attempt by a group known as the "GoldenBoyz." The attack aimed to pass Proposal 289, which sought to transfer 499k COMP tokens ($25M) from the treasury to a vault, while simultaneously delegating the voting power of those tokens to the proposers.
    • Governance Exploit: Given Compound's low voter turnout (4-5%), gaining control of these tokens (5% of supply) would have allowed the attackers to unilaterally dictate future governance outcomes.
    • Social Engineering & Timing: The attackers used failed "test" proposals (247 and 279) to gauge community resistance. For the final malicious proposal, they employed "stealth voting," casting the majority of "for" votes at the very end of the voting window to limit the community's ability to react.
    • Mitigation: The proposal passed, but the community responded with Proposal 290 to move administrative control to a Community Multisig. A truce was eventually reached, and the immediate threat to the protocol's governance was neutralized.
  • References:

2024-06-25 - 1

  • Date: 2024-06-25 (Audit Disclosure)
  • Project: Taiko (Bridge)
  • Value Lost: $0 (Critical Audit Finding)
  • Chain: Taiko / Ethereum
  • BWC:
    • Broader Classification: BWC 4: Input & Data Validation Vulnerabilities
    • Primary Classification: BWC 4.5.1: Parser Differential / Inconsistent Validation
    • Secondary Classification: BWC 2.2.4: Composable Arbitrary Calls
  • Description:
    • A critical vulnerability was discovered in Taiko's bridge message processing logic during an audit, exemplifying a Parser Differential bug.
    • The Mechanism: The bridge handled cross-chain messages via two distinct paths: processMessage (immediate execution) and retryMessage (delayed execution for rate-limited messages).
    • The Flaw: The immediate execution path correctly validated inputs to prevent calls to forbidden addresses. However, the retryMessage path inconsistently applied these validations, skipping the forbidden address check entirely.
    • The Exploit: An attacker could intentionally trigger the rate limit to force a malicious message into the "Retriable" state. They could then execute the message via the vulnerable retryMessage path, bypassing the security checks. This would allow them to execute arbitrary calls (like transferFrom) against forbidden targets (like token contracts) with the Bridge acting as msg.sender.
  • References:

2024-06-10 - 5

  • Date: 2024-06-10
  • Project: UWU Lend
  • Value Lost: ~$19,300,000
  • Chain: Ethereum Mainnet
  • BWC:
    • Broader Classification: BWC 5: Economic & Game-Theoretic Vulnerabilities
    • Primary Classification: BWC 5.2.1: Price Manipulation
    • Secondary Classification: BWC 5.2.4: Over-Leverage & Liquidation Spirals
  • Description:
    • UWU Lend was exploited due to a combination of fragile economic parameters and oracle manipulation.
    • The Flaw (Over-Leverage): The protocol configured the sUSDE market with a Liquidation Threshold of 90% and a Liquidation Bonus of 10%. This left effectively zero margin for error (90% + 10% = 100%).
    • The Exploit (Price Manipulation): An attacker manipulated the price of the collateral asset (sUSDE) down by just ~4% using a flash loan and curve pool imbalances. Because of the aggressive LTV parameters, this minor fluctuation allowed the attacker to liquidate their own position profitably. They could borrow assets, trigger the liquidation, and receive the 10% bonus which, combined with the manipulated price, exceeded the debt repayment cost, draining the protocol.
  • References:

2024-06-19 - 4

  • Date: 2024-06-19 (Audit Disclosure)
  • Project: Linea (PLONK Go Prover)
  • Value Lost: $0 (Critical Audit Finding)
  • Chain: Linea (Layer 2)
  • BWC:
    • Broader Classification: BWC 7: Low-Level & EVM-Specific Vulnerabilities
    • Primary Classification: BWC 7.3.4: Forgetting to Blind Polynomials in ZK Protocols
  • Description:
    • A critical cryptographic vulnerability was identified in Linea's PLONK Go Prover implementation during a security audit.
    • The Theory: In ZK-SNARKs, provers generate polynomials to represent secret data (the witness). To prevent the verifier from reconstructing these polynomials (and thus learning the secret) via the revealed evaluations, the polynomials must be "blinded" by adding random coefficients.
    • The Flaw: The Linea implementation split the quotient polynomial into "shards" but failed to apply blinding to these individual shards.
    • The Impact: Without this blinding, the evaluations provided during the proof generation process leaked excessive information. This could allow an attacker to statistically reconstruct the polynomial and recover the secret witness, completely compromising the zero-knowledge property of the system.
  • References:

2024-06-11 - 3

  • Date: 2024-06-11 (Audit Disclosure)
  • Project: Opal Protocol (Omnipool)
  • Value Lost: $0 (Critical Audit Finding)
  • Chain: Ethereum
  • BWC:
    • Broader Classification: BWC 5: Economic & Game-Theoretic Vulnerabilities
    • Primary Classification: BWC 5.3.1: Lack of Slippage Control
    • Secondary Classification: BWC 5.1.3: Sandwich Attacks
  • Description:
    • A critical vulnerability was identified in the Opal Omnipool's reward claiming logic during a security review.
    • The Flaw: When users claimed rewards, the contract executed a Balancer.batchSwap to convert tokens. However, the function call failed to specify a minimum output amount (limits), effectively accepting 100% slippage.
    • The Exploit: An attacker could exploit this by monitoring the mempool for reward claim transactions. They could "sandwich" the transaction by front-running it to manipulate the pool's price and back-running it to capture the slippage. This would allow the attacker to siphon off a significant portion, if not all, of the user's rewards.
  • References:

2024-06-20 - 2

  • Date: 2024-06-20 (Audit Disclosure)
  • Project: Boost AA Wallet
  • Value Lost: $0 (Critical Audit Finding)
  • Chain: EVM (Optimism, Base, etc.)
  • BWC:
    • Broader Classification: BWC 7: Low-Level & EVM-Specific Vulnerabilities
    • Primary Classification: BWC 7.3.1: Weak Random Number Generation
    • Secondary Classification: BWC 1.4.1: Compromised Validator/Node (Context: Validator manipulation)
  • Description:
    • A critical vulnerability was identified in the Boost AA Wallet's raffle mechanism during an audit.
    • The Flaw: The protocol determined raffle winners using block.prevrandao and block.timestamp as the sole sources of randomness.
    • The Exploit: While these values are hard for a regular user to predict in advance, a malicious validator (or a sequencer in L2 contexts) has control over block production. They could simulate the raffle result for a pending block and choose to withhold the block or reorganize transactions if the outcome is not favorable, effectively "re-rolling" the dice until they win.
  • References:

2024-06-14 - 1

  • Date: 2024-06-14 (Public Disclosure)
  • Project: Alchemix
  • Value Lost: $0 (Bounty Paid: ~$28,730)
  • Chain: Ethereum Mainnet
  • BWC:
    • Broader Classification: BWC 2: Access Control Vulnerabilities
    • Primary Classification: BWC 2.1.1: Missing Access Control
    • Secondary Classification: BWC 5.1.3: Sandwich Attacks
  • Description: A high-severity vulnerability was identified in Alchemix's yield harvesting logic involving its integration with Gelato. The protocol intended to mitigate sandwich attacks during yield unwrapping by restricting the harvest function—which accepts a minimumAmountOut parameter—to be callable only by the Gelato Automate contract. However, Alchemix integrated the generic, public Gelato Automate contract rather than a dedicated proxy. Because the generic contract allows any user to schedule tasks, an attacker could have scheduled a task instructing Gelato to call harvest with minimumAmountOut set to zero. This would satisfy the msg.sender check (as the call comes from Gelato) while allowing the attacker to sandwich the transaction and steal the harvested yield.
  • References:

2024-05-20 - 7

  • Date: 2024-05-20 (Audit Disclosure)
  • Project: Elfi Protocol
  • Value Lost: $0 (Critical Audit Finding)
  • Chain: Arbitrum
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.4.2: Flawed Incentive Structures
    • Secondary Classification: BWC 3.2.5: Broken State Adjustment
  • Description:
    • A critical vulnerability was identified in the Elfi Protocol's staking mechanism during a Sherlock audit.
    • The Flaw: The protocol issued transferable stakeToken (st) as proof of deposit but calculated rewards based on the account's current st balance rather than an internal, non-transferable staking record.
    • The Exploit: This created a "double-dipping" vulnerability. An attacker could stake tokens in Account A, transfer the st tokens to Account B, and claim rewards on Account B. They could then transfer the st tokens back to Account A (or to Account C) and claim rewards again for the same time period, effectively multiplying the yield generated by a single deposit.
  • References:

2024-05-27 - 6

  • Date: 2024-05-27
  • Project: RedKeysGame
  • Value Lost: ~$10,000
  • Chain: BSC
  • BWC:
    • Broader Classification: BWC 7: Low-Level & EVM-Specific Vulnerabilities
    • Primary Classification: BWC 7.3.1: Weak Random Number Generation
  • Description: The RedKeysGame contract was exploited due to a Weak RNG vulnerability. The contract determined the winner of a betting game by deriving a "random" number from predictable on-chain variables, including the block's timestamp, prevrandao (difficulty), gaslimit, coinbase, and number. An attacker deployed a malicious contract that pre-calculated the result using these same publicly available values before submitting the bet in the same transaction block. This allowed the attacker to guarantee a win every time, draining the contract's funds.
  • References:

2024-05-16 - 5

  • Date: 2024-05-16
  • Project: TCH Token
  • Value Lost: ~$18,000
  • Chain: BSC
  • BWC:
    • Broader Classification: BWC 7: Low-Level & EVM-Specific Vulnerabilities
    • Primary Classification: BWC 7.3.2: Malleable ecrecover
    • Secondary Classification: BWC 5.2.1: Price Manipulation
  • Description:
    • The TCH token contract was exploited due to a "CTF-style" signature malleability vulnerability.
    • The Flaw: The burnToken function used ecrecover to validate signatures from an authorized signer. Crucially, the replay protection mechanism tracked the uniqueness of the signature bytes rather than the message digest or a nonce.
    • The Exploit: An attacker harvested valid, previously used signatures and modified the v value (e.g., from 0x01 to 0x1c). Due to the malleability of ECDSA signatures in Ethereum (where s and -s mod n are both valid), ecrecover resolved this modified signature to the same authorized signer. However, because the signature bytes were technically different, it bypassed the contract's "already used" check.
    • The Impact: The attacker replayed these burn authorizations to burn a significant amount of TCH tokens held by the PancakeSwap liquidity pair. This artificially inflated the token price, allowing the attacker to sell their holdings for a profit.
  • References:

2024-05-28 - 4

  • Date: 2024-05-28 (Audit Disclosure)
  • Project: Scroll (Batch Token Bridge)
  • Value Lost: $0 (Critical Audit Finding)
  • Chain: Ethereum
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.1.2: ERC-777 Reentrancy
    • Secondary Classification: BWC 3.2.1: Improper Initialization (Related to configuration, but not the primary exploit)
  • Description:
    • A critical reentrancy vulnerability was identified in the Scroll Batch Token Bridge during an audit.
    • The Flaw: The depositERC20 function initiated a token transfer using safeTransferFrom before calling the internal _deposit function. Crucially, the nonReentrant modifier was placed on the internal _deposit function rather than the external depositERC20 entry point.
    • The Exploit: An attacker using a token with sender hooks (such as ERC-777 or compliant ERC-20s with callbacks) could re-enter the depositERC20 function during the safeTransferFrom call. Because the execution flow had not yet reached the _deposit function where the guard resided, the reentrancy check was bypassed. This allowed the attacker to stack multiple deposits in a single transaction, potentially inflating their credited amount on L2 or locking funds in the bridge.
  • References:

2024-05-29 - 3

  • Date: 2024-05-29
  • Project: Scroll Token (Custom Token on Scroll L2)
  • Value Lost: Token Price Plunged ~99% (Amount Unknown)
  • Chain: Scroll
  • BWC:
    • Broader Classification: BWC 6: Arithmetic & Numeric Vulnerabilities
    • Primary Classification: BWC 6.1: Integer Overflow & Underflow
  • Description: The "Scroll Token" (a custom ERC-20 token deployed on the Scroll network, not the network's native token) was exploited due to a classic integer underflow. The developers placed a subtraction operation within an unchecked block to optimize gas, assuming the "from" balance was sufficient. However, the logic allowed a transfer from an address with a zero balance to underflow, wrapping around to the maximum uint256 value. This allowed the attacker to mint a massive amount of tokens and dump them, crashing the price.
  • References:

2024-05-10 - 2

  • Date: 2024-05-10
  • Project: Galaxy Fox
  • Value Lost: ~$330,000
  • Chain: Ethereum Mainnet
  • BWC:
    • Broader Classification: BWC 2: Access Control Vulnerabilities
    • Primary Classification: BWC 2.1.1: Missing Access Control
  • Description: The Galaxy Fox token contract was exploited due to a critical access control failure in its airdrop logic. The protocol used a Merkle Tree to distribute tokens, but the setMerkleRoot function—intended for admin use to update the eligible claim list—was left public with no authorization checks. An attacker called this function to overwrite the legitimate root with a malicious one, for which they possessed a valid leaf path. This allowed them to fraudulently claim a massive amount of GFOX tokens, which they immediately swapped for ETH in the Uniswap pool.
  • References:

2024-05-10 - 1

  • Date: 2024-05-10
  • Project: TSURU
  • Value Lost: ~$410,000
  • Chain: Base
  • BWC:
    • Broader Classification: BWC 2: Access Control Vulnerabilities
    • Primary Classification: BWC 2.3.1: Missing Validation in Callbacks
  • Description: The TSURUWrapper contract was exploited due to a critical validation failure in its onERC1155Received hook. This function is a standard callback intended to be triggered only by the TSURU token contract upon a safe transfer. However, the function lacked a check to verify that msg.sender was the actual token contract. This allowed an attacker to call the hook directly, spoofing a deposit and minting unlimited tokens to themselves, which were then used to drain the Uniswap pool.
  • References:

2024-04-25 - 1

  • Date: 2024-04-25
  • Project: NGFS Token
  • Value Lost: ~$190,000
  • Chain: BSC
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.2.1: Improper Initialization
    • Secondary Classification: BWC 2.1.1: Missing Access Control
  • Description:
    • The NGFS token contract was exploited due to a failure to properly lock critical configuration variables upon deployment.
    • The Flaw: The contract included a uniswapV2Dele flag intended to lock the privileged _uniswapV2Proxy address after initialization. However, the deployer failed to set this flag to true during the deployment process.
    • The Exploit: Because the lock was open, an attacker was able to call the initialization function (or a setter protected by this flag) to overwrite the _uniswapV2Proxy with their own address. This granted them privileged access to restricted operations, allowing them to mint unlimited tokens and drain the liquidity pool.
  • References:

2024-04-08 - 9

  • Date: 2024-04-08
  • Project: Squid Game (SQUID)
  • Value Lost: ~$87,000
  • Chain: BSC
  • BWC:
    • Broader Classification: BWC 5: Economic & Game-Theoretic Vulnerabilities
    • Primary Classification: BWC 5.3.1: Lack of Slippage Control
    • Secondary Classification: BWC 2.1.1: Missing Access Control, BWC 5.1.3: Sandwich Attacks
  • Description:
    • The SquidTokenSwap contract was exploited due to a combination of insufficient slippage protection and missing access control on a critical function.
    • The Flaw: The contract exposed a public function (sellSwappedTokens) that allowed any user to trigger a swap of tokens held by the contract on PancakeSwap. Crucially, this function enforced a hardcoded slippage tolerance of 5%, which is excessively wide for an automated, public function.
    • The Exploit: An attacker utilized a sandwich attack strategy. They first front-ran the swap to push the price to the limit of the 5% tolerance. Then, they triggered the contract's swap function (which executed at the manipulated bad price). Finally, they back-ran the transaction to sell and capture the profit from the price movement, draining value from the protocol.
  • References:

2024-04-01 - 8

  • Date: 2024-04 (Incident Month)
  • Project: Hackathon Token
  • Value Lost: Unknown
  • Chain: BSC
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.2.4: Self Transfers and Transaction Timing Attacks
    • Secondary Classification: BWC 6.4: Calculation Errors
  • Description:
    • The Hackathon token was exploited due to a flawed custom transfer logic that failed to handle self-transfers correctly, specifically when an AMM pair was both the sender and recipient.
    • The Flaw: The token's transfer function contained logic intended to manage reserves but did not validate if from == to. When tokens were sent to the pair address, the faulty accounting logic effectively doubled the balance of the pair instead of netting it out.
    • The Exploit: An attacker sent excess tokens to the Uniswap-like pair and called the skim function (which syncs balances to reserves) with the pair itself as the destination. The self-transfer bug doubled the "excess" tokens in the pair's balance. The attacker then called skim again, this time to their own address, to extract the artificially created surplus.
  • References:

2024-04-19 - 7

  • Date: 2024-04-19
  • Project: Hedgey Finance
  • Value Lost: ~$44,700,000
  • Chain: Ethereum, Arbitrum
  • BWC:
    • Broader Classification: BWC 2: Access Control Vulnerabilities
    • Primary Classification: BWC 2.2.1: Unsafe Token Approvals
    • Secondary Classification: BWC 4.1.1: Insufficient Input Validation
  • Description:
    • Hedgey Finance was exploited due to a critical "lingering approval" vulnerability combined with insufficient input validation.
    • The Flaw: The createLockedCampaign function allowed users to specify a claimLockup struct, which included a tokenLocker address. The contract would automatically approve this tokenLocker address to spend the campaign's tokens. Crucially, the protocol failed to validate that the tokenLocker was a trusted Hedgey contract. Furthermore, when a campaign was canceled, the protocol returned the funds but failed to revoke (reset to zero) the token allowance granted to the tokenLocker.
    • The Exploit: An attacker created a campaign using a malicious contract address as the tokenLocker. This tricked the Hedgey contract into approving the attacker's contract to spend its funds. The attacker then canceled the campaign to retrieve their initial deposit. Because the approval was not revoked, the attacker's malicious contract retained the ability to spend funds from the Hedgey contract, which they then used to drain approximately $44.7M in assets.
  • References:

2024-04-30 - 6

  • Date: 2024-04-30 (Audit Disclosure)
  • Project: Renzo Finance
  • Value Lost: $0 (Critical Audit Finding)
  • Chain: Ethereum
  • BWC:
    • Broader Classification: BWC 8: Denial of Service (DoS) Vulnerabilities
    • Primary Classification: BWC 8.1: DoS via External Calls
  • Description:
    • A critical Denial of Service vulnerability was identified in Renzo Finance's withdrawal logic during an audit.
    • The Flaw: The protocol used the legacy Solidity function .transfer() to send ETH to users withdrawing their assets. This function enforces a hardcoded gas limit of 2300 gas on the recipient's execution.
    • The Impact: This gas stipend is insufficient for many smart contract wallets (e.g., Gnosis Safe, Argent, or wallets with complex receive logic) to process the incoming transaction. Consequently, legitimate withdrawals to these addresses would strictly fail with an "Out of Gas" error, effectively locking the users' funds in the contract with no way to claim them.
  • References:

2024-04-16 - 5

  • Date: 2024-04-16 (Audit Disclosure)
  • Project: Mantle Network (CrossDomainMessenger)
  • Value Lost: $0 (Critical Audit Finding)
  • Chain: Mantle
  • BWC:
    • Broader Classification: BWC 2: Access Control Vulnerabilities
    • Primary Classification: BWC 2.2.4: Composable Arbitrary Calls
    • Secondary Classification: BWC 4.1.1: Insufficient Input Validation
  • Description:
    • A critical vulnerability was identified in Mantle's CrossDomainMessenger contract during an audit. This contract is responsible for bridging assets and relaying messages between L1 and L2.
    • The Mechanism: When bridging tokens, they are minted to the CrossDomainMessenger on the destination chain. The messenger then calls relayMessage to execute the user's cross-chain intent. If a call fails, the funds remain in the messenger contract, waiting for a replay.
    • The Flaw: The relayMessage function lacked sufficient validation of the _target address. It allowed the execution of arbitrary calls to any address, including the token contracts holding the bridge's assets.
    • The Exploit: An attacker could craft a malicious cross-chain message targeting the MNT or ETH token contract on the destination chain. The message payload would encode a call to approve(attacker, amount). Since the CrossDomainMessenger executes this call (making it the msg.sender), and it holds the locked funds, the token contract would grant the attacker approval to spend the bridge's assets. The attacker could then drain the funds using transferFrom.
  • References:

2024-04-15 - 4

  • Date: 2024-04-15
  • Project: SumerMoney
  • Value Lost: ~$350,000
  • Chain: Base
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.1.1: Standard Reentrancy
    • Secondary Classification: BWC 5.2.1: Price Manipulation
  • Description:
    • The SumerMoney protocol (a Compound fork) was exploited due to a deviation from the standard Checks-Effects-Interactions pattern in its loan repayment logic.
    • The Flaw: The repayBorrow function refunded excess ETH to the caller before updating the global totalBorrows state variable.
    • The Exploit: An attacker repaid a loan with a 1 wei surplus. When the contract transferred this 1 wei refund, it triggered the attacker's fallback function. At this precise moment, the protocol held the repaid cash, but the totalBorrows figure had not yet been decreased. This temporary state inconsistency caused the exchange rate (calculated as (Cash + Borrows - Reserves) / Supply) to spike artificially. Inside the reentrancy hook, the attacker redeemed their collateral at this inflated rate, receiving significantly more underlying assets than they were entitled to.
  • References:

2024-04-16 - 3

  • Date: 2024-04-16 (Audit Disclosure)
  • Project: Mantle Network (op-geth)
  • Value Lost: $0 (Critical Vulnerability Patched)
  • Chain: Mantle
  • BWC:
    • Broader Classification: BWC 1: Ecosystem & Off-Chain Risks
    • Primary Classification: BWC 1.4.5: Client Consensus Bug
    • Secondary Classification: BWC 6.1: Integer Overflow & Underflow
  • Description:
    • A critical vulnerability was discovered in Mantle's execution client (op-geth) during an audit. The flaw was located in the state transition logic that handles L1-to-L2 ETH deposits.
    • The Flaw: When processing a deposit, the Go code calculated the balance change using BigInt subtraction. If the "from" address had insufficient funds, the result would be a negative number. The critical failure occurred in the common.BigToHash function, which blindly converted this negative BigInt into a positive 32-byte hash (essentially underflowing/wrapping to a massive positive value) when writing to the state trie.
    • Impact: This would have allowed an attacker to initiate a transfer they couldn't afford, resulting in their balance being set to a near-infinite amount instead of reverting, effectively enabling infinite ETH minting on L2.
  • References:

2024-04-26 - 2

  • Date: 2024-04-26 (Audit Report Date)
  • Project: Taiko (TimelockTokenPool)
  • Value Lost: $0 (Critical Audit Finding)
  • Chain: Ethereum / Taiko (Layer 2)
  • BWC:
    • Broader Classification: BWC 4: Input & Data Validation Vulnerabilities
    • Primary Classification: BWC 4.3.2: Incomplete Signature Schemes
  • Description:
    • A critical vulnerability was identified in the TimelockTokenPool contract used for Taiko grants. The contract allowed recipients to withdraw tokens using a signature authorization.
    • The Flaw: The signature validation logic relied on a weak digest: keccak256(abi.encodePacked("Withdraw unlocked Taiko token to: ", _to)). This digest failed to include critical replay protection fields: a nonce (to prevent reusing the same signature on the same contract), the verifying contract address (to prevent reusing the signature on different pools), and the chain ID (to prevent cross-chain replays).
    • The Exploit: An attacker (or a malicious recipient) could capture a valid signature used for one withdrawal and replay it multiple times to drain the pool of all unlocked tokens allocated to that grant, or potentially replay it on other chains or contract instances.
  • References:

2024-04-26 - 1

  • Date: 2024-04-26
  • Project: Renzo Protocol
  • Value Lost: $0 (Audit Finding)
  • Chain: N/A (Audit Finding)
  • BWC:
    • Broader Classification: BWC 8: Denial of Service (DoS) Vulnerabilities
    • Primary Classification: BWC 8.1: DoS via External Calls
  • Description:
    • The vulnerability was caused by using a low-level payable.transfer() call, which forwards a fixed 2300 gas stipend, to send funds to a user withdrawing from the protocol.
    • The auditor identified that if the user's withdrawal address was a multi-sig wallet (e.g., Gnosis Safe), its fallback receive() function would fail due to the insufficient gas stipend.
    • This issue was critical because the withdrawal mechanism required the final claimant to be the exact same address that initiated the withdrawal.
    • This created a permanent DoS scenario: the Gnosis Safe could not receive the funds due to the low gas, but it was the only entity authorized to complete the withdrawal, leading to a permanent loss of funds for that user.
  • References:

2024-03-03 - 2

  • Date: 2024-03-03 (Blog Series Publication)
  • Project: Stargate / Drips Network
  • Value Lost: $0 (Critical Vulnerability Disclosure)
  • Chain: Omnichain (LayerZero Integrations)
  • BWC:
    • Broader Classification: BWC 8: Denial of Service (DoS) Vulnerabilities
    • Primary Classification: BWC 8.8: DoS in Cross-Chain Messaging Protocols
    • Secondary Classification: BWC 8.7: DoS via Return Data Bomb (Resource Exhaustion)
  • Description:
    • Vulnerabilities were identified in how Stargate and Drips Network integrated LayerZero, leading to permanent channel blocking.
    • Stargate DoS: Stargate used a try-catch block to handle failed payload deliveries. Researchers found two ways to bypass this safety mechanism:
      1. EOA Target: Sending a payload to an Externally Owned Account (EOA) or a non-contract address could force the try-catch to revert unexpectedly without entering the catch block, blocking the nonce.
      2. Storage Exhaustion: Sending an extremely large payload that consumes all gas when the catch block attempts to store it for retry. This causes the catch block itself to revert, preventing the system from clearing the nonce.
    • Drips Network DoS: The protocol lacked a recovery mechanism for messages that indefinitely reverted at the bridge level on the destination chain. An attacker could send a message designed to always revert, permanently blocking the channel and preventing any future updates or message delivery.
  • References:

2024-03-03 - 5

  • Date: 2024-03-03 (Blog Series Publication)
  • Project: LayerZero V1
  • Value Lost: $0 (Critical Vulnerability Disclosure)
  • Chain: Omnichain (LayerZero)
  • BWC:
    • Broader Classification: BWC 8: Denial of Service (DoS) Vulnerabilities
    • Primary Classification: BWC 8.8: DoS in Cross-Chain Messaging Protocols
    • Secondary Classification: BWC 8.11: DoS via Front-Running (Griefing)
  • Description:
    • Security researchers at Trust Security disclosed multiple Denial of Service vectors in LayerZero V1.
    • Nonce Overlap DoS: Messages were ordered by a nonce derived from srcChain, srcAddress, and dstChain, but notably excluded the dstAddress. An attacker could configure a malicious application to send a message using the same nonce sequence as a legitimate application on the same path. By sending a "spoofed" message that fails or hangs, the attacker could block the delivery of the legitimate application's message with the same nonce, freezing the channel.
    • ONFT Gas DoS: In the ONFT (Omnichain NFT) implementation, the destination execution calls onERC721Received. An attacker could bridge an NFT to a malicious contract on the destination chain that consumes all available gas in this callback. This would cause the delivery transaction to revert. Because LayerZero V1 enforced strict ordering, this failed message would block all subsequent messages on that path.
  • References:

2024-03-21 - 4

  • Date: 2024-03-21
  • Project: Super Sushi Samurai
  • Value Lost: ~$4,600,000
  • Chain: Blast
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.2.4: Self Transfers and Transaction Timing Attacks
    • Secondary Classification: BWC 3.2.5: Broken State Adjustment
  • Description:
    • The Super Sushi Samurai (SSS) token was exploited due to a critical logic error in its custom ERC-20 transfer implementation regarding self-transfers.
    • The Flaw: The _update function handled balance updates by first subtracting the amount from the sender (_balances[from] -= amount) and then adding it to the recipient (_balances[to] += amount). However, the implementation incorrectly calculated the new recipient balance before updating the sender's balance in storage.
    • The Exploit: When an attacker transferred tokens to themselves (from == to), the contract would:
      1. Calculate toBalance (current balance + amount).
      2. Update _balances[from] (current balance - amount).
      3. Update _balances[to] with the previously calculated toBalance. Since from and to are the same storage slot, step 3 overwrote the deduction from step 2, resulting in the user's balance simply increasing by the transfer amount without the corresponding decrement, effectively doubling their balance with each self-transfer.
  • References:

2024-03-05 - 3

  • Date: 2024-03-05
  • Project: WOOFI
  • Value Lost: ~$8,750,000
  • Chain: Arbitrum
  • BWC:
    • Broader Classification: BWC 5: Economic & Game-Theoretic Vulnerabilities
    • Primary Classification: BWC 5.2.1: Price Manipulation
    • Secondary Classification: BWC 4.2.1: Insufficient Oracle Validation
  • Description:
    • The WOOFI decentralized exchange was exploited due to a vulnerability in its Synthetic Proactive Market Making (sPMM) algorithm.
    • The Flaw: The sPMM pricing mechanism, which adjusted prices based on on-chain trade volume to simulate an order book, was not adequately time-weighted or capped. It allowed a single block of transactions to drastically alter the asset's price.
    • The Exploit: An attacker utilized flashloans to borrow large amounts of WOO and other assets. They executed a sequence of large swaps in a low-liquidity WOO market on Arbitrum, manipulating the sPMM to value WOO at an incredibly low price ($0.00000009).
    • Secondary Failure: WOOFI had a safeguard designed to fall back to a Chainlink oracle if the price deviated too far. However, this fallback was not correctly configured for the WOO token on Arbitrum. Consequently, the system accepted the manipulated price, allowing the attacker to swap back and drain the pool's WOO reserves for pennies.
  • References:

2024-03-28 - 2

  • Date: 2024-03-28
  • Project: Ondo Finance
  • Value Lost: $0 (Audit Finding)
  • Chain: N/A (Audit Finding)
  • BWC:
    • Broader Classification: BWC 5: Economic & Game-Theoretic Vulnerabilities
    • Primary Classification: BWC 5.2.3: Hardcoded or Assumed Asset Price
  • Description:
    • The protocol allowed users to deposit USDC to mint the native OUSG token. The amount of OUSG minted was based on a price from an OUSG/USD oracle.
    • The vulnerability was a flawed assumption in the minting calculation, which implicitly treated 1 USDC as being exactly equal to 1 USD.
    • The code used the raw usdcAmountIn as the basis for the USD value of the deposit, without consulting a USDC/USD oracle.
    • During a de-peg event where USDC's market price is less than $1, an attacker could acquire USDC at a discount and deposit it into the protocol. The protocol would then mint OUSG tokens as if the deposited USDC was worth its full $1 value, granting the attacker an arbitrage opportunity at the expense of the protocol.
  • References:
    • Vulnerable Contract Code: 
      function _getMintAmount(
    uint256 usdcAmountIn,
    uint256 price
) internal view returns (uint256 ousgAmountOut) {
    uint256 amountE36 = usdcAmountIn * 1e18;
    ousgAmountOut = amountE36 / price;
}
    • C423n4 Finding

2024-03-28 - 1

  • Date: 2024-03-28
  • Project: Prisma Finance
  • Value Lost: ~$12,000,000
  • Chain: Ethereum Mainnet
  • BWC:
    • Broader Classification: BWC 2: Access Control Vulnerabilities
    • Primary Classification: BWC 2.3.1: Missing Validation in Callbacks
    • Secondary Classification: BWC 4.1.1: Insufficient Input Validation
  • Description: The MigrateTroveZap contract was exploited due to a critical validation failure in its onFlashLoan callback function. This function was intended to be called only by the lending protocol as part of a legitimate flashloan-initiated migration process. However, the function failed to verify the context of the call or the input data source. This allowed an attacker to invoke onFlashLoan directly with maliciously crafted data, instructing the contract to close other users' "Troves" (collateralized debt positions) and move their collateral. The attacker then manipulated the resulting position to withdraw the excess collateral for themselves.
  • References:

2024-02-05 - 1

  • Date: 2024-02-05
  • Project: Wrapped XETA (WXETA)
  • Value Lost: ~$25,000 (Liquidity Pool Drained)
  • Chain: Ethereum Mainnet
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.2.1: Improper Initialization
    • Secondary Classification: BWC 2.1.1: Missing Access Control
  • Description:
    • The Wrapped XETA (WXETA) contract was exploited due to a critical re-initialization vulnerability.
    • The Flaw: The contract's initialize function failed to properly set the initialized state variable (or check it correctly), leaving the contract open to being initialized again.
    • The Exploit: An attacker called the public initialize function on the already-deployed contract. This allowed them to overwrite the contract's owner/admin role with their own address. Once they gained admin privileges, they granted themselves minting permissions, minted a massive supply of WXETA tokens, and dumped them into the USDT/WXETA Uniswap pool to drain its liquidity.
  • References:

2024-01-22 - 4

  • Date: 2024-01-22 (Audit Disclosure)
  • Project: Restake Finance
  • Value Lost: $0 (Critical Audit Finding)
  • Chain: Ethereum
  • BWC:
    • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
    • Primary Classification: BWC 3.2.5: Broken State Adjustment
    • Secondary Classification: BWC 7.2: Unsafe Storage & Memory Handling
  • Description:
    • A critical logic error was identified in Restake Finance's withdrawal mechanism during an audit.
    • The Flaw: The protocol processed withdrawals by sending the underlying assets to the user, deleting the WithdrawalRequest struct from storage, and then attempting to burn the corresponding shares.
    • The Exploit: Because the request object was deleted before the burn function was called, the subsequent read of request.shares accessed a zeroed-out storage slot. Consequently, the function burned 0 shares instead of the correct amount.
    • The Impact: While users received their funds, the corresponding shares were never destroyed. This would lead to a permanent imbalance between the total share supply and the underlying assets, effectively diluting the protocol's exchange rate and breaking the accounting logic.
  • References:

2024-01-16 - 3

  • Date: 2024-01-16
  • Project: Socket (Bungee Bridge)
  • Value Lost: ~$3,300,000
  • Chain: Ethereum Mainnet
  • BWC:
    • Broader Classification: BWC 2: Access Control Vulnerabilities
    • Primary Classification: BWC 2.2.4: Composable Arbitrary Calls
    • Secondary Classification: BWC 2.2.1: Unsafe Token Approvals
  • Description:
    • The Socket (Bungee) bridge was exploited due to an arbitrary external call vulnerability in a newly deployed route handler.
    • The Flaw: The contract's performAction function processed user-supplied swapExtraData without validating the target or the calldata.
    • The Exploit: An attacker exploited this by passing the WETH contract address as the target and encoding a transferFrom call in the swapExtraData. Because users had previously granted infinite WETH approvals to the Socket Gateway contract, the contract executed the malicious transferFrom call as a "confused deputy," draining funds from user wallets directly to the attacker.
  • References:

2024-01-12 - 2

  • Date: 2024-01-12
  • Project: Beanstalk (Immunefi Disclosure)
  • Value Lost: $0 (Critical Vulnerability Patched)
  • Chain: Ethereum
  • BWC:
    • Broader Classification: BWC 4: Input & Data Validation Vulnerabilities
    • Primary Classification: BWC 4.1.1: Insufficient Input Validation
    • Secondary Classification: BWC 4.2.1: Insufficient Oracle Validation
  • Description: A critical vulnerability was discovered in Beanstalk's "Well" integration (liquidity pools). The protocol failed to validate the Well address provided by a user during liquidity removal. The convert logic trusted the input address to calculate the amount of BEAN tokens to return to the user. Because there was no whitelist or check to ensure the address was a legitimate Beanstalk Well, an attacker could have deployed a malicious contract that acted as a fake Well. This fake contract could report that the attacker was entitled to the entire BEAN balance of the Beanstalk contract, effectively allowing them to drain the silo without holding significant liquidity.
  • References:

2024-01-31 - 1

  • Date: 2024-01-31
  • Project: Abracadabra
  • Value Lost: $6,500,000
  • Chain: Ethereum Mainnet
  • BWC:
    • Broader Classification: BWC 6: Arithmetic & Numeric Vulnerabilities
    • Primary Classification: BWC 6.2: Precision Loss & Rounding Errors
    • Secondary Classification: BWC 5.2.2: First Deposit / Inflation Attack
  • Description:
    • The exploit's root cause was a rounding issue in the CauldronV4 contract's borrow function. An attacker manipulated their share of the total debt by repeatedly borrowing and repaying small amounts of MIM, taking advantage of a rounding error.
    • This attack was amplified by an ERC-4626 style inflation attack, where the attacker donated MIM to the BentoBox to manipulate the share price after repaying the debt of all other users.
    • By repeatedly borrowing and repaying, the attacker exponentially increased their share of the debt (part) while keeping the total borrowed assets low. This incorrect debt calculation allowed the attacker to borrow a large amount of MIM with very little collateral, draining the liquidity from the yvCrv3Crypto and magicAPE cauldrons.
  • References:

It’s important to emphasize that the intent behind this content is not to criticize or blame the affected projects but to provide objective overviews that serve as educational material for the community to learn from and better protect projects in the future.