2025 was another intense year for crypto security. A series of high-impact incidents shook the ecosystem and left real damage in their wake, affecting users, teams, and communities across the space. While the outcomes were often painful, each event also reinforces a familiar truth: security must be treated as a first-class priority.
To help the community learn from what happened, BlockSec selected ten incidents that stood out most this year. These cases were chosen not only for the scale of loss, but also for the distinct techniques involved, the unexpected twists in execution, and the new or underexplored attack surfaces they revealed.
In this post, we spotlight the top ten security incidents of 2025 and share why each one deserves attention. We will also publish a dedicated follow-up for every case, breaking down the root cause and the full attack path in detail.
Cetus Incident: The Largest DeFi Hack of 2025
Summary
On May 22, 2025, Cetus Protocol, the largest concentrated-liquidity DEX on Sui, was exploited for an estimated ~$223M as liquidity was drained from multiple pools. The root cause was a faulty overflow-prevention helper (checked_shlw()) in fixed-point u256 math: an incorrect threshold allowed an unsafe << 64 left shift to proceed, silently truncating high bits. By carefully choosing liquidity size and tight tick ranges, the attacker made Cetus compute the required token deposit as ~1 unit while crediting an LP position with enormous liquidity, then removed that inflated position to withdraw real reserves.
Reason for Selection
A single incorrect comparison in a fixed-point helper was enough to drain $223M. The attacker did not manipulate oracles or exploit governance: the entire attack relied on pure arithmetic edge cases (shift + truncation) to create near-free liquidity and withdraw real reserves deterministically. For any protocol built on concentrated-liquidity math, this case is a direct warning that silent boundary errors in low-level fixed-point operations can scale to protocol-level catastrophe.
Learn about the root cause and the attack steps in detail.
Bybit: The Largest Hack of 2025
Summary
On February 21, 2025, Bybit lost approximately $1.5 billion after an attacker compromised a Safe{Wallet} developer's machine through social engineering. With that access, the attacker injected malicious JavaScript into Safe{Wallet}'s AWS S3 bucket. The injected code specifically targeted Bybit's Safe{Wallet} transactions, tampering with transaction content during the signing process. The tampered transaction upgraded Bybit's Safe{Wallet} contract to a malicious implementation, allowing the attacker to drain all assets held by the contract.
Reason for Selection
The largest security breach in crypto history did not start with a smart contract bug. It started with a compromised developer machine and a tampered JavaScript file in an S3 bucket. The attack path ran entirely through Web2 infrastructure: social engineering, cloud storage, and front-end code injection. For an industry focused on on-chain security, Bybit is a direct reminder that operational and infrastructure security are equally essential. A multisig is only as safe as the signing interface its owners trust.
Learn about the root cause and the attack steps in detail.
Balancer V2
Summary
On November 3, 2025, Balancer V2's Composable Stable Pools and several forked projects across multiple chains were exploited in a coordinated attack, resulting in total losses exceeding $125 million. The root cause was precision loss in the invariant calculation, which distorted BPT (Balancer Pool Token) pricing. The attacker exploited this distortion to extract profit from targeted stable pools through single batch swaps.
Reason for Selection
Unlike typical oracle manipulation attacks, this exploit originated inside the invariant computation itself: a minor precision loss in fixed-point math was enough to distort BPT pricing and enable profitable single-transaction extraction. The attack propagated across multiple chains and affected both Balancer and its forks, illustrating how shared codebases amplify systemic risk in composable DeFi. Community discussion of the root cause often oversimplified the mechanics. The full analysis traces how precision loss in the invariant solver translates into exploitable pricing gaps.
Learn about the root cause and the attack steps in detail.
GMX
Summary
On July 9, 2025, GMX V1 on Arbitrum was exploited for approximately $42 million. The attacker triggered a reentrancy vulnerability to manipulate the GLP price mid-transaction, then used the distorted price to acquire assets far exceeding the value deposited. Through repeated exploitation, the attacker gradually drained underlying assets from GMX V1's liquidity pools.
Reason for Selection
Reentrancy is one of the oldest known smart contract vulnerabilities, yet it took down a battle-tested protocol with an established ACL model. The nonReentrant modifier on the OrderBook contract prevented same-contract reentrancy but did nothing to stop cross-contract calls into the Vault during the fallback. GMX V1 had been live for years, a track record that can create a false sense of security. This case shows that protocol maturity is not a substitute for system-wide reentrancy analysis, and that single-contract guards are insufficient when multiple contracts share mutable state.
Learn about the root cause and the attack steps in detail.
Yearn Finance
Summary
On November 30, 2025, Yearn Finance's yETH Weighted Stable Pool was exploited for over $9 million. The primary root cause was unsafe arithmetic in the invariant solver _calc_supply(), whose rounding-down and underflow failures independently accounted for ~$8.1M (90% of losses). A secondary vulnerability, a non-disabled bootstrap path in add_liquidity(), enabled an additional ~$0.9M after the primary exploit had already drained the pool.
The attacker executed a multi-phase strategy: first, they repeatedly added and removed liquidity to create an extreme imbalance in the pool's virtual balances; next, they exploited the arithmetic failures to collapse the product term and drain total supply to zero; finally, they re-entered the bootstrap initialization path to mint ~2.35e56 yETH via underflow and swapped it for real assets in the yETH-WETH Curve pool.
Reason for Selection
The financial loss was moderate by 2025 standards, but the technical complexity of the exploit is exceptional. The attack chains numerical edge cases (division collapse, sign flips in the invariant solver) with state-machine re-entry (re-triggering pool initialization after deployment), requiring precise multi-phase manipulation of on-chain state. Fully reconstructing the exploit demands understanding both the low-level arithmetic and the broader state transitions. The combination of subtlety, rigor, and educational depth in this case makes it one of the most analytically rewarding incidents of the year.
Learn about the root cause and the attack steps in detail.
Cork Protocol
Summary
On May 28, 2025, the Cork Protocol on Ethereum was exploited, resulting in approximately $12 million in losses. The root cause was a combination of expiration-time HIYA price manipulation and missing access control in a Uniswap v4 hook callback. Because HIYA risk premiums increase exponentially as time to maturity approaches zero, late-stage swaps inflated HIYA and caused newly initialized markets to severely underprice Cover Tokens. At the same time, CorkHook.beforeSwap lacked msg.sender authentication, allowing arbitrary calls with crafted parameters. By exploiting both flaws, the attacker extracted large amounts of CT and DS and converted them back into wstETH, draining protocol reserves.
Reason for Selection
Neither the expiration-time pricing curve nor the unauthenticated hook callback was individually catastrophic. Their interaction was. The exponential HIYA premium near maturity created an economic amplifier, and the missing msg.sender check in CorkHook.beforeSwap gave the attacker a way to trigger it with arbitrary parameters. This case illustrates a class of vulnerabilities that single-module audits are likely to miss: cross-module assumption mismatches where economic design and access control interact to produce an exploitable path.
Learn about the root cause and the attack steps in detail.
Trust Wallet
Summary
On December 25, 2025, Trust Wallet suffered a supply chain attack that compromised over 2,000 user wallets, resulting in $8.5 million in losses. The attacker obtained Trust Wallet's Chrome Web Store API key and used it to publish a backdoored extension (v2.68) through official channels. The malicious extension exfiltrated user seed phrases to an attacker-controlled server. The attacker then drained funds from the compromised wallets.
Reason for Selection
The attacker never touched a smart contract. By compromising a single API key, they published a malicious extension through Trust Wallet's official distribution channel, bypassing both manual review and the standard release process. Users had no reason to distrust the update. This is the only wallet supply chain attack in the Top 10, and it exposes a category of risk that on-chain audits cannot cover: the security of the software delivery pipeline between the developer and the end user.
Learn about the root cause and the attack steps in detail.
Bunni
Summary
On September 2, 2025, Bunni V2 was exploited for $8.4 million across the USDC/USDT pool on Ethereum and the weETH/ETH pool on Unichain. The protocol later declared bankruptcy on October 23, 2025. The root cause was a rounding error in the update of idle pool balances during liquidity removal, which caused the contract to undervalue its own total liquidity.
The attacker executed a three-stage attack: first, manipulating the pool price to deplete USDC's available balance and amplify the rounding error; next, executing a series of small withdrawals that accumulated the liquidity underestimation; finally, performing directional swaps to arbitrage the gap between the protocol's recorded liquidity and its actual reserves.
Reason for Selection
Bunni V2 had undergone multiple code audits, yet a minor rounding error in idle balance accounting went undetected. The error alone was negligible per transaction, but the attacker amplified it through repeated small withdrawals after deliberately skewing pool state, turning a fractional precision loss into an $8.4M drain. The case demonstrates how rounding errors that appear safe in isolation can become exploitable when an attacker controls the sequence and conditions under which they accumulate.
Learn about the root cause and the attack steps in detail.
1inch
Summary
On March 5, 2025, a third-party resolver integrated with 1inch Fusion V1 was exploited for over $5M due to unsafe calldata reconstruction in _settleOrder(). An attacker-controlled interactionLength corrupted the in-memory assembly of the dynamic suffix used to propagate resolver identity and execution context, allowing forged settlement data to be injected. Because resolver contracts implicitly trusted calldata forwarded by the Settlement contract based solely on msg.sender, the forged context passed all access control checks and led to unauthorized asset extraction.
Reason for Selection
This exploit blurs the boundary between smart contract vulnerabilities and traditional binary exploitation. Rather than abusing economic assumptions or high-level business logic, the attack relies on pointer arithmetic, unchecked length fields, and ABI memory layout assumptions, patterns more commonly seen in native software exploits such as buffer overflows and pointer underflows. It shows how low-level calldata and memory manipulation can reintroduce classic exploitation primitives into on-chain systems, especially when combined with implicit trust chains between contracts.
Learn about the root cause and the attack steps in detail.
Panoptic
Summary
On August 25, 2025, with the assistance of Cantina and Seal911, Panoptic conducted a whitehat rescue operation securing approximately $400K in at-risk funds. The root cause was a flaw in the contract's construction of s_positionsHash: the use of XOR to aggregate Keccak256 hash results. While a single hash function remains collision-resistant, the mathematical linearity of XOR renders the overall fingerprint (the XOR sum of hashes) insecure, allowing distinct position sets to produce identical hashes.
Reason for Selection
Most incidents in this list trace back to arithmetic bugs or missing access control. Panoptic's vulnerability is different: it is a cryptographic design flaw at the data structure level. The protocol relied on XOR to compose position fingerprints, assuming the result would inherit the collision resistance of the underlying Keccak256 hashes. It does not. XOR's linearity means an attacker can construct distinct position sets that produce identical s_positionsHash values, bypassing accounting invariants. The successful whitehat rescue prevented loss, but the underlying flaw is a useful reminder that hash composition requires the same care as the hash function itself.
Learn about the root cause and the attack steps in detail.
