Blockchain Weakness Classification (BWC)

A taxonomy for classifying smart contract vulnerabilities.

Last Update: Feb 2 2026

Authors: @BBHGuild

BWC Top 11

General Principles & Mitigations

This section outlines high-level principles and common technical mitigations that apply broadly across many vulnerability classes. Specific, targeted mitigations can be found in the main table.

Core Security Principles

• Defense in Depth: Assume breach. Layer multiple, independent defenses so the failure of one does not compromise the whole system.
• Minimize Attack Surface: Every line of code is a liability. Reduce complexity by eliminating non-essential features, code, and dependencies to shrink the target for attackers.
• Least Privilege: Grant the absolute minimum permissions for the shortest time necessary. Limit both the scope (what) and duration (how long) of any privilege.
• Security as a Process: Security is a continuous process, not a one-time audit. Actively adapt defenses to the evolving threat landscape through ongoing review and learning.

2026 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.

---

2026-02-02 - 14

• Date: 2026-02-02
• Project: Matcha Meta (SwapNet)
• Value Lost: ~$16,800,000
• Chain: Base
• BWC:
  • Broader Classification: BWC 2: Access Control Vulnerabilities
  • Primary Classification: BWC 2.2.3: Untrusted Arbitrary Calls
  • Secondary Classification: BWC 2.2.1: Unsafe Token Approvals
• Description:
  • Matcha Meta's SwapNet router was exploited for ~$16.8M (later analysis suggests ~$17M) due to an arbitrary call vulnerability in a closed-source contract.
  • Vulnerability: The SwapNet router failed to validate inputs properly, allowing unauthorized arbitrary calls. The attacker used this to force the contract to call transferFrom on various tokens, draining funds from users who had granted infinite approvals to the router.
  • Attack Flow:
    1. Reconnaissance: The attacker identified users with infinite approvals to the SwapNet router.
    2. Execution: The attacker exploited the arbitrary call flaw to inject calls to token.transferFrom(victim, attacker, amount), bypassing the router's intended logic.
    3. Laundering: Funds were swapped for USDC (~$10.5M) and then ~3,655 ETH on Base, which was subsequently bridged to Ethereum Mainnet.
• References:
  • BlockSec Analysis
  • News Article (TimesCrypto)
  • Matcha Meta X
  • Attack Transaction (Basescan)

---

2026-01-26 - 13

• Date: 2026-01-26
• Project: Individual Swap Incident (Illiquid Pool)
• Value Lost: ~$140,000
• Chain: Ethereum
• BWC:
  • Broader Classification: BWC 5: Economic & Game-Theoretic Vulnerabilities
  • Primary Classification: BWC 5.3.1: Lack of Slippage Control
  • Secondary Classification: BWC 1.3.7: Flawed Off-Chain Infrastructure (Potential UI/Routing Failure)
• Description:
  • An individual user suffered a catastrophic loss of ~$140,000 in a single swap transaction, receiving only ~0.09 EUR in return.
  • Vulnerability: The transaction was executed through a liquidity pool with insufficient depth (illiquid). The user's transaction likely lacked a proper amountOutMin (slippage protection) parameter, or the interface used failed to warn/prevent the routing through the empty pool.
  • Execution: The user attempted to swap a high-value amount of tokens. Due to the lack of liquidity in the selected pool, the trade suffered ~100% price impact. Without a slippage revert, the transaction executed, effectively donating the funds to the pool's liquidity providers or back-running MEV bots.
• References:
  • Community Alert (deebeez)
  • Swap Transaction (Etherscan)

---

2026-01-11 - 12

• Date: 2026-01-11 (Estimated based on report timing)
• Project: MetaverseToken (MT)
• Value Lost: ~$37,000
• Chain: BSC
• BWC:
  • Broader Classification: BWC 5: Economic & Game-Theoretic Vulnerabilities
  • Primary Classification: BWC 5.2.1: Price Manipulation
• Description:
  • TenArmor detected a suspicious attack involving the MetaverseToken (MT) on BSC, resulting in a loss of approximately $37,000.
  • Vulnerability: Limited details were provided, but the incident has been classified as price manipulation based on the detected on-chain behavior.
  • Attack Flow: The specific mechanics involved an interaction with the MT contract that drained funds, likely via market manipulation or a flaw in how the token handles price/value calculations.
• References:
  • TenArmor Alert
  • Attack Transaction (BscScan)

---

2026-01-01 - 11

• Date: 2026-01-01
• Project: Valinity
• Value Lost: ~$63,000
• Chain: Ethereum
• BWC:
  • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
  • Primary Classification: BWC 3.4.2: Flawed Incentive Structures (Flawed Rebalance Logic)
  • Secondary Classification: BWC 5.2.1: Price Manipulation (Spot Price Dependency)
• Description:
  • Valinity was exploited for ~$63k due to a business logic flaw in its rebalancing mechanism.
  • Vulnerability: The acquireByLTVDisparity function, intended to rebalance the synthetic VY token holdings based on LTV ratios and Uniswap V3 spot prices, was publicly callable. Crucially, the logic was flawed as it was hardcoded to execute swaps of VY into a liquidity pool that held negligible liquidity (~$106 USDC).
  • Attack Flow:
    1. Price Manipulation: The attacker swapped USDC for PAXG to artificially increase the PAXG price on Uniswap V3.
    2. Forced Dump: The attacker called the public acquireByLTVDisparity function. Due to the inflated PAXG price (which altered the LTV calculation), the contract logic triggered a sell-off of VY tokens into the illiquid pool.
    3. Arbitrage/Borrow: The attacker bought the dumped VY tokens cheaply from the pool and used them as collateral to borrow hard assets (ETH, BTC, PAXG) from the protocol, exiting with the profit.
  • Note: The protocol paused contracts following the exploit.
• References:
  • TenArmor Alert
  • Weilin Li Analysis
  • Attack Transaction (Etherscan)

---

2026-01-01 - 10

• Date: 2026-01-01
• Project: PRXVTai
• Value Lost: ~$97,000
• Chain: Base
• BWC:
  • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
  • Primary Classification: BWC 3.4.2: Flawed Incentive Structures (Reward Accounting Mismatch)
  • Secondary Classification: BWC 2.3.1: Missing Validation in Callbacks (Missing Token Transfer Hooks)
• Description:
  • PRXVTai was exploited for ~$97k on Base due to a flaw in its staking reward mechanics.
  • Vulnerability: The PRXVTStaking contract minted a transferable receipt token (stPRXVT) representing staked AgentTokenV2. However, the contract failed to implement the necessary hooks (e.g., _beforeTokenTransfer) to update reward accounting state variables when these receipt tokens were transferred between users.
  • Attack Flow:
    1. Staking/Transfer: The attacker likely staked tokens to receive stPRXVT or transferred stPRXVT between wallets.
    2. Accounting Desync: Because the reward logic (earned()) calculated rewards based on the current balance but the "reward debt" (or userRewardPerTokenPaid) was not synchronized during transfers, the system failed to correctly track how long the tokens were held by specific addresses.
    3. Drain: This allowed the attacker to claim inflated rewards, which were then bridged to Ethereum.
• References:
  • CertiK Alert
  • Attack Transaction (Basescan)

---

2026-01-20 - 9

• Date: 2026-01-20
• Project: SynapLogic
• Value Lost: ~$88,000
• Chain: Base
• BWC:
  • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
  • Primary Classification: BWC 3.2.8: Faulty Array & List Handling (Duplicate Entries)
  • Secondary Classification: BWC 3.4.2: Flawed Incentive Structures
• Description:
  • SynapLogic on Base was exploited for ~$88k due to a logic flaw in its referral system.
  • Vulnerability: The swapExactTokensForETHSupportingFeeOnTransferTokens function accepted a user-supplied array address[] refBy to distribute referral rewards (10% per referee) but failed to check for duplicate addresses or cap the total payout percentage.
  • Attack Flow:
    1. Duplicate Injection: The attacker called the function with the refBy array containing their own address repeated 31 times (e.g., [self, self, ... x31]).
    2. Reward Multiplication: The contract calculated the reward as 31 * 10% = 310% of the input value.
    3. Drain: The contract paid out the inflated reward in ETH/USDC from its reserves to the attacker, draining the purchasing contract.
  • Note: The attacker also minted SYP tokens during the process, but these were locked in vesting and could not be sold. The profit was derived solely from draining the contract's liquidity backing the referral payouts.
• References:
  • SlowMist Alert
  • Weilin Li Analysis
  • Attack Transaction (Basescan)

---

2026-01-20 - 8

• Date: 2026-01-20
• Project: MakinaFi
• Value Lost: ~$4,130,000 (1,299 ETH)
• Chain: Ethereum
• BWC:
  • Broader Classification: BWC 5: Economic & Game-Theoretic Vulnerabilities
  • Primary Classification: BWC 5.2.1: Price Manipulation (Asset Inflation)
  • Secondary Classification: BWC 4.2.2: Oracle Manipulation (Internal Accounting as Oracle)
• Description:
  • MakinaFi's DUSD Machine was exploited for ~$4.13M due to a vulnerability in its internal accounting logic.
  • Vulnerability: The protocol used a specific Weiroll script to calculate the value of its positions (specifically in the MIM-3CRV Curve pool) to determine the Assets Under Management (AUM). This script relied on spot values that could be manipulated.
  • Attack Flow:
    1. Manipulation: The attacker used large flash loans to inflate the value of the MIM-3CRV pool and the associated rewards.
    2. AUM Update: The attacker called updateTotalAum, which ran the vulnerable script. This recorded an artificially inflated value for the protocol's holdings, consequently spiking the price of the DUSD token (which is derived from AUM).
    3. Extraction: The attacker utilized the DUSD/USDC Curve pool (which relies on this internal price) to swap DUSD for USDC at the inflated rate.
  • Execution Twist: The original attacker (0x2F93...) deployed the exploit contract but was front-run by an MEV bot (0x935...). The MEV bot replicated the attack logic and secured the funds.
  • Status: The protocol is paused (Recovery Mode). The team is negotiating with the MEV builder and a Rocket Pool validator who unintentionally received a portion of the funds to recover the assets.
• References:
  • CertiK Incident Analysis
  • MakinaFi Official Update
  • Attack Tx

---

2026-01-21 - 7

• Date: 2026-01-21
• Project: SagaEVM (Saga Protocol Chainlet)
• Value Lost: ~$6.8M bridged to Ethereum)
• Chain: SagaEVM / Ethereum
• BWC:
  • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
  • Primary Classification: BWC 3.2.5: Broken State Adjustment (Infinite Mint)
  • Secondary Classification: BWC 10.3: Cross-Protocol Interoperability Attacks (IBC Message Validation)
• Description:
  • SagaEVM, an EVM-compatible chainlet of the Saga Protocol, was exploited for approximately $7 million, resulting in a chain halt at block height 6593800. The exploit targeted the ecosystem's stablecoin, Saga Dollar ($D).
  • Vulnerability: The flaw existed within the chain's precompile bridge contract responsible for handling Inter-Blockchain Communication (IBC). The system failed to properly validate custom payloads, allowing a malicious helper contract to bypass collateral checks and mint infinite $D tokens "out of thin air."
  • Attack Flow:
    1. Injection: The attacker deployed a malicious helper contract (0x7D69...) on SagaEVM.
    2. Infinite Mint: The helper contract sent crafted IBC messages to the precompile bridge, triggering the unauthorized minting of ~$7M in $D.
    3. Extraction: The attacker bridged the illicitly minted $D to Ethereum Mainnet via the Squid Router.
    4. Laundering: On Ethereum, the funds were swapped via 1inch and KyberSwap into ETH (2,000+ ETH), USDC, yUSD, and tBTC. A portion ($800k) was deposited into Uniswap V4 liquidity positions (NFTs).
  • Status: SagaEVM remains paused. The Saga SSC mainnet and other chainlets were unaffected. The $D token depegged ~25% following the inflation event.
  • Addresses:
    • Attacker (Saga/ETH): 0x2044697623AfA31459642708c83f04eCeF8C6ECB
    • Malicious Helper Contract (Saga): 0x7D69E4376535cf8c1E367418919209f70358581E
• References:
  • Official Saga Incident Update
  • Analysis Tweet (Weilin Li)
  • Attacker Address (Etherscan)
  • Loss Transaction (Etherscan)
  • QuillAudits Analysis Tweet

---

2026-01-12 - 6

• Date: 2026-01-12
• Project: YO Protocol
• Value Lost: ~$3,710,000 (Covered by Protocol Treasury)
• Chain: Ethereum
• BWC:
  • Broader Classification: BWC 5: Economic & Game-Theoretic Vulnerabilities
  • Primary Classification: BWC 5.3.1: Lack of Slippage Control
  • Secondary Classification: BWC 1.3.7: Flawed Off-Chain Infrastructure
• Description:
  • YO Protocol suffered a loss of ~$3.71M during a routine rebalancing operation due to a misconfigured automated swap. The protocol's "Automated Harvesting System" attempted to swap ~$3.84M worth of stkGHO for USDC but received only ~$112k, resulting in a 97% loss.
  • Vulnerability: The incident was an operational failure rather than a smart contract exploit. The vault operator (keeper bot) submitted a transaction to the Odos Router with an effectively disabled slippage parameter (set to 17,872,058). The on-chain harvesting logic checked for "execution drift" but failed to validate the sanity of the initial output quote.
  • Execution: The aggregator, following the permissive instructions, routed the massive trade through fragmented and illiquid Uniswap V4 pools (and others including Curve/Balancer). The route utilized pools with extreme fee tiers (up to 88%) and insufficient liquidity, vaporizing the funds into the hands of LPs positioned in these pools.
  • Incident Response: The YO Protocol team utilized their multisig to backstop the loss, purchasing ~3.71M GHO via CoW Swap (which offers MEV protection) and redepositing it into the vault. An on-chain message was sent to the LPs requesting a return of funds in exchange for a 10% bounty.
• References:
  • Rekt News: Yo

---

2026-01-12 - 5

• Date: 2026-01-12
• Project: dHEDGE
• Value Lost: $0 (Critical Vulnerability Patched; >$10M Risk)
• Chain: Ethereum / Optimism
• BWC:
  • Broader Classification: BWC 4: Input & Data Validation Vulnerabilities
  • Primary Classification: BWC 4.5.1: Parser Differential / Inconsistent Validation
  • Secondary Classification: BWC 10.3: Cross-Protocol Interoperability Attacks
• Description:
  • A critical vulnerability was identified in dHEDGE’s 1inch integration guard that could have allowed a malicious pool manager to bypass slippage protection and drain over $10M in user funds.
  • Vulnerability: The issue stemmed from a Parser Differential between the dHEDGE contract guard and the 1inch Router. The dHEDGE guard calculated slippage based on the token input parameter provided in the function call. However, the 1inch unoswap function for Uniswap V3 pools ignores this token input entirely, determining the swap direction (ZeroForOne) solely based on a specific bitmask within the pool uint256 identifier.
  • Attack Flow:
    1. Parser Deception: A malicious manager provides a worthless "Fake Token" as the token input. The dHEDGE guard calculates slippage logic based on this Fake Token (which the attacker controls to ensure checks pass).
    2. Execution Divergence: The manager constructs the pool identifier such that the 1inch Router executes a swap of the real pool assets (e.g., USDT) -> Fake Token, ignoring the token input provided in step 1.
    3. Bypass: Because the dHEDGE guard logic assumes the Fake Token is the source asset being swapped, it fails to validate the slippage/outflow of the real USDT, allowing the manager to drain the pool.
  • Incident Response: The vulnerability was disclosed by a whitehat researcher following an audit contest where it was initially missed. The protocol developers confirmed the severity and patched the issue before any exploitation occurred.
• References:
  • Vulnerability Disclosure Write-up

---

2026-01-08 - 4

• Date: 2026-01-08
• Project: TMXTribe
• Value Lost: ~$1,400,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 1.1.2: Barriers to Verification (The Specialist Gap)
• Description:
  • TMXTribe, a GMX fork, was exploited for approximately $1.4M over a 36-hour period due to flawed logic in its unverified contracts. The attack involved a loop of minting and staking TMX LP tokens using USDT, swapping the deposited USDT for USDG (the protocol's stablecoin), unstaking, and draining the acquired USDG.
  • Vulnerability: The specific root cause was a logic bug in the LP staking and swapping mechanics that failed to account for this extraction loop. The contracts were unverified, hiding the exact flaw from independent review.
  • Incident Response: Despite the exploit continuing for 36 hours, the team failed to pause the protocol. On-chain activity showed the team deploying and upgrading contracts during the attack but taking no effective action to stop the drainage.
  • Addresses:
    • Exploiter 1: 0x763a67E4418278f84c04383071fC00165C112661
    • Exploiter 2: 0x16Ed3AFf3255FDDB44dAa73B4dE06f0c2E15288d
• References:
  • Rekt News Postmortem
  • Exploiter Address (Arbiscan)

---

2026-01-08 - 3

• Date: 2026-01-08
• Project: Truebit
• Value Lost: ~$26,600,000
• Chain: Ethereum
• BWC:
  • Broader Classification: BWC 6: Arithmetic & Numeric Vulnerabilities
  • Primary Classification: BWC 6.1: Integer Overflow & Underflow
• Description:
  • Truebit was exploited for approximately $26.6M due to an integer overflow vulnerability. A malicious actor was able to mint tokens for 0 ETH and subsequently swap them for 8,535 ETH.
  • Vulnerability: The getPurchasePrice() function, responsible for calculating the minting cost, relied on an internal calculation where intermediate values (v9 + v12) overflowed 2^256. This overflow caused the price calculation to wrap around and result in zero (after division), allowing the attacker to mint TRU tokens for free.
  • Attack Flow: The attacker called AdminUpgradeabilityProxy.buyTRU() to mint 240M tokens for 0 ETH, then called sellTRU() to drain ETH from the protocol. This process was repeated with increasing amounts.
  • Addresses:
    • Exploiter 1: 0x6C8EC8f14bE7C01672d31CFa5f2CEfeAB2562b50
    • Exploiter 2: 0xc0454E545a7A715c6D3627f77bEd376a05182FBc
    • Protocol Contract: 0x764C64b2A09b09Acb100B80d8c505Aa6a0302EF2
• References:
  • CertiK Alert
  • Exploiter 1 Address
  • Attack Transaction

---

2026-01-06 - 2

• Date: 2026-01-06
• Project: IPOR Fusion (USDC Optimizer on Arbitrum)
• Value Lost: ~$336,000
• Chain: Arbitrum
• BWC:
  • Broader Classification: BWC 10: Network & Consensus Evolution Attacks
  • Primary Classification: BWC 10.4.1: EIP-7702 Delegation Risks
  • Secondary Classification: BWC 4.1.1: Insufficient Input Validation
• Description:
  • A legacy IPOR Fusion vault (USDC on Arbitrum) was exploited for ~$336k. The exploit leveraged a "perfect storm" of a legacy vulnerability and a new attack vector introduced by EIP-7702.
  • Vulnerability: The incident was caused by the combination of two factors:
    1. Legacy Logic Error: The specific legacy vault lacked strict validation for "fuses" (logic modules) in its configureInstantWithdrawalFuses function, trusting that only verified addresses would add them.
    2. EIP-7702 Delegation Hijack: An administrator account (0xd8a1...) had delegated its execution to a helper contract (0xa3cc...) via EIP-7702. This helper contract contained a vulnerability allowing arbitrary calls.
  • Attack Flow:
    1. Identity Hijacking: The attacker exploited the arbitrary call vulnerability in the delegated helper contract to force the admin's EOA to call the Vault.
    2. Malicious Fuse Injection: Acting as the admin, the attacker added a malicious "fuse" to the vault.
    3. Drain: The attacker triggered instantWithdraw, causing the vault to execute the malicious fuse code and transfer assets to the attacker.
  • Incident Response: IPOR Labs acknowledged the exploit, confirmed it was isolated to this single legacy vault due to its unique configuration, and stated that the IPOR DAO would cover the shortfall from the treasury.
• References:
  • IPOR Official Post-Mortem
  • Malicious Fuse Injection Tx
  • IPOR Security Update Tweet

---

2026-01-03 - 1

• Date: 2026-01-03
• Project: Flow Blockchain / deBridge / LayerZero
• Value Lost: Undetermined (Significant breakdown in cross-chain accounting; Specific transactions of ~$200k+ cited)
• Chain: Flow, Cross-chain
• BWC:
  • Broader Classification: BWC 1: Ecosystem & Off-Chain Risks
  • Primary: BWC 1.1.6: Unverifiable Outcomes (State finality was revoked by decree, not consensus rules).
  • Secondary: BWC 1.1.1: Indispensable Intermediaries (The validators acted as "Landlords" deciding who retains assets, failing the Walkaway Test).
• Description:
  • Following an undisclosed exploit, the Flow Blockchain team executed a mandatory chain rollback to revert the network state. However, the team allegedly failed to coordinate this action with critical bridge providers (e.g., deBridge, LayerZero), leading to a catastrophic state desynchronization between Flow and the broader ecosystem.
  • Centralization Risk: The decision to unilaterally roll back the chain highlights the risks of centralized governance in Layer-1 blockchains, where "finality" can be revoked by the operator.
  • Bridge Mismatch (Double Spend & Loss): The rollback created a temporal paradox for cross-chain transactions processed during the rollback window:
    1. Bridged Out (Double Spend): Users who bridged funds out of Flow had their assets released on the destination chain. The rollback restored their balances on Flow to the pre-transfer state, effectively doubling their funds.
    2. Bridged In (Total Loss): Users who bridged funds into Flow had their assets locked on the source chain. The rollback erased the crediting transaction on Flow, leaving the users with no assets on either chain.
• References:
  • Flow Blockchain Announcement
  • deBridge/Community Alert

---

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.

2025 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.

---

2025-12-31 - 6

• Date: 2025-12-29
• Project: Multiple (e.g., Skep-pe) / "Anti-Rug" Vigilante Bot
• Value Lost: Variable (Deployer ETH Locked / Failed Launches)
• Chain: Ethereum
• Actor: 0x5c37ce78b79a09d211f3d35a617f980585e32b3c
• BWC:
  • Broader Classification: BWC 8: Denial of Service (DoS) Vulnerabilities
  • Primary Classification: BWC 8.11: DoS via Front-Running (Griefing)
  • Secondary Classification: BWC 3.2.1: Improper Initialization
• Description:
  • A sophisticated "vigilante" bot campaign was identified targeting new token launches (often categorized as "shitcoins") that utilize a specific initialization pattern.
  • The Flaw: Many token contracts use a startTrading or openTrading function that unconditionally calls IUniswapV2Factory.createPair(). The factory reverts if a pair for the token combination already exists.
  • The Exploit: The bot monitors the mempool for deployers funding their token contracts with ETH in preparation for liquidity addition. The bot then front-runs the deployer's openTrading transaction by calling createPair on the Uniswap factory directly.
  • The Impact: When the deployer's transaction attempts to execute, it reverts because the pair now exists. This effectively "bricks" the launch. In many cases, the contracts lack a mechanism to rescue the ETH sent to the contract (or rely on openTrading to move it), causing the deployer's initial liquidity funds to be permanently locked or "burned."
  • Code Snippet:

    function openTrading() external onlyOwner() {
        require(!tradingOpen,"trading is already open");
        uniswapV2Router = IUniswapV2Router02(0x7a250d5630B4cF539739dF2C5dAcb4c659F2488D);
        _approve(address(this), address(uniswapV2Router), _tTotal);
        
        // VULNERABILITY: The bot calls factory.createPair() before this transaction executes.
        // This causes the legitimate launch transaction to revert due to the pair already existing.
        uniswapV2Pair = IUniswapV2Factory(uniswapV2Router.factory()).createPair(address(this), uniswapV2Router.WETH());
        
        uniswapV2Router.addLiquidityETH{value: address(this).balance}(address(this),balanceOf(address(this)),0,0,owner(),block.timestamp);
        IERC20(uniswapV2Pair).approve(address(uniswapV2Router), type(uint).max);
        swapEnabled = true;
        tradingOpen = true;
    }
    

• References:
  • Deeberiroz X Alert
  • Threat Actor Address

---

2025-12-29 - 5

• Date: 2025-12-29
• Project: MSCST (Staking Contract) / GPC Token
• Value Lost: ~$129,900
• Chain: BSC
• BWC:
  • Broader Classification: BWC 2: Access Control Vulnerabilities
  • Primary Classification: BWC 2.1.1: Missing Access Control
  • Secondary Classification: BWC 5.2.1: Price Manipulation (Atomic Sandwich)
• Description:
  • Note: This incident occurred in late 2025.
  • The MSCST staking contract on BSC was exploited for ~$129.9k via an atomic sandwich attack facilitated by a public function.
  • Vulnerability: The releaseReward function lacked access control, allowing any caller to trigger internal logic. Additionally, the function allowed the caller to specify a fee parameter (or implicitly used the contract's balance) to execute a swap.
  • Attack Flow:
    1. Flashloan & Dump: The attacker flashloaned GPC tokens and swapped them for BNB, lowering the price of GPC.
    2. Trigger Vulnerability: The attacker called releaseReward with the fee set to the contract's MSC balance. This function swapped MSC for GPC and transferred the GPC directly to the GPC/BNB liquidity pool (calling sync), effectively increasing the GPC reserves and further lowering the price (making GPC cheaper).
    3. Arbitrage: The attacker swapped their BNB back for GPC at the artificially lowered price, profiting from the spread, and repaid the flashloan.
• References:
  • TenArmor Alert
  • Weilin Li Analysis
  • Attack Transaction (BscScan)

---

2025-12-24 - 4

• Date: 2025-12-24
• Project: EIP-7702 Delegatee Contract (Unnamed)
• Value Lost: ~$280,000
• Chain: BSC
• BWC:
  • Broader Classification: BWC 10: Network & Consensus Evolution Attacks
  • Primary Classification: BWC 10.4.1: EIP-7702 Delegation Risks (Initialization Front-Running)
  • Secondary Classification: BWC 3.2.1: Improper Initialization
• Description:
  • An uninitialized EIP-7702 delegatee contract was exploited on BSC, resulting in a loss of approximately $280,000.
  • Vulnerability: The contract, intended to serve as a code source for EIP-7702 delegations, was deployed without being initialized.
  • Attack Flow: The attacker called the exposed initialization function to grant themselves the owner role of the delegatee contract. Once in control of the logic contract, they were able to manipulate the accounts that had delegated to it, effectively draining the funds from the delegators.
  • Aftermath: The stolen funds (~95 ETH equivalent) were subsequently deposited into Tornado Cash.
• References:
  • CertiK Alert
  • Attack Transaction (BscScan)

---

2025-12-21 - 3

• Date: 2025-12-21
• Project: CHAR (Token Pair)
• Value Lost: ~$144,500
• Chain: BSC
• BWC:
  • Broader Classification: BWC 5: Economic & Game-Theoretic Vulnerabilities
  • Primary Classification: BWC 5.1.2: Back-Running (MEV Skimming)
  • Secondary Classification: BWC 1.1.7: User Disempowerment (Operational Error / "Fat Finger")
• Description:
  • A user or project team member suffered a loss of ~$144.5k involving the CHAR token on BSC.
  • Vulnerability: This was an operational error rather than a smart contract flaw. The victim mistakenly transferred CHAR tokens directly to the Uniswap V2-style liquidity pair address instead of interacting with the router to swap them.
  • Execution: The liquidity pool contract's balance became greater than its tracked reserves (sync mismatch). An MEV bot detected this discrepancy and executed a transaction (likely calling skim() or a swap) to extract the excess tokens, effectively claiming the "donated" funds.
• References:
  • TenArmor Alert
  • Attack Transaction (BscScan)

---

2025-12-19 - 2

• Date: 2025-12-19
• Project: Dragun69
• Value Lost: ~$87,400
• Chain: BSC
• BWC:
  • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
  • Primary Classification: BWC 3.3.3: Improper Handling of Native Tokens (Missing msg.value Check)
  • Secondary Classification: BWC 4.1.1: Insufficient Input Validation
• Description:
  • Note: This incident occurred in late 2025 but was logged in the 2026 database due to disclosure/reporting timing.
  • The "Dragun69: Router" contract on BSC was exploited for ~$87.4k due to a missing validation check on native token transfers.
  • Vulnerability: The router's swap function (specifically for ETH -> Token swaps) failed to verify msg.value. The contract logic assumed that the BNB amount specified in the swap parameters was provided by the caller in the current transaction. However, without the check, the contract utilized its own accumulated BNB balance to execute the swap.
  • Attack Flow:
    1. Trigger: The attacker called the Aggregator Proxy, which triggered the vulnerable implementation to run a PancakeV3 swap.
    2. Misappropriation: The router, failing to check msg.value, spent its own WBNB/BNB reserves to fulfill the swap.
    3. Extraction: The swap callback verified the balance and forwarded the resulting tokens/BNB to a recipient address specified in the untrusted calldata (the attacker), effectively draining the contract.
  • Note: The project's deployments on Base and Ethereum were not affected as they correctly included the msg.value check. The BSC implementation was patched ~6 hours after the exploit.
• References:
  • TenArmor Alert
  • Weilin Li Analysis
  • Zyy0530 Analysis
  • Attack Transaction (BscScan)

---

2025-12-13 - 1

• Date: 2025-12-13
• Project: Ribbon Finance (Legacy Contracts / Opyn Fork)
• Value Lost: ~$2,700,000
• Chain: Ethereum
• BWC:
  • Broader Classification: BWC 2: Access Control Vulnerabilities
  • Primary Classification: BWC 2.1.1: Missing Access Control (Unprotected Oracle Configuration/Ownership)
  • Secondary Classification: BWC 4.2.2: Oracle Manipulation
• Description:
  • Note: This incident occurred in late 2025.
  • Legacy contracts associated with Ribbon Finance (specifically an Opyn fork) were exploited for approximately $2.7M.
  • Vulnerability: The root cause was identified as a flawed oracle upgrade. Approximately 6 days prior to the attack, the oracle pricer was updated. This update reportedly introduced an access control vulnerability (potentially involving an unprotected transferOwnership or insufficient checks on the pricer whitelist logic) that allowed the attacker to manipulate price-feed proxies.
  • Attack Flow:
    1. Market Creation: The attacker created a new option market (e.g., LINK/USDC) with a short expiration time.
    2. Oracle Manipulation: Abusing the vulnerable oracle stack, the attacker forced arbitrary expiry prices for assets like wstETH, AAVE, LINK, and WBTC into the shared Oracle at the specific expiry timestamp.
    3. Drain: The attacker redeemed large short oToken positions against the MarginPool. Because the MarginPool relied on the forged expiry prices for settlement, the attacker was able to drain WETH, wstETH, USDC, and WBTC.
• References:
  • Weilin Li Analysis
  • LZhou Analysis
  • Specter Analyst Alert
  • Expiry Price Manipulation Tx (Etherscan)

---

2025-11-20 - 5

• Date: 2025-11-20
• Project: GANA Payment
• Value Lost: ~$3,100,000
• Chain: BSC
• BWC:
  • Broader Classification: BWC 10: Network & Consensus Evolution Attacks
  • Primary Classification: BWC 10.4.1: EIP-7702 Delegation Risks
  • Secondary Classification: BWC 1.2.2: Private Key Leakage, BWC 2.1.1: Missing Access Control
• Description:
  • GANA Payment, a newly launched payment protocol on BSC, was exploited for $3.1 million just nine days after launch.
  • Root Cause: The exploit originated from a compromised owner private key. The attacker used this key to authorize an EIP-7702 delegation to a malicious contract.
  • The Exploit: The malicious delegator contract acted as a middleman, allowing the attacker to bypass the onlyEOA (tx.origin == msg.sender) check on the staking contract. Because the transaction was an EIP-7702 transaction authorized by the owner, the staking contract perceived the calls as legitimate EOA interactions from the owner.
  • Attack Flow:
    1. Access: Compromised the owner key.
    2. Delegation: Transferred ownership to 8 different addresses, each authorizing the malicious EIP-7702 delegator.
    3. Manipulation: The delegated code manipulated the gana_Computility reward rate to an astronomical value (10,000,000,000,000,000).
    4. Drain: Systematically staked and unstaked funds through these accounts, draining the protocol.
  • Aftermath: $2.1M was bridged to Ethereum, and ~$1M was laundered through Tornado Cash on BSC.
• References:
  • Rekt.news Analysis
  • Malicious Delegator
  • Exploit Transaction

---

2025-11-11 - 4

• Date: 2025-11-11
• Project: @ImpermaxFinance
• Value Lost: 380,000 $
• Chain: base
• BWC:
  • Broader Classification: BWC 6: Arithmetic & Numeric Vulnerabilities
  • Primary Classification: BWC 6.2: Precision Loss & Rounding Errors
  • Secondary Classification: BWC 2.1.1: Missing Access Control
• Description:
  • The exploit was a sophisticated, multi-stage attack that combined a precision loss vulnerability in the liquidation mechanism with a missing access control on a fund allocation function.
  • 1. Precision Loss & State Manipulation: The attacker repeatedly created tiny, "underwater" debt positions in a low-liquidity lending market (cbBTC). By calling the restructureBadDebt() function, a rounding error allowed them to incrementally drain the market's totalBalance one wei at a time. This manipulation drove the pool's exchangeRate to near zero.
  • 2. Triggering a Malicious State: The attacker continued this process until the pool's totalBalance was exactly zero. This triggered a fallback condition in the code where the exchangeRate function returned a default, artificially high value of 1e18. At this point, the attacker held nearly 100% of the pool's shares, acquired for a negligible cost.
  • 3. Missing Access Control & Fund Drain: The attacker then exploited an unprotected flashAllocate function in a separate lending vault contract. This function, which lacked proper access control, was used to force the main cbBTC vault to deposit all its funds into the attacker's manipulated, malicious pool. Due to the artificially high exchange rate, the vault received almost no shares for its large deposit. The attacker, holding all the shares, then withdrew the vault's funds.
• References:
  • @hklst4r X Alert
  • Impermax Post-Mortem

---

2025-11-04 - 3

• Date: 2025-11-04
• Project: @MoonwellDeFi
• Value Lost: 1,000,000 $
• Chain: base
• BWC:
  • Broader Classification: BWC 4: Input & Data Validation Vulnerabilities
  • Primary Classification: BWC 4.2.1: Insufficient Oracle Validation
• Description: Moonwell DeFi's wrsETH price anomaly on November 4, 2025, stemmed from a Chainlink oracle malfunction. The protocol's vulnerability was its failure to validate the data received from its price oracle, blindly trusting an erroneously high price for wrsETH. An exploiter was able to repeatedly borrow over 20 wstETH with only ~0.02 wrstETH flashloaned and deposited due to the faulty oracle that returned a wrstETH price of $5.8M. The attacker profited by approximately 295 ETH ($1M).
• References:
  • Attack Tx 1
  • @CertiKAlertX Alert

---

2025-11-03 - 2

• Date: 2025-11-03
• Project: Balancer Hack Side Story (Sonic Chain)
• Value Lost: ~$3,000,000
• Chain: Sonic
• BWC:
  • Broader Classification: BWC 4: Input & Data Validation Vulnerabilities
  • Primary Classification: BWC 4.5.1: Parser Differential / Inconsistent Validation
  • Secondary Classification: BWC 10.3: Cross-Protocol Interoperability Attacks
• Description:
  • On November 3, 2025, following the Balancer V2 hack, the Sonic team attempted to contain the exploit by freezing the attacker's account on the L1 level. They set the attacker's native token balance to zero and replaced their code, intending to prevent them from paying gas to move funds.
  • The Bypass (BWC 4.5.1): The attacker bypassed this "transport layer" freeze by exploiting an inconsistency between the L1 gas requirements and the application-level logic. The Beets Staked Sonic (stS) token supported ERC-2612 permit, which allows for gasless approvals via off-chain signatures. The attacker signed a permit (which requires no gas) to authorize a secondary wallet, then used that secondary wallet to transferFrom and drain the "frozen" assets.
• References:
  • OpenZeppelin Analysis

---

2025-11-03 - 1

• Date: 2025-11-03
• Project: Balancer V2 & Forks
• Value Lost: ~$120,000,000
• Chains: Ethereum, Base, Polygon, Sonic, Arbitrum, Optimism, Berachain, Gnosis, Avalanche.
• BWC:
  • Broader Classification: BWC 6: Arithmetic & Numeric Vulnerabilities
  • Primary Classification: BWC 6.2: Precision Loss & Rounding Errors
  • Secondary Classification: BWC 1.1.2: Permissioning & Censorship Risks, BWC 5.1.1: Front-Running
• Description:
  • Arithmetic Vulnerability: The core of the exploit was a precision loss vulnerability within the upscale function in Balancer V2's Composable Stable Pools. This function would incorrectly round down when scaling factors were non-integer values. An attacker utilized the batchSwap feature to execute a three-stage attack: first, they precisely adjusted a token's balance to a rounding boundary; second, they performed swaps with crafted amounts, causing the rounding error to deflate the calculated price of the Balancer Pool Tokens (BPT); finally, they swapped assets back to the artificially cheapened BPT for a significant profit. This method was replicated across multiple chains where Balancer V2 or its forks were deployed.
  • Censorship & Centralized Interventions: Following the exploit, several chains took centralized action. Berachain validators halted the network for a hard fork; Sonic Labs froze the attacker's wallet; Gnosis froze affected pools and suspended its bridge; and Polygon validators reportedly censored the attacker's transactions.
  • Front-Running: A white-hat MEV bot operator successfully front-ran some of the attacker's transactions on Ethereum, recovering and returning approximately $600,000.
• References:
  • Attack Tx (Arbitrum)
  • X Post by @Phalcon_xyz with attack breakdown
  • Berachain Foundation network halt tweet

---

2025-10-15 - 5

• Date: 2025-10-15
• Project: ZKsync OS
• Value Lost: $0 (Critical Vulnerability Found in Audit)
• Chain: ZKsync Era
• BWC:
  • Broader Classification: BWC 8: Denial of Service (DoS) Vulnerabilities
  • Primary Classification: BWC 8.7: DoS via Return Data Bomb
  • Secondary Classification: BWC 1.1.1: Indispensable Intermediaries (L1->L2 Queue Halt)
• Description:
  • A critical denial-of-service vulnerability was identified in the ZKsync OS execution environment. The system preallocated a fixed 128 MB buffer for return_data from external calls.
  • The Exploit: An attacker could craft a transaction that makes numerous external calls, returning large amounts of data. This would overflow the preallocated buffer (causing a panic) while remaining within the transaction's gas limit.
  • Impact: Crucially, if this panic occurred within an L1->L2 transaction (which are processed sequentially in a queue), it would permanently halt the entire L1->L2 transaction queue. Since the queue processing halts on a panic, no subsequent L1->L2 transactions could ever be processed, effectively bricking the bridge.
• References:
  • OpenZeppelin Audit Report

---

2025-10-15 - 4

• Date: 2025-10-15
• Project: ZKsync OS
• Value Lost: $0 (Critical Vulnerability Found in Audit)
• Chain: ZKsync Era
• BWC:
  • Broader Classification: BWC 1: Ecosystem & Off-Chain Risks
  • Primary Classification: BWC 1.4.5: Client Consensus Bug
  • Secondary Classification: BWC 7.4.2: Compiler/Architecture Correctness
• Description:
  • A critical non-determinism bug was identified in ZKsync OS during an audit. The issue stemmed from the use of architecture-dependent usize arithmetic in Rust.
  • The Flaw: usize is 32-bit on the ZK prover's RISC-V architecture but 64-bit on the sequencer's x86_64 architecture.
  • The Exploit Vector: An attacker could craft a transaction with calldata lengths close to u32::MAX.
    • On the Sequencer (64-bit), the transaction processes successfully because the 64-bit integer does not overflow.
    • On the Prover (32-bit), the same calculation overflows or panics.
  • Impact: This discrepancy effectively breaks the "Client Consensus." The sequencer accepts a block that the prover cannot prove. If such a block were committed, it would halt the L1 verification process, potentially freezing the entire ZKsync Era network.
• References:
  • OpenZeppelin Audit Report

---

2025-10-10 - 3

• Date: 2025-10-10
• Project: Binance
• Value Lost: Unknown
• Chain: N/A (Centralized Exchange)
• BWC:
  • Broader Classification: BWC 1: Ecosystem & Off-Chain Risks
  • Primary Classification: BWC 1.1.6: Closed-Source Design
• Description: During a market crash, a trader's pair trade (one long, one short position) was liquidated in a seemingly adversarial manner. Instead of partially liquidating both positions to maintain the hedge, the exchange's closed-source liquidation engine allegedly closed the profitable short position entirely, while leaving the long position fully exposed to the market crash, leading to its complete liquidation shortly after. This highlights the risks of trading on platforms with opaque, unauditable liquidation systems that may prioritize the house's profit over optimal position resolution for the user.
• References:
  • X Post by @coinmamba

---

2025-10-10 - 2

• Date: 2025-10-10
• Project: Multiple (Ethena Labs, Zerobase, Venus Protocol)
• Value Lost: ~$400B in total liquidations
• Chain: Not Specified
• BWC:
  • Broader Classification: BWC 1: Ecosystem & Off-Chain Risks
  • Primary Classification: BWC 1.5.5: Geopolitically-Induced Network Stress
  • Secondary Classification: BWC 5.4.1: Cascade Failure from Network Congestion, BWC 4.2.2: Oracle Manipulation
• Description: The "Black Friday" event was a systemic failure triggered by a major geopolitical event (Trump's tariff announcement), which caused a crypto market plunge and led to a cascade of liquidations. The market crash led to mass liquidations, which in turn caused the depeg of USDe and the failure of the WBETH oracle, amplifying the crisis across multiple protocols. The Venus Protocol was directly impacted by an oracle failure when the price of WBETH depegged, highlighting the vulnerability of critical off-chain infrastructure during extreme market stress.
• References:
  • X Alert by @GoPlusSecurity

---

2025-10-04 - 1

• Date: 2025-10-04
• Project: Abracadabra (@MIM_Spell)
• Value Lost: ~$1,700,000
• Chain: Ethereum Mainnet
• BWC:
  • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
  • Primary Classification: BWC 3.2.5: Broken State Adjustment
• Description: The root cause was a flawed implementation in the cook function, which allows users to execute multiple operations in a single transaction. The vulnerability occurred when an attacker combined two actions: ACTION_BORROW, which correctly set a needsSolvencyCheck flag to true, followed by ACTION_CUSTOM, which called an empty helper function that incorrectly returned a fresh status object, resetting the needsSolvencyCheck flag to false. This second action overwrote the critical security flag set by the first, effectively bypassing the solvency check and allowing the attacker to borrow millions in MIM tokens against zero collateral.
• References:
  • Attack Tx
  • X Alert by @Phalcon_xyz

---

2025-09-30 - 11

• Date: 2025-09-30
• Project: f(x) Protocol v2
• Value Lost: $0 (Funds lock-up)
• Chain: Not Specified
• BWC:
  • Broader Classification: BWC 8: Denial of Service (DoS) Vulnerabilities
  • Primary Classification: BWC 8.10: DoS via Forced Recursion
• Description: A critical vulnerability was discovered during an audit that allowed an attacker to permanently lock user funds. The protocol used a recursive function to update user positions. An attacker could trigger around 150 insignificant liquidations, each creating a new node in a data structure. When a legitimate user later tried to manage their position, the recursive function would attempt to traverse this long chain of nodes, exceeding the EVM's call stack limit and causing the transaction to fail. This permanently prevented users from accessing their funds.
• References:
  • OpenZeppelin Audit

---

2025-09-30 - 10

• Date: 2025-09-30
• Project: Uniswap v4 Hooks (Conceptual)
• Value Lost: $0 (Conceptual bug pattern)
• Chain: Not Specified
• BWC:
  • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
  • Primary Classification: BWC 3.4.2: Flawed Incentive Structures
• Description: A conceptual vulnerability in donation-based penalty mechanisms, as seen in a Uniswap v4 hook designed to penalize just-in-time (JIT) liquidity. The hook donates a penalized LP's fees to other in-range LPs. The flaw allows an attacker to bypass this penalty by using a secondary account to be the sole recipient of their primary account's "donated" penalty fees, effectively turning the penalty into a self-rebate.
• References:
  • OpenZeppelin Audit

---

2025-09-27 - 9

• Date: 2025-09-27
• Project: Cool
• Value Lost: $100,500
• Chain: Mainnet
• BWC:
  • Broader Classification: BWC 2: Access Control Vulnerabilities
  • Primary Classification: BWC 2.1.1: Missing Access Control
  • Secondary Classification: BWC 5.1.1: Front-Running
• Description: A proxy contract was upgraded to a new implementation named "Cool". This new implementation contained a withdrawToken() function that lacked proper access control. A transaction calling this unprotected function was subsequently front-run by an MEV bot, leading to the loss of all funds.
• References:
  • Exploit Tx
  • X Alert: @TenArmorAlert

---

2025-09-23 - 8

• Date: 2025-09-23
• Project: MYX Finance
• Value Lost: ~$73,000,000 (from liquidations)
• Chain: Not Specified
• BWC:
  • Broader Classification: BWC 5: Economic & Game-Theoretic Vulnerabilities
  • Primary Classification: BWC 5.2.1: Price Manipulation
  • Secondary Classification: BWC 1.3.8: Sybil Attacks, BWC 1.2.3: Insider Threat
• Description: A coordinated, multi-vector attack involving massive price manipulation and a large-scale Sybil attack. Attackers used 100 coordinated wallets to claim $170 million in an airdrop, securing a large supply of the token. They then generated billions in artificial volume (wash trading) and engineered a short squeeze that liquidated over $73 million from retail traders. The project's official response appeared to defend the Sybil attack, suggesting potential insider complicity.
• References:
  • Rekt News - Parabolic Mirage

---

2025-09-23 - 7

• Date: 2025-09-23
• Project: Base Sequencer Debate
• Value Lost: $0 (Ecosystem Risk)
• Chain: N/A (Off-Chain)
• BWC:
  • Broader Classification: BWC 11: Privacy & Regulatory Attack Vectors
  • Primary Classification: BWC 11.2.2: Government Overreach
• Description: This incident represents a case of Regulatory Weaponization, where ecosystem participants called for regulatory action against a competitor (Base) over technical disagreements about its sequencer design. The core of the issue involved intentionally mischaracterizing a novel technology (a transaction sequencer) by equivocating it with a known regulated entity (a traditional exchange's matching engine) in an attempt to invite SEC scrutiny.
• References:
  • Discussion between @danrobinson and @MaxResnick1 on X

---

2025-09-13 - 6

• Date: 2025-09-13
• Project: JUDAOGlobal (Tentative)
• Value Lost: $20,000,000
• Chain: Polygon
• BWC:
  • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
  • Primary Classification: BWC 3.2.1: Improper Initialization
  • Secondary Classification: BWC 2.2.2: Misconfigured Proxy
• Description: A developer executed a faulty proxy upgrade, setting an incorrect implementation contract for a vault holding 77 million POL tokens from a presale. Crucially, the developer forgot to call the initialize function on the new implementation. This failure to re-initialize the contract's state effectively wiped out all admin and upgrade privileges, leaving the contract ownerless and the $20 million in funds permanently locked and inaccessible.
• References:
  • Locked Contract
  • Flagged by: @YannickCrypto

---

2025-09-12 - 5

• Date: 2025-09-12
• Project: Shibarium Bridge
• Value Lost: ~$3,957,000
• Chain: Ethereum Mainnet, Shibarium
• BWC:
  • Broader Classification: BWC 1: Ecosystem & Off-Chain Risks
  • Primary Classification: BWC 1.2.2: Private Key Leakage
  • Secondary Classification: BWC 1.1.1: Centralization Risks
• Description: A sophisticated attack compromised the Shibarium PoS bridge, resulting in the unauthorized withdrawal of multiple assets. The attacker gained control over the signing keys for 10 of the 12 network validators, allowing them to forge malicious checkpoint/exit proofs and approve fraudulent transactions. The root cause was a widespread compromise of validator keys. The incident highlighted significant centralization risks, as a majority of the validators were "internal" (operated by the core team) and their key compromise led to a catastrophic failure of the bridge's security model.
• References:
  • Shibarium Bridge Security Update
  • Attack Tx

---

2025-09-10 - 4

• Date: 2025-09-10
• Project: NPM Supply Chain Attack
• Value Lost: ~$50
• Chain: Multiple (ETH, BTC, SOL, TRX)
• BWC:
  • Broader Classification: BWC 1: Ecosystem & Off-Chain Risks
  • Primary Classification: BWC 1.4.4: Supply Chain Attacks
  • Secondary Classification: BWC 1.3.1: Social Engineering Exploits
• Description: A widespread supply chain attack was identified where an attacker compromised a reputable developer's NPM account via a targeted phishing email. The attacker then injected a malicious, obfuscated payload into popular NPM packages. This payload was designed to compromise front-end applications and browser wallets by intercepting network requests and silently swapping user crypto addresses with the attacker's address during transactions.
• References:
  • SlowMist Team Alert

---

2025-09-10 - 3

• Date: 2025-09-10
• Project: Reth (Ethereum Client)
• Value Lost: $0
• Chain: Ethereum Mainnet
• BWC:
  • Broader Classification: BWC 1: Ecosystem & Off-Chain Risks
  • Primary Classification: BWC 1.4.5: Client Consensus Bug
• Description: A bug in the Reth Ethereum client's state root computation caused multiple nodes running this client to stall on the Ethereum mainnet. The flaw was not in a smart contract but in the client software itself, which failed to correctly compute the state root according to the protocol rules. This led to a consensus failure where the affected nodes could not agree on the state of the chain with the rest of the network, requiring operators to manually intervene.
• References:
  • Announcement from Reth core developer Georgios Konstantopoulos

---

2025-09-05 - 2

• Date: 2025-09-05
• Project: Uniswap vs. Bancor
• Value Lost: $Millions in legal fees
• Chain: Not Applicable (Legal/Off-Chain)
• BWC:
  • Broader Classification: BWC 11: Privacy & Regulatory Attack Vectors
  • Primary Classification: BWC 11.2.1: Patent Trolling
• Description: This incident is not a technical exploit but a legal one. The Bancor team filed a patent infringement lawsuit against Uniswap, claiming Uniswap's Automated Market Maker (AMM) violates their patent. This represents a case of Regulatory Weaponization, where the legal system is used to attack a competitor, stifle open-source innovation, and extract value, posing a systemic risk to the ecosystem.
• References:
  • @haydenzadams founder Uniswap
  • @danrobinson patner Paradigm

---

2025-09-02 - 1

• Date: 2025-09-02
• Project: @bunni_xyz
• Value Lost: $ 8,400,000
• Chain: Ethereum, Unichain
• BWC:
  • Broader Classification: BWC 6: Arithmetic & Numeric Vulnerabilities
  • Primary Classification: BWC 6.2: Precision Loss & Rounding Errors
  • Secondary Classification: BWC 5.2.1: Price Manipulation
• Description:
  • The exploit's root cause was a rounding error in the smart contract logic that updated a pool's idle balance during withdrawals. While the rounding direction was safe for single operations, it became exploitable when combined in a specific sequence.
  • The attacker used a flash loan to perform a large swap, manipulating the price and draining most of one asset from a pool. They then executed a series of 44 tiny withdrawals. Each withdrawal exploited the rounding error, causing the protocol's tracked total liquidity to decrease disproportionately more than the tiny amount actually withdrawn.
  • After corrupting the pool's internal accounting, the attacker executed a final large swap and reverse swap at the highly manipulated price, draining approximately $8.4M from the affected pools on Ethereum and Unichain.
• References:
  • Bunni Post-Mortem Report
  • X Announcement of Incident

---

2025-08-25 - 5

• Date: 2025-08-25
• Project: Panoptic
• Value Lost: $0 (White-hat rescue of over $4M)
• Chain: Ethereum, Base, Unichain
• BWC:
  • Broader Classification: BWC 7: Low-Level & EVM-Specific Vulnerabilities
  • Primary Classification: BWC 7.3.5: Insecure Cryptographic Construction
  • Secondary Classification: BWC 4.1.1: Insufficient Input Validation
• Description:
  • A critical vulnerability was discovered in Panoptic's "position fingerprinting" mechanism, which allowed an attacker to bypass all solvency checks and drain funds. The flaw stemmed from a combination of an insecure cryptographic construction and insufficient input validation.
  • Cryptographic Weakness: The position fingerprint was generated by XORing the keccak256 hashes of individual position IDs. Using XOR as a combiner is cryptographically insecure, as it is vulnerable to collision attacks (e.g., via Gaussian elimination).
  • Insufficient Input Validation: The protocol failed to validate that the user-supplied position IDs in a list were legitimate or even owned by the caller.
  • Attack Path: An attacker could craft a fraudulent list of arbitrary, non-existent positions that produced the same XOR fingerprint as a real, high-collateral position. By submitting this spoofed list, they could trick the contract into believing they were solvent, allowing them to withdraw collateral and drain funds.
  • The vulnerability was responsibly disclosed by a researcher from Cantina, leading to a coordinated white-hat rescue operation that successfully secured over 98% of at-risk funds, preventing any loss.
• References:
  • Cantina Post-Mortem: Inside the $4M Panoptic Rescue

---

2025-08-24 - 4

• Date: 2025-08-24
• Project: Unverified Staking Contract
• Value Lost: ~$85,000
• Chain: BSC
• BWC:
  • Broader Classification: BWC 10: Network & Consensus Evolution Attacks
  • Primary Classification: BWC 10.4.1: EIP-7702 Delegation Risks
  • Secondary Classification: BWC 5.2.1: Price Manipulation
• Description:
  • An unverified staking contract on BSC was exploited for ~$85k. The victim contract used the "EOA only" (tx.origin == msg.sender) check to protect its stake function from flashloan-based price manipulation.
  • The Exploit: The attacker deployed a malicious contract and authorized its delegation to an EOA using a 7702-type transaction. The EOA transferred ~13.9 BNB tokens to itself, triggering arbitrary smart contract logic while ensuring that future tx.origin == msg.sender checks pass.
  • Attack Flow:
    1. Flashloan & Pump: In the fallback function, the malicious contract flashloaned $3.5M BSC-USD, bought POT tokens from the PancakeSwap BSC-USD/POT pool to inflate the price, then staked ~220k POT at the inflated price.
    2. Dump: The attacker swapped the remaining POT tokens back to BSC-USD tokens to repay the flashloan and almost reset the BSC-USD/POT price.
    3. Profit: In a subsequent transaction, the attacker unstaked and received 3.3M POT tokens (versus 220k staked) due to the inflated recorded value.
• References:
  • Unverified staking contract
  • Exploit Transaction

---

2025-08-24 - 3

• Date: 2025-08-24
• Project: ShibaSwap Treasure Finder
• Value Lost: $27,000
• Chain: Mainnet
• BWC:
  • Broader Classification: BWC 5: Economic & Game-Theoretic Vulnerabilities
  • Primary Classification: BWC 5.1.3: Sandwich Attacks
  • Secondary Classification: BWC 10.4.1: EIP-7702 Delegation Risks
• Description: The convert() function in the ShibaSwap: Treasure Finder contract lacked slippage protection, enabling exploitation through sandwich attacks. Additionally, its onlyEOA() modifier, intended to prevent contract calls, was bypassed using an EIP-7702 account, demonstrating a protocol upgrade-induced vulnerability.
• References:
  • Exploit Tx 1
  • Flagged by: @TenArmorAlert

---

2025-08-23 - 2

• Date: 2025-08-23
• Project: RansomVault Hacker
• Value Lost: $90,000
• Chain: Ethereum Mainnet
• BWC:
  • Broader Classification: BWC 5: Economic & Game-Theoretic Vulnerabilities
  • Primary Classification: BWC 5.1.1: Front-Running
• Description: This incident involves a hacker's (Hacker A) ransomware contract being exploited by another attacker (Hacker B), likely an MEV bot. The withdrawETH function was protected by a password that was passed as a cleartext argument in the transaction data. When Hacker A tried to withdraw the ransom, their transaction sat in the public mempool. Hacker B scanned the mempool, extracted the password, and submitted their own transaction with a higher gas fee to front-run Hacker A and steal the funds.
• References:
  • Exploit Tx

---

2025-08-13 - 1

• Date: 2025-08-13
• Project: Coinbase
• Value Lost: $550,000
• Chain: Mainnet
• BWC:
  • Broader Classification: BWC 2: Access Control Vulnerabilities
  • Primary Classification: BWC 2.2.1: Unsafe Token Approvals
• Description: Coinbase's fee-receiver wallet lost approximately $550,000 due to mistakenly granting ERC-20 allowances to 0x's Mainnet Settler, a permissionless execution contract. This was not a hack but a configuration error that handed a sophisticated MEV bot the approval to drain dozens of token types from Coinbase's treasury, as anyone can call the Settler contract.
• References:
  • Exploit Tx
  • Flagged by: @deeberiroz

---

2025-07-28 - 5

• Date: 2025-07-28
• Project: SuperRare
• Value Lost: $730,000
• Chain: Mainnet
• BWC:
  • Broader Classification: BWC 2: Access Control Vulnerabilities
  • Primary Classification: BWC 2.1.1: Missing Access Control
• Description: The core of the vulnerability was a logically flawed require statement intended to enforce access control. The code require((msg.sender != owner() || msg.sender != address(0xc2...)), "Not authorized..."); always evaluates to true for any caller, because an address cannot be two different values simultaneously. This logical error rendered the authorization check completely ineffective, making it functionally missing.
• References:
  • Vulnerable Implementation

---

2025-07-15 - 4

• Date: 2025-07-15
• Project: Arcadia
• Value Lost: $3,600,000
• Chain: Base
• BWC:
  • Broader Classification: BWC 2: Access Control Vulnerabilities
  • Primary Classification: BWC 2.2.4: Composable Arbitrary Calls
• Description: The attacker exploited a missing validation vulnerability in the Asset Manager contracts. By supplying malicious calldata to a rebalancing function, the attacker tricked the Asset Manager into making an arbitrary call to a victim's Arcadia Account. Since the victim had authorized the Asset Manager, this call was successful, allowing the attacker to impersonate the Asset Manager and drain the victim's funds.
• References:
  • Postmortem

---

2025-07-09 - 3

• Date: 2025-07-09
• Project: GMX
• Value Lost: $42,000,000
• Chain: Arbitrum
• BWC:
  • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
  • Primary Classification: BWC 3.1.4: Composable Reentrancy
• Description: The GMX protocol was exploited via a sophisticated composable reentrancy attack. The vulnerability was in the PositionManager.executeDecreaseOrder() function, which made an external call (an ETH refund) to the attacker's contract. The attacker's contract then re-entered the GMX protocol, opening a large leveraged position before the initial transaction was complete. This manipulation artificially inflated the Assets Under Management (AUM) of the GLP pool, allowing the attacker to redeem their own GLP tokens at a much higher price.
• References:
  • Slowmist Analysis

---

2025-07-09 - 2

• Date: 2025-07-09
• Project: ZKSwap
• Value Lost: $5,000,000
• Chain: N/A
• BWC:
  • Broader Classification: BWC 4: Input & Data Validation Vulnerabilities
  • Primary Classification: BWC 4.3.1: Missing Signature Validation
• Description: The verifyExitProof() function contained a hardcoded return true; statement, which effectively disabled the cryptographic verification of withdrawal proofs. An attacker activated the emergency "Exodus Mode" and repeatedly called the exit() function with fabricated proofs, which the contract accepted due to the skipped verification, allowing the attacker to drain funds.
• References:
  • Postmortem

---

2025-07-02 - 1

• Date: 2025-07-02
• Project: Quickswap
• Value Lost: Unknown
• Chain: Polygon
• BWC:
  • Broader Classification: BWC 10: Network & Consensus Evolution Attacks
  • Primary Classification: BWC 10.4.1: EIP-7702 Delegation Risks
• Description: The contract implemented an onlyEOA() modifier to prevent contract-based calls (like flash loans). An attacker leveraged an EIP-7702 transaction to bypass this check. EIP-7702 allows a contract to execute a call while setting the msg.sender to the EOA that signed the transaction. This made the onlyEOA() check return true, tricking the contract into believing the caller was a standard user while allowing the attacker to execute complex contract logic.
• References:
  • Vulnerable Address

---

2025-06-20 - 3

• Date: 2025-06-20
• Project: Unidentified Staking Contract
• Value Lost: ~$32,000
• Chain: Mainnet
• BWC:
  • Broader Classification: BWC 7: Low-Level & EVM-Specific Vulnerabilities
  • Primary Classification: BWC 7.1: Unchecked Return Values
  • Secondary Classification: BWC 3.3.4: Weird ERC20 Behaviors
• Description: The staking contract was exploited due to its failure to check the return value of an external call to a legacy Compound cToken (cUSDC). An attacker called the deposit function, but the underlying cUSDC.transferFrom call failed and returned false instead of reverting. The victim contract did not validate this boolean response and proceeded as if the deposit were successful, incorrectly updating the attacker's internal balance. The attacker was then able to withdraw real funds from the contract based on their unbacked, phantom deposit.
• References:
  • Exploit Tx
  • Flagged by: @deeberiroz

---

2025-06-17 - 2

• Date: 2025-06-17
• Project: MetaPool (mpETH)
• Value Lost: $227,785
• Chain: Mainnet
• BWC:
  • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
  • Primary Classification: BWC 3.2.7: Broken Invariant via Function Overriding
• Description: The mpETH staking contract, which inherited from OpenZeppelin's ERC4626Upgradeable, was exploited due to a broken security invariant. The parent contract's security relied on an internal _deposit function to check that assets were received before minting shares. The mpETH contract overrode this internal function and moved the asset receipt check into its own public deposit function. However, the team failed to account for the inherited public mint function, which now called the new, check-less _deposit function, allowing an attacker to mint shares for free.
• References:
  • X Alert
  • Attack Tx (MEV Bot)

---

2025-06-02 - 1

• Date: 2025-06-02
• Project: #FPC
• Value Lost: $4,700,000
• Chain: BSC
• BWC:
  • Broader Classification: BWC 5: Economic & Game-Theoretic Vulnerabilities
  • Primary Classification: BWC 5.2.1: Price Manipulation
  • Secondary Classification: BWC 3.3.2: Fee-on-Transfer & Rebase Accounting Issues
• Description: The protocol was exploited through a price manipulation attack that capitalized on the token's non-standard burn-on-transfer mechanism. The FPC token was designed to burn a portion of its own tokens directly from the liquidity pool during every sell transaction. An attacker used a flash loan to execute a large buy, drastically inflating the token's price, and then immediately sold the tokens. The flawed burn logic, combined with the artificially high price, allowed the attacker to drain the pool's liquidity.
• References:
  • Attack Tx

---

2025-05-28 - 4

• Date: 2025-05-28
• Project: Cork Protocol
• Value Lost: ~$13,200,000 (3,761 wstETH)
• Chain: Ethereum Mainnet
• BWC:
  • Broader Classification: BWC 2: Access Control Vulnerabilities
  • Primary Classification: BWC 2.2.4: Composable Arbitrary Calls
  • Secondary Classification: BWC 5.2.1: Price Manipulation
• Description:
  • The protocol was drained via a highly sophisticated, two-vector exploit targeting complex interactions between its market automation and a custom Uniswap V4 hook.
  • 1. Price Manipulation (Setup): The attacker first exploited the market's rollover pricing logic. By executing a single trade in a low-volume period just before market expiry, they skewed the volume-weighted price calculation. This allowed them to purchase a massive number of Cover Tokens for a near-zero cost after the rollover completed.
  • 2. Arbitrary Call via Malicious Hook (Drain): The primary vulnerability was an access control flaw in Cork's hook integration. The attacker deployed their own malicious contract that also acted as a Uniswap hook. This malicious hook was able to interact with Cork's hook in a way that bypassed authorization checks, which were absent because Cork had integrated an older version of a Uniswap periphery contract before an explicit authorization feature was added upstream. This bypass allowed the attacker to illegitimately withdraw Depeg Swaps.
  • With both the cheaply acquired Cover Tokens and the stolen Depeg Swaps, the attacker was able to drain the Liquidity Vault of its assets.
• References:
  • Cork Protocol Exploit Post-Mortem
  • Exploiter Contract 1
  • Exploiter Contract 2

---

2025-05-23 - 3

• Date: 2025-05-23
• Project: Mango Markets Exploiter Trial
• Value Lost: $0 (Legal Precedent established, related to a $110M exploit)
• Chain: N/A (Legal/Off-Chain)
• BWC:
  • Broader Classification: BWC 11: Privacy & Regulatory Attack Vectors
  • Primary Classification: BWC 11.2.3: "Code is Law" Defense Exploitation
• Description: In a landmark ruling, U.S. District Judge Arun Subramanian vacated the fraud and manipulation convictions of Avraham Eisenberg. The judge determined that the evidence was insufficient to prove Eisenberg made "false representations" to Mango Markets, reasoning that as a decentralized, permissionless smart contract, the protocol could not be deceived. This decision validated the "code is law" defense in a US court, highlighting a critical regulatory vulnerability.
• References:
  • Court Ruling Document: Case 1:23-cr-00010-AS, Document 220

---

2025-05-18 - 2

• Date: 2025-05-18
• Project: KRC/BUSD AMM Pool
• Value Lost: Not Specified
• Chain: BSC
• BWC:
  • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
  • Primary Classification: BWC 3.3.2: Fee-on-Transfer & Rebase Accounting Issues
  • Secondary Classification: BWC 5.2.1: Price Manipulation
• Description: The KRC/BUSD AMM pool was drained by exploiting a deflationary (fee-on-transfer) mechanism in the KRC token. The token's contract burned 9% of the transfer amount from the recipient's balance if the recipient was the AMM pool. This burn was invisible to the AMM's accounting, causing a desynchronization where the pool's actual KRC balance became lower than its tracked reserves. The attacker repeatedly triggered this burn, manipulating the internal price before executing a final swap to drain the remaining BUSD.
• References:
  • Exploit Tx

---

2025-05-11 - 1

• Date: 2025-05-11
• Project: MBU Token
• Value Lost: $2,000,000
• Chain: BSC
• BWC:
  • Broader Classification: BWC 6: Arithmetic & Numeric Vulnerabilities
  • Primary Classification: BWC 6.5: Inconsistent Scaling Bugs
• Description: The MBU token contract was exploited due to an inconsistent scaling bug in its deposit function. The contract failed to properly normalize the decimal precision of different tokens when performing calculations. This allowed an attacker to deposit a small amount of BNB and receive a vastly disproportionate number of MBU tokens in return, which were then swapped for a profit of $2 million.
• References:
  • Exploit Tx
  • @openzeppelin Postmortem

---

2025-04-24 - 1

• Date: 2025-04-24
• Project: Zora Airdrop / 0x
• Value Lost: $128,000
• Chain: Base
• BWC:
  • Broader Classification: BWC 2: Access Control Vulnerabilities
  • Primary Classification: BWC 2.2.1: Unsafe Token Approvals
• Description: Zora's airdrop process allocated claimable $ZORA tokens to the 0x Settler contract, a permissionless contract designed to execute arbitrary transactions. An attacker exploited this by calling the Settler contract and instructing it to claim the tokens and send them to the attacker's own address. The root cause was the allocation of a claim (an unsafe approval) to a contract that was not designed to securely hold assets on its own behalf.
• References:
  • Exploit Tx
  • Threesigma Postmortem

---

2025-03-25 - 2

• Date: 2025-03-25
• Project: Magic Internet Money (@MIM_Spell)
• Value Lost: ~$12,900,000
• Chain: Arbitrum
• BWC:
  • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
  • Primary Classification: BWC 3.2.5: Broken State Adjustment
• Description: The vulnerability was in the integration between the CauldronV4 and RouterOrder contracts. When an attacker's position was liquidated, the collateral held within the RouterOrder was correctly transferred to the liquidator. However, the RouterOrder contract failed to update its internal state variable (inputAmount) that tracked this collateral. This created an inconsistent state where the Cauldron contract's solvency check still considered the liquidated assets as valid collateral, allowing the attacker to borrow against this "phantom collateral."
• References:
  • Liquidate and Borrow Again Tx

---

2025-03-05 - 1

• Date: 2025-03-05
• Project: 1inch (Fusion V1)
• Value Lost: ~$10,000,000 (Majority returned for a bounty)
• Chain: Ethereum Mainnet
• BWC:
  • Broader Classification: BWC 7: Low-Level & EVM-Specific Vulnerabilities
  • Primary Classification: BWC 7.2: Unsafe Storage & Memory Handling
  • Secondary Classification: BWC 6.1: Integer Overflow & Underflow
• Description:
  • The exploit targeted a critical calldata corruption vulnerability in the deprecated 1inch Settlement (Fusion V1) contract, which was written in low-level Yul.
  • The core of the vulnerability was an integer underflow in an assembly block that calculated a memory offset. By providing a crafted, extremely large interactionLength value in the order data, an attacker could cause the offset calculation to underflow.
  • This allowed the attacker to overwrite a different, controlled part of the calldata being assembled in memory. Specifically, they overwrote the legitimate resolver address in the order's suffix data with the victim's address (a market maker).
  • This tricked the Settlement contract into making a privileged callback to the victim's contract, triggering a function that drained the market maker's funds. The majority of funds were later returned by the attacker in exchange for a bounty.
• References:
  • Attack Tx
  • 1inch Post-Mortem

---

2025-02-23 - 1

• Date: 2025-02-23
• Project: ZeroLend
• Value Lost: ~$371,000 (Initial Exploit) + Undetermined ongoing extraction from new depositors
• Chain: Base
• BWC:
  • Broader Classification: BWC 5: Economic & Game-Theoretic Vulnerabilities
  • Primary Classification: BWC 5.2.1: Price Manipulation
  • Secondary Classification: BWC 1.1.7: User Disempowerment & Extractive Design ("Zombie Market" / Cover-up)
• Description:
  • Note: This incident occurred in 2025 but was publicly exposed by Rekt.news in Jan 2026 after a 10-month cover-up.
  • ZeroLend was drained of ~$371k on this date, but the team maintained a "Zombie Market" for months, attributing withdrawal failures to "high utilization" or UI bugs while keeping the deposit function active.
  • Vulnerability: The attacker utilized PT-LBTC (a Pendle Principal Token) as collateral. By manipulating the price of this illiquid derivative on the lending market, the attacker was able to borrow ~3.92 real LBTC against it, effectively draining the pool. This attack vector was identical to the Ionic Money exploit that occurred just 18 days prior (Feb 4, 2025).
  • Cover-up & Ongoing Extraction: ZeroLend did not disclose the loss. On-chain analysis revealed that a Gnosis Safe (created two months post-exploit) utilizing Gelato automation has been systematically withdrawing liquidity provided by new, unsuspecting depositors, effectively turning the broken protocol into a trap for users.
  • Status (as of Jan 2026): The ZERO token has been delisted from major exchanges, GitHub activity has ceased, and the protocol remains largely abandoned by developers despite the frontend remaining accessible.
• References:
  • Rekt News: Zero To Lend
  • Attacker Address (Base)

---

2025-02-03 - 2

• Date: 2025-02-03
• Project: Bybit (Centralized Exchange)
• Value Lost: ~$1,400,000,000 (401,347 ETH)
• Chain: Ethereum
• BWC:
  • Broader Classification: BWC 1: Ecosystem & Off-Chain Risks
  • Primary Classification: BWC 1.4.4: Supply Chain Attacks (Compromised Dev Machine)
  • Secondary Classification: BWC 1.3.3: Front-End Hijack/Spoofing (UI Manipulation)
• Description:
  • Bybit suffered a massive $1.4B theft from its cold wallet due to a sophisticated supply chain attack targeting its multi-signature setup.
  • Vulnerability: The attack did not exploit the smart contracts directly but rather the Safe Wallet user interface via a supply chain compromise. A developer's machine was compromised, allowing attackers to inject malicious JavaScript into the Safe UI build.
  • Attack Flow:
    1. Injection: Malicious JS was injected into the Safe UI via a compromised dev machine.
    2. Deception: When signers attempted routine internal transfers, the script intercepted the request. It silently replaced the transaction parameters with attacker-controlled data (redirecting the proxy implementation).
    3. Blind Signing: The script sent the malicious payload to the hardware wallet for signing. Crucially, the signers failed to verify the raw data on the hardware device screen against the intended transaction.
    4. Execution: The valid signatures were used to upgrade the wallet's implementation to a malicious contract, allowing the attacker to drain 401,347 ETH.
  • Key Lesson: Multi-signature owners must verify hardware wallet prompts against the intended transaction structure (verify what you sign).
• References:
  • Safe SecOps Guidelines
  • Incident Investigation Report

---

2025-01-13 - 1

• Date: 2025-01-13
• Project: UniLend
• Value Lost: ~$197,000
• Chain: EVM
• BWC:
  • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
  • Primary Classification: BWC 3.2.5: Broken State Adjustment
• Description: The attacker exploited a critical flaw in the redeemUnderlying function's health factor calculation due to an incorrect order of operations. When a user redeemed assets, the contract would first burn their LP shares and then perform the health check. However, the check incorrectly used the contract's current, pre-withdrawal token balance (which was still high) against the user's new, post-burn share balance (which was low). This mismatch led to a massively inflated health factor calculation, allowing an undercollateralized position to appear safe and enabling the attacker to drain funds.
• References:
  • Attack Tx
  • SlowMist Analysis

---

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.

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:
  • TenArmor Alert
  • Contract Analysis

---

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:
  • Cantina Vulnerability Walkthrough

---

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:
  • Rekt News - Polter Finance Rekt
  • CertiK Analysis

---

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:
  • Verichains Ramses Hack Analysis
  • Medium Analysis

---

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:
  • Spearbit / Cantina Audit Report
  • Royco Security Review

---

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:
  • Cantina Vulnerability Walkthrough

---

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:
  • Verichains AIZPT Hack Analysis
  • BlockSec Exploit Transaction

---

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:
  • BlockSec Exploit Transaction
  • LearnBlockchain.cn Analysis

---

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:
  • OpenZeppelin Uniswap V4 Core Audit

---

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:
  • Immunefi: Top 5 Bugs from the Fuel Attackathon (Report 32465)
  • OpenZeppelin Web3 Security Auditor's Rewind 2024

---

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:
  • Contract Analysis
  • Exploit Transaction

---

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:
  • Penpie Post-Mortem
  • Olympix Analysis
  • Contract Analysis

---

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:
  • Rekt News - Onyx Protocol Rekt II

---

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:
  • Maia DAO Post-Mortem

---

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:
  • SolidityScan Analysis
  • TenArmor X Alert

---

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:
  • Bedrock UniBTC Hack Analysis (BlockApex)
  • Vulnerable Code (GitHub)

---

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:
  • Halborn Analysis: Ronin Network Hack
  • Verichains Post-Mortem Analysis

---

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:
  • Halborn Hack Analysis
  • Rekt News Coverage

---

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:
  • OpenZeppelin Uniswap V4 Periphery Audit

---

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:
  • Immunefi Report #30655

---

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:
  • Code4rena Findings Report
  • Vulnerable Code

---

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:
  • OpenZeppelin Uniswap V4 Periphery Audit

---

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:
  • Delta Prime Post-Mortem

---

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:
  • Lunaray Hack Analysis
  • Verichains Post-Mortem

---

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:
  • Rekt News - Li.Fi / Jumper Rekt
  • Li.Fi Post-Mortem

---

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:
  • SolidityScan Analysis
  • Contract Analysis

---

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:
  • OpenZeppelin Analysis (Contextual Link based on description)

---

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:
  • OpenZeppelin Taiko Protocol Audit
  • Medium: Different Parsers, Different Results

---

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:
  • Medium Analysis
  • CertiK Alert

---

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:
  • OpenZeppelin Linea Prover Audit

---

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:
  • Cantina / Solodit Audit Report

---

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:
  • Sherlock Findings Report

---

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:
  • Immunefi Bugfix Review
  • Gelato Security Docs

---

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:
  • Sherlock Audit Issue #146

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:
  • Exploit Transaction
  • Contract Analysis

---

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:
  • DecurityHQ Analysis

---

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:
  • OpenZeppelin Scroll Batch Token Bridge Audit

---

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:
  • Verichains: Unveiling the Scroll Token Attack

---

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:
  • Neptune Mutual Analysis

---

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:
  • Neptune Mutual Analysis
  • X Alert by @shoucccc

---

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:
  • SolidityScan Hack Analysis
  • Contract Analysis

---

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:
  • Neptune Mutual Analysis
  • Exploit Transaction

---

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:
  • DeFiHackLabs Exploit Reproduction
  • Contract Analysis

---

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:
  • Hedgey Finance Incident Analysis (CertiK)
  • Halborn Hack Explanation

---

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:
  • Code4rena Findings Report

---

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:
  • OpenZeppelin Mantle V2 Audit
  • Web3 Security Auditor's Rewind 2024

---

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:
  • Lunaray Hack Analysis

---

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:
  • OpenZeppelin Mantle Audit

---

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:
  • Code4rena Findings Report
  • GitHub Issue #60

---

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:
  • C423n4 Finding

---

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:
  • Trust Security: Learning by Breaking - Part 2 (Stargate)

---

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:
  • Trust Security: Learning by Breaking - Part 1 (Nonce)
  • Trust Security: Learning by Breaking - Part 3 (OFT/ONFT)

---

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:
  • Rekt News - SSS Rekt
  • Neptune Mutual Analysis

---

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:
  • WOOFI Post-Mortem
  • Cyfrin Hack Analysis

---

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:
  • Prisma Finance Post-Mortem
  • Contract Analysis

---

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:
  • Contract Analysis
  • CertiK Alert

---

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:
  • OpenZeppelin Restake Finance Audit

---

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:
  • Rekt News - Socket Rekt
  • Socket Post-Mortem

---

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:
  • Immunefi Bugfix Review

---

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:
  • Attack Tx 1
  • Attack Tx 2
  • Rekt News Article

---

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.

2023 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.

---

2023-06-22 - 1

• Date: 2023-06-22 (Disclosure Date)
• Project: General EIP-2612 Implementations
• Value Lost: $0 (Vulnerability Disclosure)
• Chain: EVM
• 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:
  • Security researchers at Trust Security detailed a Denial of Service vector known as "Permit Griefing" affecting contracts integrating EIP-2612.
  • The Flaw: Many contracts implement a "multicall" or "permit-then-execute" flow where permit() is called to set token allowances before executing a trade or deposit. The contracts typically expect the permit() call to succeed and will revert the entire transaction if it fails.
  • The Exploit: Because the permit signature is visible in the mempool, an attacker can front-run the user's transaction and submit the permit() call themselves. The attacker's transaction succeeds, consuming the user's nonce and granting the approval. However, when the user's transaction subsequently attempts to call permit() with the same (now used) nonce, it reverts. Although the approval exists, the user's intent (the trade or deposit) is blocked.
• References:
  • Trust Security: Permission Denied

---

2023-12-06 - 1

• Date: 2023-12-06
• Project: TIME Contract ERC2771 Exploit
• Value Lost: $212,000
• Chain: Ethereum Mainnet
• BWC:
  • Broader Classification: BWC 4: Input & Data Validation Vulnerabilities
  • Primary Classification: BWC 4.4.1: ERC-2771 + Multicall
• Description:
  • The TIME contract was exploited due to a vulnerability in its multicall function, which was set as a trusted forwarder for ERC-2771 meta-transactions. The issue stemmed from the multicall function not complying with the ERC-2771 standard for trusted forwarders.
  • The Flaw: A compliant trusted forwarder must append the original msg.sender (20 bytes) to the end of the calldata it forwards. The TIME contract's multicall function failed to do this.

  • // Flawed Multicall implementation
    function aggregate(Call[] calldata calls) public payable returns (uint256 blockNumber, bytes[] memory returnData) {
        ...
        (success, returnData[i]) = call.target.call(call.callData); // Fails to append msg.sender
        ...
    }
    

  • The Mechanism: The ERC2771Context contract, used for handling meta-transactions, retrieves the sender's address by reading the last 20 bytes of the calldata it receives from a trusted forwarder.

  • // ERC2771Context logic to extract sender
    function _msgSender() internal view virtual override returns (address sender) {
        if (isTrustedForwarder(msg.sender) && msg.data.length >= 20) {
            assembly {
                sender := shr(96, calldataload(sub(calldatasize(), 20)))
            }
        } else {
            return super._msgSender();
        }
    }
    

  • The Exploit: Because the flawed multicall didn't append the real sender, the last 20 bytes of the original calldata provided by the attacker were read by _msgSender. This allowed the attacker to craft a call where the last 20 bytes contained any address they wished to impersonate, such as the contract's owner, thereby bypassing access controls and draining funds.
  • The Fix: A secure multicall implementation appends the sender, ensuring the correct address is forwarded.

  • // Secure Multicall3 implementation
    function aggregate(Call[] calldata calls) public payable returns (uint256 blockNumber, bytes[] memory returnData) {
        ...
        (success, returnData[i]) = call.target.call(abi.encodePacked(call.callData, msg.sender)); // Correctly appends msg.sender
        ...
    }
    

• References:
  • Time Exploit
  • Openzeppelin ERC2771 disclosure

---

2023-09-25 - 1

• Date: 2023-09-25 (Disclosure Date)
• Project: Multiple Smart Accounts (ERC-1271 Implementations)
• Value Lost: $0 (Critical Vulnerability Disclosure)
• Chain: EVM Chains (Multi-chain)
• BWC:
  • Broader Classification: BWC 4: Input & Data Validation Vulnerabilities
  • Primary Classification: BWC 4.3.2: Incomplete Signature Schemes
  • Secondary Classification: BWC 4.3.1: Missing Signature Validation
• Description:
  • A widespread vulnerability was identified in the implementation of ERC-1271 isValidSignature across multiple smart account providers.
  • The Flaw: The standard implementation often only verified that the signature recovered to the correct owner address. It failed to verify that the signature was intended specifically for the contract instance receiving it.
  • The Exploit: If a user deployed multiple smart accounts (e.g., Account A and Account B) controlled by the same EOA key, a valid signature intended for Account A (e.g., a Permit signature) could be replayed on Account B because Account B only checked if the signer was the owner (which was true). This allowed attackers to replay authorizations across different accounts or chains owned by the same user.
  • Vulnerable Code Pattern:

    function isValidSignature(bytes32 _hash, bytes calldata _signature) external view returns (bytes4) {
        // VULNERABLE: Only checks signer identity, not the destination scope
        if (recoverSigner(_hash, _signature) == owner) {
            return 0x1626ba7e;
        } else {
            return 0xffffffff;
        }
    }
    

• References:
  • Curious Apple Mirror Post
  • Alchemy Security Update

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.

2020 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.

---

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.

2020 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.

---

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.

2020 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.

---

2020-03-12 - MakerDAO Black Thursday

• Date: 2020-03-12
• Project: MakerDAO
• Value Lost: $8,300,000
• Chain: Ethereum Mainnet
• BWC:
  • Broader Classification: BWC 5: Economic & Game-Theoretic Vulnerabilities, BWC 1: Ecosystem & Off-Chain Risks
  • Primary Classification: BWC 5.4.1: Cascade Failure from Network Congestion, BWC 1.3.7: Flawed Off-Chain Infrastructure
• Description:
  • On "Black Thursday," a massive ETH price drop caused extreme network congestion and gas price spikes on Ethereum.
  • This led to a cascade of failures in the MakerDAO system:
    1. Oracle Lag: Price oracles failed to update in a timely manner due to the high gas fees.
    2. Mass Liquidations: When the oracles finally updated with a much lower price, a large number of collateralized debt positions (CDPs) were liquidated simultaneously.
    3. Keeper Failure: The reference keeper software, used by most auction bidders, was not designed to handle the extreme gas prices and failed to submit bids.
    4. Zero-Bid Auctions: The lack of competing bids allowed a few liquidators to win collateral auctions with bids of 0 DAI, extracting over $8.3 million worth of ETH for free.
  • This incident was a systemic failure caused by the protocol's inability to handle extreme market volatility and network congestion, coupled with a critical failure in its off-chain keeper infrastructure.
• References:
  • ConsenSys - Black Thursday: The Day DeFi Died (For a Bit)
  • MakerDAO Posrmortem

---

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.

2017 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.

---

2017-11-06 - Parity Multi-Sig Library Self-Destruct

• Date: 2017-11-06
• Project: Parity
• Value Lost: $300,000,000 (approx. 513,774 ETH frozen)
• Chain: Ethereum Mainnet
• BWC:
  • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
  • Primary Classification: BWC 3.2.1: Improper Initialization
• Description:
  • The Parity multi-signature wallets relied on a single shared library contract for their logic (acting as the implementation for many light proxies).
  • This library contract was deployed but left uninitialized, meaning it had no owner.
  • A user (devops199) was able to call the initWallet function on the library contract itself, effectively claiming ownership of the standard library.
  • The user then triggered the kill() function (Tx: 0x47f7...f690), which executed selfdestruct.
  • The destruction of the library contract rendered all dependent multi-sig wallets non-functional, permanently freezing the funds held within them.
• References:
  • I accidentally killed it and evaporated $300 million
  • Parity Security Alert

---

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.

2016 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.

---

2016-06-17 - The DAO Hack

• Date: 2016-06-17
• Project: The DAO
• Value Lost: $60,000,000 (approx. 3.6M ETH)
• Chain: Ethereum Mainnet
• BWC:
  • Broader Classification: BWC 3: Smart Contract Logic & State Manipulation
  • Primary Classification: BWC 3.1.1: Standard Reentrancy
• Description:
  • The DAO smart contract contained a critical reentrancy vulnerability in its splitDAO function.
  • The contract logic performed an external call to send Ether to the user before updating the user's internal balance (or share count).
  • The attacker deployed a malicious contract with a fallback function. When The DAO contract sent ETH to this malicious contract, the fallback function triggered, recursively calling the splitDAO function again.
  • Since the state (balance) hadn't been updated yet, the subsequent calls were also successful, allowing the attacker to drain funds repeatedly in a single transaction stack.
  • This event led to the controversial hard fork that created Ethereum (ETH) and Ethereum Classic (ETC).

Vulnerable Code Pattern

// Simplified representation of the vulnerability
mapping(address => uint) public balances;

function withdraw() public {
    uint amount = balances[msg.sender];
    
    // Check
    require(amount > 0);

    // Interaction (Vulnerability: External call before state update)
    (bool sent, ) = msg.sender.call{value: amount}("");
    require(sent, "Failed to send Ether");

    // Effect
    balances[msg.sender] = 0;
}

• References:
  • Chainlink - Reentrancy Attacks and The DAO Hack
  • Phil Daian - Analysis of the DAO exploit

---

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.

Services Agreement Template for a Smart Contract Audit

This Services Agreement ("Agreement") is entered into between [Client Name], hereinafter referred to as "Client," and [Auditor Name], hereinafter referred to as "Auditor," collectively referred to as the "Parties."

1. Scope of Work

The Auditor agrees to perform a security audit of the Client's smart contracts deployed on [blockchain network], specifically [list contract addresses or repository links]. The audit will assess the code for vulnerabilities, logic errors, and compliance with industry best practices.

2. Audit Process

• Initial Review: The Auditor will perform an initial assessment of the smart contract code and share preliminary findings.
• Client Feedback: The Client may address the findings and implement fixes based on the initial review.
• Final Review: The Auditor will review the updated code and prepare a final audit report.
• Report Delivery: The final report will detail vulnerabilities, recommendations, and an overall security assessment.

3. Timeline

The audit will begin on [start date] and is expected to conclude by [end date], with the final report delivered by [report delivery date]. The Auditor is available to work from the 1st to the 21st of each month, dedicating 12 hours per day, 7 days a week, for a total of 21 consecutive days.

4. Pricing and Payment Terms

4.1 Pricing Formula

The total fee for the audit is calculated based on the number of Solidity lines of code (SLOC), determined using the following method:

• Code Formatting: The Solidity code must be formatted using forge fmt with the following settings:

   export FOUNDRY_FMT_SINGLE_LINE_STATEMENT_BLOCKS="multi"
   export FOUNDRY_FMT_LINE_LENGTH=90
   export FOUNDRY_FMT_TAB_WIDTH=4
   export FOUNDRY_FMT_MULTILINE_FUNC_HEADER="params_first_multi"
   export FOUNDRY_FMT_BRACKET_SPACING=false
   export FOUNDRY_FMT_INT_TYPES="long"
   export FOUNDRY_FMT_QUOTE_STYLE="double"
   export FOUNDRY_FMT_NUMBER_UNDERSCORE="thousands"
   export FOUNDRY_FMT_HEX_UNDERSCORE="remove"
   export FOUNDRY_FMT_OVERRIDE_SPACING=false
   export FOUNDRY_FMT_WRAP_COMMENTS=false
   export FOUNDRY_FMT_CONTRACT_NEW_LINES=true
   export FOUNDRY_FMT_SORT_IMPORTS=true
  

• Counting Lines of Code: After formatting, the SLOC will be calculated using cloc, a GNU utility, based on its output for Solidity files.
• The total fee is determined by the formula:

$TotalFee=\left(\frac{a\times \text{testing factor}}{200}+12\right)\times 200\text{ USD}$

Where:

• ( a ) = SLOC, as calculated by cloc after formatting with forge fmt using the settings above.

• Testing factor = 2 (if the Client provides tests) or 3 (if the Auditor must write tests for Proof of Concept (POC)).

• Audit Time: The adjusted SLOC (after applying the testing factor) is divided by 200 (assuming the Auditor audits 200 SLOC per hour).

• Report Compilation: An additional 12 hours is added for compiling the audit report and quality-of-life (QOL) documentation.

• Hourly Rate: The total hours are multiplied by the Auditor’s rate of {200 USD} per hour.

4.2 Deposit

The Client shall pay a 30% non-refundable deposit of the estimated total fee upon signing this Agreement. The estimate will be based on an initial SLOC count provided by the Client.

4.3 Final Payment

The final payment will be adjusted based on the actual SLOC count at the time of the audit and is due upon delivery of the final audit report.

4.4 Payment Method

Payments shall be made in [cryptocurrency, e.g., ETH, USDC] to the Auditor’s wallet address [wallet address].

4.5 Late Payments

Late payments will incur interest at [rate] per [time period].

5. Responsibilities

Client Responsibilities:

• Provide the final commit of the smart contracts by [date].
• Indicate whether tests are provided or if the Auditor must write tests for POC.
• Be available for meetings and discussions as required.
• Implement recommended fixes from the audit findings.

Auditor Responsibilities:

• Perform the audit with professionalism and diligence.
• Deliver a comprehensive final report by the agreed delivery date.
• Maintain confidentiality of the Client’s information.

6. Changes and Unforeseen Circumstances

• Scope Changes: Any changes to the scope must be agreed in writing and may adjust the timeline and fees. New functionality added during the fix audit may incur additional costs.

• Auditor Unavailability: If the Auditor cannot perform the audit due to unforeseen circumstances, a qualified replacement will be provided, or the timeline will be adjusted.

• Client Delays: If the Client is not ready by the start date, the Auditor may reschedule or charge additional fees.

• SLOC Disputes: Any disagreements over the SLOC count will be resolved by re-running cloc on the code formatted with the specified forge fmt settings.

7. Intellectual Property

The Auditor retains ownership of any tools, methodologies, or concepts developed during the audit, unless otherwise agreed.

8. Liability Limitations

The Auditor is not liable for undetected vulnerabilities or exploits after the audit. The Client understands that the audit is a point-in-time evaluation and does not ensure absolute security.

9. Cancellation Policy

The Client may cancel with at least 7 days’ notice, forfeiting the deposit. Cancellations with less than 7 days’ notice will incur a fee of 50% of the estimated total fee. The Auditor may cancel if the Client fails to meet their obligations, with the deposit remaining non-refundable.

10. Dispute Resolution

Disputes arising from this Agreement will be resolved through [mediation, arbitration, or jurisdiction-specific legal process].

11. Compliance and Legal Framework

The Client confirms that all funds used for payment are from legitimate sources and comply with anti-money laundering (AML) regulations. The Auditor may require the Client to complete know-your-business (KYB) procedures before starting the audit. Both Parties agree to adhere to applicable laws and regulations.

12. Miscellaneous

Confidentiality: Both Parties will protect sensitive information shared during the engagement. Report Publication: The Auditor may publish the audit report after 30 days from delivery, unless the Client objects in writing. Governing Law: This Agreement is governed by the laws of [jurisdiction].

13. Signatures

By signing below, both Parties confirm they have read, understood, and agree to be bound by this Agreement.

[Client Signature] [Date] [Auditor Signature] [Date]