One bug, millions lost: How smart contract hacks work
Smart contracts were designed to remove the middleman. Once deployed, they can execute transactions automatically according to predefined rules, without anyone manually approving each step. But that same automation creates a problem: code is only as secure as the assumptions built into it.
And hackers don't always need to break the blockchain itself. In August 2026, an attacker drained nearly 200,000 XRP from the Coreum–XRP Ledger bridge by exploiting a flaw in how the bridge verified deposits. No private keys were stolen and the XRP Ledger itself was not compromised — the bridge simply accepted deposits that had never actually reached its reserve.
This goes to show how broad the attack surface has become. In the first half of 2026, TRM Labs counted a record 207 crypto hacks, while total losses fell to about $972 million. Smart-contract exploits accounted for most incidents, but infrastructure and operational compromises — including stolen keys and privileged-access breaches — still caused roughly 76% of the money lost.
Here's how these attacks actually work — the most common ways hackers turn a flaw in crypto infrastructure into real money.
TL;DR
- Smart contracts are automated — and that makes bugs dangerous. A single coding or logic error can let attackers bypass intended rules and drain funds.
- Reentrancy, oracle manipulation, flash loans, bridge exploits, and access-control failures are among the major attack vectors.
- Not every hack involves stolen private keys. The August 2026 Coreum–XRP Ledger bridge exploit relied on a deposit-verification flaw that allowed the attacker to trigger legitimate withdrawals against fake deposits.
- Hackers range from solo exploiters to sophisticated criminal groups. North Korea-linked actors have been behind some of the year's largest crypto thefts.
- Smart-contract exploits are becoming more frequent but often smaller. Infrastructure attacks are less common but tend to cause much larger losses.
- There is no foolproof defense. Audits, bug bounties, formal verification, multisig controls, and withdrawal delays can reduce risk, but none can guarantee that a protocol won't be exploited.
How do hacks work?
Once a smart contract is deployed, its logic can be inspected by anyone. A single coding error, flawed price feed, or missing verification check can give an attacker a way to make the contract do something its developers never intended.
In the overwhelming majority of attacks, hackers pore over the code of a targeted smart contract. The goal is usually not to brute-force passwords or crack encryption, but to find a bug they can exploit.
Here are five of the most common attack vectors in 2026.
Reentrancy: The exploit that built a fork
A reentrancy attack allows hackers to withdraw more funds than they are entitled to, potentially draining a smart contract entirely. The attacker repeatedly triggers a withdrawal function before the contract has updated its internal ledger.
Picture a bank teller handing you your withdrawal several times before updating your account balance. Because the balance hasn't changed yet, you can keep asking for more.
Example: The DAO hack
The most famous example dates back to June 2016 and triggered one of the biggest crises in Ethereum's history.
The DAO, a decentralized venture fund built on Ethereum, was drained of 3.6 million ETH, worth roughly $70 million at the time. A flaw in its smart contract allowed the attacker to receive ETH before the contract updated its internal accounting.
The bug was located in the contract's splitDAO function, which members could use to withdraw their funds if they disagreed with a project proposal.
- The attacker was able to receive ETH and immediately call the function again.
- Because the ledger had not yet been updated, the contract still treated the attacker as having funds available and sent more ETH.
- The cycle continued until millions of dollars' worth of ETH had been drained.
Fortunately for the Ethereum community, the stolen funds were locked in a child DAO for 28 days before they could be withdrawn. That gave developers and users time to debate how to respond.
The majority eventually voted for a hard fork that rewrote the blockchain's history, moved the stolen funds into a recovery contract, and bailed out affected investors. A minority refused to alter the ledger and continued using the original chain, which became known as Ethereum Classic.
Flash loans: Borrow millions, owe nothing, walk away rich
Flash loans are a legitimate DeFi tool used for arbitrage, refinancing, and other strategies. Unlike traditional overcollateralized crypto loans — where borrowers deposit more than they can borrow — flash loans require no collateral. The catch is that they must be repaid within the same transaction, or the entire operation is reverted.
Attackers have repurposed the mechanism to manipulate markets and exploit vulnerable DeFi protocols.
For example, an attacker can use a flash loan to move the price of an asset on an automated market maker such as Uniswap, then exploit that distorted price elsewhere in the same transaction.
The borrowed capital is returned to the lender, plus a small fee, before the transaction ends. The entire sequence — borrowing, manipulating the market, exploiting the protocol, and repaying the loan — can be executed atomically through smart contract code.
To the blockchain, it all happens as part of a single transaction. Depending on the network, the entire process can take seconds or less.
Flash loans themselves aren't the problem — they're just a tool. The vulnerability comes from what an attacker can do with the borrowed capital, particularly when a protocol relies on weak price oracles or other manipulable market data.
Oracle manipulation: Feeding the contract a lie
In an oracle attack, hackers manipulate the price feeds that smart contracts rely on to determine the market value of an asset.
Blockchains are closed systems, so smart contracts cannot natively access information from the outside world. Oracles act as the bridge, feeding external data such as asset prices into blockchain applications.
Oracle designs vary widely. Some use broad, decentralized and tamper-resistant networks such as Chainlink. Others rely on a single exchange, API, or flawed pricing mechanism.
If an attacker can manipulate the source an oracle relies on, they can feed a false price to a smart contract, and things go wrong fast. The result can be cheap loans against inflated collateral, stolen funds, or artificial liquidations.
A typical attack can look like this:
- The attacker takes out a large flash loan.
- They buy or sell a large amount of an asset on a thinly traded market, pushing its price sharply higher or lower.
- The smart contract checks the manipulated oracle and treats the false price as genuine.
- The attacker borrows valuable assets against artificially inflated collateral or exploits the distorted price in another way.
- They repay the original flash loan and keep the proceeds.
Oracle manipulation was at the center of the 2022 Mango Markets exploit, in which roughly $117 million was drained.
Puerto Rico resident Avraham Eisenberg artificially inflated the price of Mango Markets' native MNGO token by buying and selling millions of dollars' worth of MNGO and USDC between two Mango Markets accounts.
The manipulation pushed the value of his MNGO holdings roughly 40-fold, from around $10 million to $400 million, while trading volume surged by 2,000% that day. Using the inflated collateral, Eisenberg was able to borrow nearly all of the exchange's valuable assets.
Eisenberg argued that his actions were not illegal. In 2024, however, a federal jury in New York convicted him of commodities fraud, commodities market manipulation, and wire fraud in connection with the exploit.
Bridges: DeFi's favorite target
This attack vector goes beyond pure code bugs. Instead, attackers often compromise an authorized party responsible for approving cross-chain transactions.
Cross-chain bridges are protocols that enable the transfer of data, funds, or smart contract instructions between separate blockchain networks. They provide the infrastructure that lets users move assets between otherwise incompatible ecosystems — for example, representing ETH on another chain through a wrapped version.
Bridges have repeatedly proved to be one of DeFi's weakest points. They often secure enormous amounts of value while relying on complex verification systems that create additional attack surfaces. Some of the most high-profile bridge exploits include Ronin, which lost roughly $624 million, Wormhole ($326 million), and Nomad ($190 million).
A bridge typically involves a contract on the source chain, a messaging or verification layer, and a contract on the destination chain. The source-side contract locks or burns tokens. The verification layer confirms that event, after which the destination-side contract can mint or release the corresponding assets.
There are several ways to verify these messages, but many bridge exploits have involved compromised multisig signers or validator infrastructure. Attackers may use phishing or social engineering to obtain signing keys or gain access to the systems that control them.
Example: KelpDAO exploit
This was the case in April 2026, when North Korea's Lazarus Group drained 116,500 rsETH worth roughly $292 million from Kelp DAO's bridge in just 46 minutes.
According to the reported attack, the hackers used social engineering to obtain session keys and compromise internal remote procedure call (RPC) nodes. They also disrupted legitimate external nodes through a distributed denial-of-service (DDoS) attack.
The bridge was powered by LayerZero, while Kelp DAO's setup relied on a single decentralized verifier network (DVN). That meant compromising one verifier was enough to approve a fraudulent cross-chain transaction. Before the stolen funds were frozen, the attacker had moved them through a large handful of addresses to one consolidation address, as shown below.
The fallout triggered a major DeFi "bank run," with an immediate $10 billion exodus in total value locked across the sector. The attackers had used the fraudulent rsETH as collateral to borrow roughly $236 million worth of WETH, prompting users to rush for the exits before lending pools froze.
Not every bridge exploit requires stealing a signing key, however.
Sometimes the weakness is in the verification logic itself — as the Coreum–XRP Ledger bridge learned in August 2026. On August 9, an attacker drained roughly 199,916 XRP through 94 unauthorized transactions over 97 minutes. The XRP Ledger itself was never compromised, and no private keys were stolen.
Instead, the attack exploited a flaw in the bridge's deposit validation: its relayer checked transaction data and memo fields but failed to confirm that the funds had actually reached the designated deposit address.
The attacker could therefore create transactions that looked like valid deposits, triggering the bridge's automated multisig system to release real XRP from its reserve. It was essentially a fake receipt being accepted as proof of payment — with the bridge paying out real money in response.
Access control: When the wrong person gets the keys
Before executing a transaction, a smart contract typically checks whether the caller has the necessary permissions. Certain functions, for example, may only be accessible to an administrator or authorized address.
If those controls are incorrectly implemented or can be bypassed, attackers may gain access to functions they should never be able to call, including functions capable of changing contract settings, minting tokens, or withdrawing funds.
The code can work exactly as designed — the failure is that the wrong person got the keys to use it.
That's essentially what happened to TrustedVolumes, a DeFi liquidity provider and market maker, in May 2026. An attacker walked away with an estimated $6.7 million by finding one door the protocol forgot to lock.
TrustedVolumes traded directly out of its own token reserves, and every trade needed a kind of digital sign-off proving the protocol had actually approved it — like a stamp of authenticity. That stamp could only come from a short list of pre-approved signers.
The problem was the function controlling who got added to that list had no protection on it at all. The attacker simply called it themselves and put their own wallet on the list.
From then on, every trade they made carried a valid-looking stamp of approval, so the protocol had no way to tell the difference between a real trade and a fake one. Using that access, the attacker drained a mix of tokens — WETH, WBTC, USDT, and USDC — converted everything to ETH, and spread it across several wallets before anyone caught on.
Not all hackers are the enemy
The hackers behind the biggest crypto exploits are often organized criminal groups. One of the most notorious is North Korea's Lazarus Group, which has been linked to some of the industry's largest heists, including the 2022 Ronin bridge attack and the 2025 Bybit hack, which alone resulted in $2.7 billion in losses.
But it doesn't always take a sophisticated criminal syndicate. Small groups — or even solo hackers — can exploit newly deployed contracts with poorly designed or overlooked vulnerabilities. Protocols rushing to market may skip thorough audits, limit stress-testing, or simply miss an edge case that later proves costly.
And then there are white-hat hackers, who aren't trying to steal anything at all. These independent security researchers look for vulnerabilities and report them to protocols so they can be fixed. In return, they may receive a bug bounty or other reward.
Hackers don't even have to be human anymore. As AI agents become more capable, they can assist with finding vulnerabilities and generating exploit code. This raises particular concerns around zero-day vulnerabilities — previously unknown flaws for which developers have had no time to release a fix, leaving affected systems exposed until the vulnerability is discovered and patched.
Reducing the odds, not the risk to zero
There is no foolproof defense against smart contract exploits. Security-conscious protocols instead build multiple layers of protection, combining independent code audits, bug bounty programs, formal verification, and operational safeguards.
Specialized security firms inspect smart contracts before deployment, looking for vulnerabilities that could be exploited once the protocol goes live. Bug bounty programs take a different approach: they effectively crowdsource vulnerability detection to a much larger pool of independent researchers, who are rewarded for finding and responsibly disclosing flaws.
Formal verification goes a step further by using mathematical methods to prove that specific properties of a smart contract hold under defined conditions. It can provide a much stronger assurance than conventional testing, although it does not eliminate every possible security risk.
Protocols add security at the operational level too — multisignature requirements can prevent a single compromised key from draining a treasury, and time-delayed withdrawals give developers and security teams a window to detecxt and stop suspicious transactions before they become irreversible.
The goal is to make the protocol harder to break and to limit the damage when something inevitably slips through.
No two bugs alike
None of these attack vectors are new, and none of them are going away. The tools attackers use are getting more sophisticated too, from AI-assisted vulnerability scanning to increasingly coordinated state-sponsored operations like Lazarus Group's. The attack surface isn't shrinking; it's just shifting to wherever the weakest link happens to be that month.
For anyone using DeFi protocols, that's less a reason for alarm than a reason for realism. Audits, bug bounties, and multisig controls all reduce risk, but none of them make a protocol invulnerable — and the protocols that get exploited are often ones that looked perfectly secure right up until they weren't.
The most useful habit is understanding how these exploits actually work, so a headline about a nine-figure hack reads less like a mystery and more like a mechanism you already recognize.
