Top 10 Smart Contract Attack Vectors of H1 2025, Ranked by Risk

Smart contracts get drained more than ten ways — reentrancy, front-running, governance takeovers, and signature replay all have entire audit checklists of their own, and none of them happen to top this particular ranking. What follows isn't an attempt at an exhaustive taxonomy. It's the ten highest-risk categories from a six-month window, ranked by a score that weighs both total value lost and how often each one actually fired — which makes it a much better map of where real money is currently being lost than a "biggest hacks ever" leaderboard would be.

Most "top crypto hacks" lists are just a leaderboard sorted by dollar amount. That's useful for headlines and useless for auditors, because a $260 million loss and a $260,000 loss can come from the exact same root cause, and the leaderboard tells you nothing about which mistake you're actually likely to make in your own codebase.

BlockThreat's breakdown of DeFi attack vectors for the first half of 2025 is more useful precisely because it sorts by mechanism instead of by size — ranked by a composite risk score that weighs both total value lost and how often each vector actually fired. Ten categories, together accounting for roughly $494 million in losses across 133 recorded incidents in six months. What follows is a walk through all ten, in the order the data ranks them, with real incidents attached to each one where the public forensics are solid enough to name names.

1. Stolen private keys — $94,000,000 across 15 incidents

This is the category every audit misses, because it isn't a smart contract bug at all. The code can be flawless and the protocol still loses everything if whoever holds the deployer key, the multisig signer key, or the admin key gets compromised off-chain.

April 2025 gave two clean examples. UPCX, a crypto payment platform, lost an estimated $70 million after attackers used a compromised private key to push a malicious update to the project's smart contract — the contract logic itself wasn't broken, the key that was allowed to change it was stolen. In the same month, ZKsync lost roughly $5 million when a compromised administrator account was used to mint tokens that had gone unclaimed from an old airdrop, exploiting privileged functions the admin account had access to. Both incidents ended the same way audits can't prevent: someone with legitimate credentials did something illegitimate, because the credentials themselves were no longer under legitimate control.

The fix isn't a Slither rule. It's operational — hardware signing, multi-party computation for key custody, time-locked admin actions, and treating "who can call this privileged function" as seriously as "what does this function do."

2. Reward manipulation — $19,000,000 across 26 incidents

This is the highest-frequency category on the list, and it's also the vaguest-sounding one, which is exactly why it's dangerous. It covers any exploit where an attacker games the accounting that determines how much a user is owed — staking rewards, liquidity mining emissions, rebasing calculations, or rollover pricing in structured products — without necessarily touching a price oracle or a permission check.

Cork Protocol's incident in 2025 is a good illustration of the family, even though its post-mortem groups it with configuration and access-control issues too: a rollover pricing manipulation combined with missing access control on a Uniswap v4 hook let an attacker distort how much value a position was entitled to during a rollover event. The pattern generalizes: any function that computes "how much does this user get" based on internal protocol state, rather than an external, hard-to-manipulate reference, is a reward-manipulation candidate. The fix is treating internal accounting variables with the same suspicion you'd apply to an external oracle — because from the attacker's perspective, they're the same attack surface.

3. Price oracle manipulation — $14,000,000 across 28 incidents

Second-highest incident count on the list, and the one every smart contract security course already teaches — which makes its persistence a genuine indictment of how hard it is to actually fix in practice. The pattern is old: borrow a large sum via flash loan, execute a large trade against a thin-liquidity pool, watch the pool's spot price move, and get a lending or derivatives protocol to price collateral against that momentarily-distorted number.

Two 2025 incidents show the pattern hasn't gone away even at protocols built after everyone supposedly learned this lesson. Loopscale, a Solana lending protocol, lost about $5.8 million in April 2025 because it accepted an oracle account passed in by the user without verifying that account actually matched the oracle registered for that collateral type — the attacker simply supplied their own price feed. Resupply, which manages the synthetic reUSD token, suffered a similar exploit in June 2025: collateral prices were pulled from a DEX-connected pool without independent verification, so a flash loan, a large trade, and a price pump were enough to borrow against artificially inflated collateral.

The lesson from both: "we use an oracle" is not a security property. Which oracle, whether it's TWAP-smoothed, whether the calling contract can be spoofed into using a different one — those are the actual questions.

4. Insufficient function access controls — $14,000,000 across 26 incidents

Tied with oracle manipulation on dollar losses, and just as common. This is the category of "a function that should have required onlyOwner, or a specific role check, didn't — or checked the wrong thing."

KiloEx's April 2025 exploit is a textbook case that actually chains two vulnerability classes together: the attacker found a way to call a sequence of functions that ended in setting a token's price directly — a function that should have been gated to a privileged oracle role, wasn't properly restricted, and let the attacker set an artificially low price, open a large long position, then push the price back up to cash out for roughly $7.5 million. It's worth sitting with that one, because it's the cleanest possible demonstration that "access control" and "oracle manipulation" aren't actually separate bug classes in practice — a missing permission check is often how an oracle gets manipulated in the first place.

5. Malicious insider — $52,700,000 across 6 incidents

The smallest incident count on the list and the second-largest total loss, which tells you something on its own: insider incidents are rare but severe, because an insider already has the access an external attacker spends weeks trying to obtain.

This is also the category where public, verified attribution is genuinely hard to come by — most protocols and investigators are reluctant to publicly confirm insider involvement while legal action is pending, and "malicious insider" versus "compromised insider credentials" (category 1) can look identical from the outside for months. What's worth taking from the aggregate number rather than a single named case: this category is a reminder that a security model built entirely around external threat actors — audits, bug bounties, monitoring for anomalous external wallets — has a blind spot exactly the size of your own team's privileged access. Deployer keys, upgrade authority, and treasury multisigs held by employees deserve the same scrutiny you'd apply to a stranger asking for the same permissions.

6. Integer overflow — $260,000,000 in a single incident (Cetus)

One incident, and it's the largest loss on the entire list — larger than the next three categories combined. Cetus, the largest DEX on Sui, lost approximately $223 million (reported by different sources anywhere from $220M to $230M depending on what's counted as recovered) on May 22, 2025, in one of the cleanest and most technically interesting exploits of the year.

The bug lived in a shared math library, not in Cetus's own business logic. A function called checked_shlw, used to verify that a value could be safely bit-shifted without overflowing, compared the input against the wrong threshold — checking against 0xFFFFFFFFFFFFFFFF << 192 instead of the mathematically correct 0x1 << 192. That gap let an attacker choose a liquidity value that passed the overflow check but still overflowed during the actual liquidity calculation. The overflow corrupted the math so badly that the protocol calculated the attacker needed to deposit just one token unit to open an enormous liquidity position — a position that had already passed multiple professional audits, including one completed just a month before the exploit.

The attacker opened a narrow-range concentrated liquidity position, deposited the trivial required amount, and withdrew real reserves against the phantom liquidity credit, draining the pool in under fifteen minutes. Sui's validators froze roughly $162 million on-chain before it could be bridged out; about $60 million had already moved to Ethereum. Cetus relaunched using recovered funds, its own treasury, and a loan from the Sui Foundation.

The audit lesson here is uncomfortable: three separate security firms reviewed code that touched this library and none caught it, because the bug lived in shared, "already trusted" infrastructure rather than the protocol's own novel logic. Auditing your own contracts isn't enough if you're not also auditing — or at minimum, fuzzing — every math library you import.

7. Function parameter validation — $14,000,000 across 10 incidents

The sibling category to access control: the function is correctly restricted to the right caller, but doesn't validate that the parameters it was called with are sane. Think: a swap function that trusts a caller-supplied minimum-output value without checking it's non-zero, or a fee calculation that doesn't bound a caller-supplied multiplier.

A representative small-scale case from April 2025: Impermax, on Base, lost between roughly $152,000 and $300,000 after an attacker used a flash loan to interact with Uniswap V3 pools in a way that manipulated fee calculations and LP position accounting. The protocol's logic miscalculated accrued fee income in a way that let the attacker trigger a favorable collateral revaluation. It's a smaller number than most of the incidents in this piece, which is itself informative — this category skews toward frequent, moderate losses rather than single catastrophic events, because parameter-validation gaps tend to get caught before they scale to the size of a Cetus or a Bybit, but there are a lot of them.

