Original Article Title: "Retrospect of 20 Hacks: Why Is the Crypto Industry Always Hacked?"
Original Article Authors: Changan, Biteye
In April 2026, Kelp DAO was hacked for $2.92 billion. The attacker used uncollateralized tokens to borrow real assets on Aave, resulting in over $2 billion in bad debt in just 46 minutes.
This was just one of many hacks this year. Drift was hacked for $2.85 billion, Step Finance for around $30 million, Resolv Labs for around $23 million. The news of hacks kept coming one after another, with the industry unable to react before the next project was breached.
Is there a pattern behind these events? How do hackers attack protocols?
This article summarizes the 20 most representative historical and recent hack cases, attempting to find answers.
Based on the 20 cases we've compiled, three clear patterns emerge:
· The majority of cases involve technical vulnerabilities, but the losses from individual hacks are relatively limited; permissioned and social engineering attack cases, although fewer, contribute to the majority of the total losses.
· The scale of permissioned attacks is increasing. In the 20 cases, the four largest losses all involved the North Korean hacker group.
· The battlefield of technical vulnerabilities is shifting, and cross-chain bridges have never been secure.
Hack Reason:
The North Korean hacker group Lazarus Group (FBI and ZachXBT highly confident attribution, Operation "TraderTraitor") breached Safe Wallet's multi-signature mechanism through front-end UI hijacking + multi-signature fraud.
The attacker injected malicious JavaScript code into the Safe Wallet frontend. When the multi-signature holders (6 signers) initiated a regular cold wallet transfer, the UI displayed the correct receiving address and amount, but the underlying Call Data was tampered with, redirecting 401,000 ETH to the attacker's address. Under the deception of "out of sight, out of mind," 3 out of 6 signers approved the transaction, and the funds were lost instantly.
Root Cause: The multi-signature relied on human-machine interaction, and the frontend's failure to independently verify led to a breakdown in mathematical security. Tether froze the related USDT within hours, while Circle delayed freezing USDC for 24 hours, exacerbating the loss. This event exposed the fatal threat of social engineering and UI attacks to centralized exchanges, leading to the emergence of transaction verification networks like Safenet.
This event bears a striking resemblance to the Drift Protocol incident in April 2026 ($285M): targeted social engineering to establish trust, followed by UI/signature fraud, signaling a shift by hackers from contract vulnerabilities to "human-machine weaknesses."
In the subsequent handling of the situation, Bybit promptly utilized its own funds to fully compensate all losses, ensuring zero loss for users, and the platform is currently operating stably.
Theft Reason:
The North Korean hacker group Lazarus Group successfully took full control of the validation node's private keys through social engineering and backdoor means.
The attacker breached the internal systems of Sky Mavis and exploited a backdoor in a gas-free RPC node, taking control of 5 out of 9 validation nodes (including 4 Sky Mavis nodes and 1 Axie DAO node). Subsequently, they crafted two fake withdrawal transactions, illicitly siphoning off 173,600 ETH and 25.5M USDC.
The fundamental reason for this event lies in the validation authority being highly concentrated in a small number of nodes in the cross-chain bridge design. In the face of targeted social engineering attacks, the threshold of 5 out of 9 nodes required for signatures to complete transactions was almost meaningless.
Theft Reason:
The core reason for the theft from the Poly Network was a critical vulnerability in the permission management design of the cross-chain contracts.
The attacker exploited the relationship between the EthCrossChainManager and EthCrossChainData, two high-privilege contracts, to forge an executable function call.
Due to the fact that the EthCrossChainManager itself has the permission to modify the Keeper public key, and the _method parameter used in the call can be customized by the user, the attacker was able to successfully invoke the putCurEpochConPubKeyBytes function, which originally could only be executed by high-level permissions, by constructing a hash collision.
As a result, the attacker replaced their own public key with the legitimate manager's public key, gained control of cross-chain assets, and ultimately transferred out funds from multiple chains.
Theft Reason:
Normally, when a user wants to transfer assets from one chain to another, the system must first confirm that the assets have indeed been deposited, and the related signatures are indeed genuine and valid, only then will the corresponding assets be generated on the other chain.
The issue with Wormhole lies in the "signature verification" step. Wormhole's code used a deprecated and insufficiently secure function to check if the transaction is legitimate. This function was originally intended to confirm whether the signature verification had been completed by the system upfront. However, its check was not rigorous, providing an opportunity for attackers.
Exploiting this vulnerability, the attacker forged a set of information that appeared to have already been "verified," leading the system to mistakenly believe that this cross-chain operation was genuine and valid. In other words, the system was supposed to confirm first whether the money had indeed been locked in, but because the verification step was bypassed, the system directly trusted the false proof submitted by the attacker.
Thus, the attacker was able to mint a large amount of wETH out of thin air without actually depositing sufficient assets. After generating these assets, they were further transferred and exchanged, ultimately resulting in Wormhole losing approximately $326 million.
Theft Reason:
The DPRK hacker group engaged in a targeted infiltration for six months, combined with the Solana Durable Nonce presign scam to carry out the attack.
Starting from the fall of 2025, attackers masqueraded as a quantitative trading firm, established offline trust with Drift contributors at multiple international crypto conferences, and invested over a million dollars into the Ecosystem Vault to build credibility. After gaining trust, the attackers induced Security Council members to pre-sign multiple seemingly harmless transactions: leveraging Solana's Durable Nonce mechanism to conceal ownership transfer instructions. Meanwhile, Drift had just completed the migration to zero-latency multisig, eliminating the window for post-execution detection and intervention.
Once obtaining protocol control, the attackers registered a fake token called CVT with only a few hundred dollars of actual liquidity, creating a price illusion through wash trading, then deposited 500 million CVT as collateral into the protocol, borrowing $285 million of USDC, SOL, and ETH. The entire execution phase lasted only 12 minutes.
Drift's official statement, along with the SEAL 911 security team, attributed this attack to a "medium-to-high confidence" DPRK-affiliated entity (North Korean state-backed hacker group), with the executioner not being a native North Korean but a third-party intermediary controlled by them through offline contacts.
Reason for the Theft:
The core of this attack revolved around a multisig wallet being gradually compromised and ultimately replaced by a malicious contract.
The attacker first obtained permissions from some signers through phishing and other methods (including direct compromise and signature inducement). Building on this, they misled other signers through a spoofed interface, causing them to unknowingly approve malicious transactions.
After collecting enough signatures, instead of directly transferring assets, the attacker leveraged the multisig wallet's upgradability feature to perform a contract upgrade, replacing the original implementation contract with their deployed malicious contract.
Once this malicious contract was set with the new execution logic, all subsequent transactions were redirected, funneling funds continuously to the attacker's address. Eventually, full control of the multisig wallet was taken over, and on-chain assets were gradually siphoned out.
Reason for Theft:
This attack originated from an arithmetic overflow bug in the protocol's liquidity calculation.
Specifically, Cetus's mathematical functions used for large number calculations contained a boundary check error. When a certain value reached the critical point, the system failed to recognize an imminent overflow, continued with the calculation, and resulted in an abnormally large output.
The attacker constructed a series of operations around this:
First, they created extreme price conditions through large transactions, then positioned liquidity in a specific range, only depositing a minimal amount of assets (dust level). Under these conditions, the overflow issue in the contract was triggered, causing the system to believe the attacker should receive a liquidity share far greater than actually contributed.
Subsequently, the attacker used these inflated shares to perform liquidity removal operations, extracting assets significantly higher than initially provided from the pool. This entire process could be repeated, continuously draining the pool funds and ultimately resulting in significant losses.
Reason for Theft:
The core of this attack was the compromise of a high-privilege minting account's private key due to access control failure.
Gala's contract itself had permission restrictions on the mint function, but one of the accounts with minting privileges (minter account) had its private key obtained by the attacker. This account had long been inactive but still retained full high-level permissions.
After gaining control of this account, the attacker directly called the contract's minting function, minting around 5 billion GALA tokens and transferring them to a personal address. Subsequently, the attacker gradually exchanged these tokens on the market for ETH, cashing out.
No smart contract vulnerabilities were exploited throughout the process; instead, malicious operations were executed directly through legitimate permissions.
Reason for Theft:
The essence of this attack lies in Mixin storing the private key in a centrally managed cloud database.
Mixin Network claims to be maintained by 35 mainnet nodes, supporting cross-chain transfers for 48 public chains. However, its hot wallet and the private keys of numerous deposit addresses are stored in a "recoverable manner" on a third-party cloud service provider's database. In the early hours of September 23, 2023, an attacker breached this database and extracted these private keys in bulk.
Upon obtaining the private keys, the attacker did not need to crack any contract logic but directly initiated transfers with a legitimate signature. On-chain records show that the attacker sequentially emptied addresses in descending order of balance, involving over 10,000 transactions over several hours. The primary assets involved approximately $95.3 million in ETH, $23.7 million in BTC, and $23.6 million in USDT, with the USDT promptly exchanged for DAI to circumvent freezing.
Reason for Theft:
The core of this attack lies in the protocol's internal asset and liability calculation logic inconsistency, which was magnified by a flash loan.
Specifically, Euler's DonateToReserve function, when executed, only burned the eToken representing the collateral asset without synchronously burning the dToken representing the debt, breaking the system's correspondence between "collateral" and "liabilities."
In this scenario, the protocol mistakenly perceived a reduction in collateral assets and a change in debt structure, leading to an abnormal asset state.
The attacker constructed a complete set of operations around this:
They first borrowed a significant amount of funds through a flash loan, carried out deposit and borrowing actions within the protocol, and continuously adjusted the quantity relationship between eToken and dToken. Exploiting the aforementioned logic flaw, they caused the system to continuously generate incorrect asset/liability states, thus obtaining a borrowing capacity exceeding the actual collateral capability.
After gaining abnormally amplified borrowing power, the attacker then withdrew funds in batches and completed transfers using multiple assets (DAI, USDC, stETH, wBTC). The entire process was completed in a single transaction, magnifying profits through multiple operations, ultimately resulting in a loss of approximately $197 million.
Theft Reason:
The core of this incident was a flaw in the Token Gateway's proof verification logic.
The attacker exploited a lack of input validation in the MMR (Merkle Mountain Range) proof verification, forging a cross-chain proof that should have been rejected. Due to a system error that incorrectly treated this invalid proof as valid, the attacker gained control of the Ethereum bridge DOT contract, minted approximately 1 billion fake bridged DOT, and dumped them on a DEX.
Furthermore, the attack impacted DOT pools on Ethereum, Binance Smart Chain, BNB Chain, and Arbitrum. The initial estimated loss of around $237,000 was later revised to approximately $2.5 million.
Theft Reason:
The core of this attack was the bypass of the supply cap check combined with manipulation of the exchange rate calculation logic.
Specifically, Venus calculated the market funds by directly reading the real balance from the contract using balanceOf(), while the supply cap check was only done in the mint() process.
The attacker bypassed the supply cap check by directly transferring underlying assets (ERC-20 transfer) to the vToken contract, circumventing the mint() and evading supply cap validation.
As these funds were included in the contract balance, the system calculated an increase in pool assets for the exchange rate, even though the corresponding vToken balance did not increase, leading to an artificially inflated exchange rate.
In this scenario, the attacker's original collateral value was amplified, granting them significantly more borrowing power than they actually had.
Subsequently, the attacker leveraged this inflated collateral value to iteratively borrow, drive up prices, and borrow again in a loop, extracting various assets from the protocol and resulting in approximately $5 million in losses.
Reason for the Theft:
The core of this attack was the compromise of a critical signing key and the lack of an upper limit check on minting in the on-chain contract.
The USR minting process in Resolv relies on an off-chain service: users submit a request, which is then signed by a system holding a privileged key (SERVICE_ROLE) and ultimately minted by the contract.
However, the contract only checks for "validity of the signature" and does not verify the "reasonableness of the minted amount," nor does it have a collateral ratio, a price oracle, or a maximum minting limit.
The attacker breached the project's cloud infrastructure, obtained this signing key, and was able to generate legitimate signatures.
With signing authority, the attacker used a small amount of USDC (around $100,000–200,000) as input, forged parameters, and directly minted about 80 million USRs without collateral backing.
Subsequently, these uncollateralized USRs were swiftly exchanged for other stablecoins and eventually converted to ETH. The funds were gradually withdrawn, while a significant increase in the token supply caused the USR price to rapidly deviate from its peg.
Reason for the Theft:
The core of this attack was a flaw in the EVM precompile bridge's validation logic.
SagaEVM utilized an EVM implementation based on Ethermint, and this code contained an undiscovered vulnerability that affected the transaction validation logic of the cross-chain bridge.
By crafting specific transactions, the attacker bypassed the bridge's checks on "whether the collateral asset has been deposited" and "the stablecoin's supply limit."
In the absence of the checks being bypassed, the system treated these forged messages as legitimate cross-chain operations and proceeded to mint the corresponding amount of stablecoins. With no real collateral backing, the attacker could mint a significant amount of stablecoins at no cost and exchange them for real assets in the protocol.
Ultimately, the protocol funds were continuously drained, the stablecoin deviated from its peg, and about $7 million in assets were transferred out.
Theft Reason:
The core of this attack was due to a double-spend vulnerability in the BRO Vault contract (triggered by reentrancy).
Specifically, when the contract received ERC-3525 assets, it called doSafeTransferIn, and since ERC-3525 is based on ERC-721, the onERC721Received callback was triggered during the secure transfer process.
In this process, the contract minted once in the main flow and then triggered another minting operation in the callback function.
As the callback occurred before the first mint had completed, the attacker was able to trigger two mints in one deposit operation, creating a typical reentrancy path. By exploiting this vulnerability repeatedly, the attacker inflated a small amount of assets into a large amount of BRO, exchanged it for SolvBTC, and transferred out.
Theft Reason:
The direct vulnerability in this incident was not within Aave but rather arose from the failure of Kelp DAO's cross-chain bridge verification mechanism.
The attacker sent a forged message to the LayerZero-based cross-chain bridge, causing the system to erroneously release and mint about 116,500 rsETH without any actual ETH deposit. These rsETH had no real asset backing but were treated as valid collateral in the system.
Subsequently, the attacker deposited this unsecured rsETH into Aave as collateral and borrowed a significant amount of real assets (WETH). Due to Aave's parameter configuration allowing for large-scale collateralization and borrowing, the attacker swiftly borrowed and withdrew the funds.
The end result: The attacker, through the process of "faking collateral assets → borrowing real assets," shifted the risk to Aave, leading to a significant bad debt scenario.
Reason for Theft:
The core of this exploit lies in the fact that the oracle price can be manipulated in a single transaction (low liquidity + VWAP mechanism).
Prior to the attack, the USTRY/USDC trading pair had virtually no liquidity and no normal trading within the oracle price window. The Reflector oracle used by YieldBlox is based on VWAP (Volume-Weighted Average Price), where in this scenario, a single transaction can determine the price.
The attacker first placed an extreme price (around 500 USDC per USTRY) and then used another account to execute a trade with a minimal volume (only about 0.05 USTRY), successfully pushing the oracle price to around $106.
Once the price was manipulated, the attacker's USTRY holdings were treated by the system as high-value collateral, allowing them to receive a loan far exceeding the actual value. Subsequently, the attacker borrowed all assets from the pool (XLM and USDC) and proceeded with fund withdrawal.
Reason for Theft:
The core of this attack was the compromise of a key team member's device, leading to a breach of private keys or signature processes.
By infiltrating a team executive's device, the attacker gained access to the project's control wallet. This access may have involved directly obtaining the private keys or disrupting transaction signing processes through malware to have team members unwittingly approve malicious transactions.
After gaining control, the attacker performed actions on multiple Solana wallets controlled by the project, including unstaking assets and transferring funds. No smart contract vulnerability was exploited throughout the process; instead, the attack leveraged the acquired wallet permissions to facilitate fund transfers.
Ultimately, a significant amount of project funds were siphoned off, resulting in approximately $30-40 million in losses and a substantial drop in token price.
Incident Cause:
The core of this attack lies in an integer overflow vulnerability in the TRU purchase pricing function.
During the price calculation in buyTRU(), involving multiple large number multiplications and additions, the contract is using Solidity version 0.6.10, which does not have overflow checks enabled by default.
When the attacker submits a specific large parameter, an overflow occurs in the intermediate calculations, causing the value to wrap around and resulting in an abnormally low final purchase price, possibly even 0.
In this scenario, the attacker can buy a large amount of TRU at a very low or even zero cost.
Meanwhile, the protocol's selling logic (sellTRU()) still calculates based on normal rules, allowing for proportional exchange of the ETH reserve in the contract.
The Attacker's Subsequent Actions:
Low/zero-cost purchase of TRU → Selling at normal price → Withdrawing ETH
Through multiple rounds of operations, continuously draining funds from the protocol, ultimately resulting in approximately $26 million in losses.
Incident Cause:
The core of this attack lies in relying on external Curve pool data for AUM/sharePrice calculations, lacking validation, and being vulnerable to flash loan manipulation.
The attacker leveraged flash loans to borrow a large sum, temporarily injected liquidity into multiple Curve pools, and conducted trades to artificially alter the pool's state and related calculation results (such as LP value, withdraw calculations, etc.).
These manipulated data were directly used by the protocol for AUM (Assets Under Management) calculation, further impacting the sharePrice.
Due to the lack of effective validation of external data or timestamping, the system treated this anomalous data as authentic, leading to:
· Significant inflation of AUM
· Abnormally amplified sharePrice
After the sharePrice was artificially raised, the attacker exploited the price difference to conduct arbitrage, swapping out assets in the DUSD/USDC pool to make a profit.
From these 20 incidents, we can see a clear trend: there are ultimately only two paths through which hackers steal substantial assets: technical vulnerabilities and social engineering.
1. Technical Vulnerabilities: A clear migration path can be seen in the timeline of technical vulnerability cases.
Early technical vulnerabilities were highly concentrated in cross-chain bridges. During that period, cross-chain bridges were the infrastructure where DeFi expanded most rapidly, with the newest code and weakest audits. They held a large amount of assets but had not undergone a sufficiently adversarial validation.
Subsequently, the industry began to focus on the security of cross-chain bridges, and verification mechanisms were generally strengthened, leading to a significant reduction in large-scale cross-chain bridge technical vulnerabilities. However, the vulnerabilities did not disappear; they simply moved to different areas—shifting to the mathematical logic within DeFi protocols, oracle designs, and dependencies on third-party libraries.
· Cetus: Boundary condition error in the math library,
· Truebit: Integer overflow in an old compiler,
· YieldBlox: Overreliance of oracles on low liquidity markets.
At the core of this is only one fact: the attack surface always follows the assets, the novelty of the code, and the blind spots in audits. A certain type of infrastructure is intensively attacked, the industry begins to pay attention, defenses are strengthened, and then attackers move to the next area of fastest growth and weakest defense.
2. Social Engineering: Among these 20 theft cases, 4 have been confirmed to be linked to or highly attributed to the North Korean state hacker group—Ronin, WazirX, Bybit, Drift—resulting in a total loss of over $2.5 billion.
According to Chainalysis data, North Korean-affiliated hacker groups stole over $2 billion in cryptocurrency assets in 2025 alone, accounting for nearly 60% of the global cryptocurrency theft that year. Compared to 2024, North Korean hacker attacks decreased by 74%, but the average amount per attack increased significantly.
The tactics of North Korean hackers continue to evolve, from direct system intrusions during the Ronin era, to supply chain attacks on Bybit, and then to six months of offline penetration in Drift, each time finding new ways beyond existing defenses.
What is even more alarming is that North Korean hackers have been actively infiltrating the global crypto industry by posing as developers. Once inside the target company, these individuals familiarize themselves with the internal system architecture, gain access to the codebase, and stealthily implant backdoors in the production code.
The scope of the breaches is expanding: In early incidents, the impact was mostly limited to the protocol itself. However, with the increasing composability of DeFi, the impact of a single breach is now spreading externally.
· Drift: Following the breach, at least 20 protocols relying on its liquidity or strategies experienced interruptions, pauses, or direct losses. Carrot Protocol was the most significantly affected with a 50% TVL impact.
· Aave: The Aave contract itself was completely secure. The only issue arose from accepting rsETH from Kelp DAO as collateral, which led to Aave inheriting the bad debt risk due to a failure in an external bridge validation.
Ultimately, these patterns all point to one reality: Depositing assets into a protocol involves trusting not only the code of that protocol but also every external asset it relies on, every third-party service, and the judgment and operational security of the few individuals with administrative permissions.
Recently, there has been a continuous stream of theft-related news. Just this month, Polymarket launched a prediction market asking, "Will there be any crypto projects hacked for over 100 million this year?" However, before a month had passed, the market had already been settled. This is not a coincidence. As the asset size of DeFi grows and inter-protocol dependencies deepen, the ability to safeguard funds has not kept pace with this growth.
The pressure to enhance security has not relented, yet the dimensions of threats continue to expand. In April 26, Anthropic's Claude Mythos Preview revealed thousands of high-risk vulnerabilities in every mainstream operating system and browser during testing, with the ability to convert 72% of known vulnerabilities into exploitable attack paths.
Once this capability is systematically applied to scan smart contracts, vulnerabilities in the DeFi industry will be discovered and exploited at an unprecedented rate. Simultaneously, project teams can proactively use this tool for self-assessment, identify and rectify potential risks in advance, and further enhance their security defenses.
1. Avoid concentrating assets in a single protocol. While diversification does not eliminate risk entirely, it helps control the upper limit of a single loss.
2. Maintain Distance from New Protocols. Most technical vulnerabilities are discovered in the early days after the protocol launch. A protocol that has been running for two years, undergone multiple audits, and real stress tests is much more secure than a protocol that offers high yields right after launch.
3. Whether the Protocol is Truly Profitable. A protocol that can truly make money has actual compensation ability when losses occur. Protocols that rely on token incentives to operate and do not have real income themselves often can only offer compensation solutions such as issuing new tokens or empty promises when things go wrong.
A truly mature financial infrastructure will not always prioritize security after growth metrics. Until that day comes, news of hacks will not cease.
Original Article Link
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia