Crypto hacks in 2026 so far: what 77 verified incidents show

Our hack database holds 77 verified incidents since 2022. Each one is written from primary sources (the affected project's own post-mortem, an advisory, a governance post) and linked to them. This post looks at the 13 incidents of 2026 so far: how much was lost, how the attacks worked and what they have in common. Every amount is the one the primary source states; we do not convert token amounts into dollars.

The year in numbers

The 13 incidents of 2026 add up to $1B in stated losses, but only 7 of them state a USD amount at all. The other 6 report their losses in tokens, as a share of a contract's holdings or not at all, and are counted but not summed. The total is therefore a floor, not the full damage.

For context, the years before:

The largest losses

Losses were extremely concentrated. The two largest incidents, Bitget with $388M and Drift Protocol with $295M, make up 67% of all stated losses of the year. Add Kelp DAO with $292M and three incidents explain almost everything; the remaining ten are smaller by an order of magnitude or state no dollar amount.

That concentration is typical of hacks and matters for reading any yearly total: one large incident changes a year's headline number more than any trend in the dozen smaller ones.

Pattern 1: keys and signing infrastructure

Several of the year's incidents did not break a smart contract at all. They broke the keys or the signing arrangement around it.

• At Resolv, attackers gained access to the signing infrastructure of the stablecoin protocol and illicitly minted tokens.¹
• At Humanity Protocol, an attacker used stolen keys to move and mint tokens.²
• At IoTeX ioTube, the attacker compromised the owner account of the bridge's validator contract.³
• At THORChain, a newly joined node operator exploited a flaw in the threshold signature scheme that its vaults rely on.⁴

Our type labels count 2 incidents as key compromises; read more broadly, control over keys and signers was at the centre of at least four. For a protocol, the contract audit is only one layer; who can sign, mint or upgrade is another.

Pattern 2: bridges

4 of the 13 incidents were bridge exploits. They failed in different ways: a forged cross-chain message at Kelp DAO, a compromised owner account at ioTube, a mismatch between two systems' views of the same transfer at Syscoin, and at Verus an exploit whose fix makes the Ethereum contract prove that each import is a validated export from Verus.⁵

Bridges hold large pools of locked assets and depend on two systems agreeing on what happened. That makes them a recurring target: our database also lists bridge exploits in 2022, 2023 and 2025.

Pattern 3: bugs below the application

A third group of incidents came from software that sits underneath the application, in parts that most users never see:

• At Saga, a vulnerability in a precompile of the Cosmos EVM stack let the same balance be reused within one transaction.⁶
• At the Liquid Network, a consensus bug in the software behind the sidechain allowed unbacked tokens to be created.⁷
• At GalaChain, a flaw in signature verification allowed unauthorized transfers from several wallets.⁸
• At Coldcard, a firmware bug in affected releases had weakened the seeds that hardware wallets generated; the devices themselves were not hacked.⁹

And the largest incident of the year up to this snapshot, at Bitget, was enabled by the compromise of third-party security products that gave access to the exchange's wallet environment, according to the exchange's summary of the investigations.¹⁰

Chains and venues

By chain, 5 incidents involved Ethereum, 2 involved Bitcoin or a Bitcoin sidechain, and 8 involved chains outside our main list: application chains, sidechains and bridges' own networks. Attacks followed the assets, not a particular technology: the same patterns appeared on very different stacks.

Centralised venues were not spared either, and a single exchange incident can outweigh a year of smaller hacks: Bitget alone accounts for $388M of the year's stated losses.

How we verify an incident

Every entry in the database goes through the same steps before it is published:

• Primary sources only. Facts come from the affected project's own statements (post-mortems, security notices, advisories, governance posts, release notes) or from on-chain transactions. News coverage is linked as coverage, never used as the source of a fact.
• Our own words. The summary on each incident page is written by us and repeats only what the sources state. We do not attribute fault beyond them, and we do not use words like "rug" or "scam" without evidence.
• Amounts as stated. A loss stated in tokens stays in tokens. Converting it at today's price would put a number on the page that no source ever published.
• Checked links. Each primary source carries the day its link was last checked, and an amount that a later update revises is revised on the page too.

The full method is on our incident methodology page. Without a primary source that can still be reached, an incident does not go in, which is why some well-known incidents are missing.

What the incidents have in common

Reading the 13 post-mortems side by side, a few points repeat:

1. Most losses came from outside the main contract logic: keys, signers, bridges, firmware and base-layer software.
2. Recovery is partial and slow. Several projects report funds frozen, returned or covered by a fund, but often only for part of the loss and months later. Our incident pages show the recovery status the sources state.
3. Numbers change. Initial amounts are often revised in later updates. We keep the source of each stated amount and the day it was last checked.

For anyone holding assets on-chain or on a venue, the practical takeaway is to know where the keys are, which bridges an asset depends on, and how a venue reports incidents. The Latest tab of our Security section lists new incidents as they are verified, next to stablecoin prices.

The numbers in this post are frozen at the snapshot time shown on each block; incidents verified after it are not counted here. The hack database is updated as new incidents are verified.