8. Rounding error — $10,000,000 across 4 incidents

Four incidents, low count, meaningful losses per incident — rounding bugs tend to require real sophistication to find and exploit, which keeps the incident count low but the payout high when someone does.

The clearest illustration of this category's mechanics comes from just outside the chart's window: Balancer V2's November 2025 exploit, which is worth including here despite the date because it's the sharpest public example of the pattern. Attackers targeted arithmetic precision loss inside ComposableStablePool's invariant calculations, executing dozens of tiny "micro-swaps" inside a single batched transaction, each one shaving a negligible rounding error off the pool's calculated price. Compounded across enough repetitions in one transaction, those negligible errors became a roughly $128 million extraction across multiple chains in under thirty minutes. The same mechanism — small individually-irrelevant rounding losses that compound catastrophically when an attacker can repeat them hundreds of times atomically — is exactly what the H1 2025 rounding-error incidents in this category represent at smaller scale.

The takeaway for anyone auditing fixed-point math: "the rounding error is negligible" is only true if the attacker can't call your function nine hundred times in one transaction. Bound the repetition, not just the individual error.

9. Logic error — $1,500,000 across 9 incidents

The catch-all category, and by dollar amount, the smallest total loss with a meaningful incident count — which suggests these bugs get caught relatively early, before they scale. This is the category for bugs that don't fit oracle manipulation, access control, or parameter validation neatly: an inverted comparison operator, a state variable updated in the wrong order relative to an external call, a fee applied to the wrong side of a trade.

These rarely make headlines precisely because the losses stay contained, but they're the most common thing an auditor will actually find in a real review — not the exotic overflow bug, but a small, boring logic mistake that happens to sit on a path an attacker can reach. It's a useful reminder that most of an audit's value comes from the unglamorous line-by-line logic review, not from hunting for the next Cetus.

10. Supply chain — $4,700,000 across 2 incidents

The smallest category by both metrics here, but arguably the one with the highest ceiling, because it's the one category on this list where the vulnerability doesn't live in the protocol's own code at all — it lives in a dependency, a build tool, a frontend package, or a third-party service the protocol trusts by default.

The category's defining incident of 2025 technically falls outside this DeFi-specific dataset, but it's the reason every security team now takes this category seriously: Bybit's $1.4–1.5 billion loss in February 2025 — the largest crypto theft in history — was a supply chain attack, not a smart contract bug. Attackers, later attributed by the FBI to North Korea's Lazarus-linked TraderTraitor cluster, compromised a developer's machine at Safe{Wallet}, the multisig infrastructure Bybit relied on, and injected malicious JavaScript into Safe's own interface. When Bybit's signers approved what their screen showed as a routine transfer, the compromised UI was actually presenting a transaction that handed control of the cold wallet to the attackers — the signers' keys were never stolen, their judgment was deceived by tampered infrastructure they had no reason to distrust. It's excluded from the DeFi-specific chart because Bybit is a centralized exchange, not a protocol, but the mechanism is identical to what smaller DeFi projects experienced with compromised bridge dependencies and package injections throughout the year.

The audit implication is the least comfortable one on this list: you can review every line of your own contract and still get drained through a dependency you never wrote and don't control. Software bill of materials tracking, subresource integrity on frontend assets, and independent transaction simulation before signing aren't optional extras anymore — they're the only thing that would have caught this.

Ranked by risk rather than by size, the picture that emerges isn't "smart contracts are buggy." It's narrower and more useful than that: nearly $114 million of this six-month total came from something that wasn't a smart contract bug at all — stolen keys, insider access, and supply chain compromise, three categories where the most rigorous Solidity review in the world wouldn't have helped. The rest came from a small number of recurring patterns — unverified oracles, missing access checks, unvalidated parameters, and math that breaks at the edges — that keep reappearing in new protocols because each one gets treated as a novel bug instead of a known category with a known checklist. These ten aren't the only ways a protocol dies. They're the ten that cost the most, most often, in the six months this data covers.

Data source: BlockThreat's H1 2025 DeFi attack vector risk ranking (blockthreat.io). Readers who want hands-on practice with these vulnerability classes can work through minimized, runnable examples at Cyfrin's sc-exploits-minimized repository.