10 Smart Contract Vulnerabilities and How to Prevent Them

1. Access control vulnerabilities (SC01)

What it is. Access control decides who can call a contract's privileged functions, such as minting tokens, moving treasury funds, pausing the protocol, or upgrading the code. A vulnerability exists when those checks are missing, misconfigured, or tied to a single key that can be stolen.

Business impact. Access control failures are usually total: once attackers hold an admin role, the contract simply does what they say. Hacken attributes $2.12 billion of 2025 losses to access control exploits, a figure that also includes compromised keys and infrastructure.

Real-world example. On July 19, 2017, an attacker took 153,037 ETH (about $30 million) from three Parity multisig wallets. The wallets forwarded unknown calls to a shared library, which left its initWallet() function open to anyone. The attacker called it, became the sole owner, and withdrew the funds. More recently, Zoth lost $8.4 million in March 2025 after the single wallet holding its admin and upgrade rights was compromised.

How to prevent it.

• Use established role-based access control libraries, such as OpenZeppelin's AccessControl.
• Put admin and upgrade roles behind a multisig or governance with a timelock, never a single wallet.
• Lock initialization functions, and monitor every privilege change in real time.

2. Business logic vulnerabilities (SC02)

What it is. Business logic vulnerabilities are design flaws, not typos. The code does exactly what it says, but what it says allows an outcome nobody intended, such as rewards claimed twice or a liquidation that pays out too much.

Business impact. Logic flaws let attackers extract value through normal-looking transactions, and code scanners rarely catch them because nothing is technically broken. Finding them takes someone who understands how the protocol is meant to hold value, and who thinks like an attacker trying to extract it.

Real-world example. On March 13, 2023, Euler Finance lost about $197 million. Its donateToReserves() function let users donate collateral without checking whether their account stayed healthy. The attacker made their own position insolvent, then liquidated it at a profit. Unusually, the attacker returned nearly all recoverable funds within weeks. Most victims aren't that lucky: Abracadabra lost about $12.9 million in March 2025 to flawed collateral accounting.

How to prevent it.

• Model the protocol's economics with simulations before writing code.
• Encode core invariants in code and tests, such as "withdrawals can never exceed deposits plus yield."
• Use property-based fuzzing and formal verification on accounting functions, and launch new features with caps.

3. Price oracle manipulation (SC03)

What it is. Protocols need asset prices to set collateral values, liquidations, and swap rates. An oracle supplies that price. Oracle manipulation happens when the price comes from a source an attacker can move, such as a thinly traded pool, for long enough to profit.

Business impact. A manipulated price lets attackers borrow far more than their collateral is worth, leaving the protocol with bad debt. These attacks are becoming more common. By late August 2026, TRM Labs had counted 32 price-manipulation exploits that year, about one in eight hacks, up from one in 17 in 2022. They include Tectonic, where an attacker borrowed about $75 million in August 2026 before a Cronos chain rollback reversed most of the loss.

Real-world example. On October 11, 2022, an attacker pushed the price of MNGO on Mango Markets up more than twentyfold within minutes, then borrowed more than $110 million against the inflated collateral. After a governance vote, about $67 million was returned. The attacker was convicted of fraud in April 2024, but a federal judge vacated the convictions in May 2025. Legal recourse after an exploit is far from certain.

How to prevent it.

• Aggregate prices from several independent sources, and use time-weighted average prices (TWAPs) instead of spot prices.
• Reject stale data, and set conservative collateral factors for illiquid assets.
• Add circuit breakers that pause activity during abnormal price movements.

4. Flash loan attack (SC04)

What it is. A flash loan is an uncollateralized loan borrowed and repaid within a single transaction. It's a legitimate DeFi tool, but it gives anyone hundreds of millions of dollars for a few seconds. A flash loan attack uses that capital to exploit a weakness that would otherwise need deep pockets.

Business impact. Flash loans remove the attacker's biggest constraint: their own capital. A tiny rounding error or a governance assumption becomes exploitable at scale, and the damage can outlast the theft. Bunni lost $8.4 million to a flash loan–driven exploit in September 2025 and shut down a month later, saying a secure relaunch would cost "6-7 figures in audit and monitoring expenses alone."

Real-world example. On April 17, 2022, an attacker flash-borrowed about $1 billion in stablecoins to take over Beanstalk's governance. With over 78% of the voting power, they passed a proposal that sent the protocol's funds to their own wallet. Beanstalk lost about $182 million, and the attacker kept about $76 million after repaying the loans in the same transaction.

How to prevent it.

• Base voting power on balances recorded before a proposal, and delay execution.
• Cap position sizes, rate-limit high-impact actions, and test against adversarial multi-step transactions.
• Fix the underlying logic, oracle, or arithmetic flaw, because the flash loan is only the amplifier.

5. Lack of input validation (SC05)

What it is. Contracts constantly receive inputs: amounts, addresses, signatures, tokens, and messages from other chains. Lack of input validation means the contract accepts them without checking that they're within bounds, authentic, and well-formed.

Business impact. Unvalidated inputs are a common way into bridges and lending markets, where one fake message or token can create money out of nothing. Once one attacker shows the way, these bugs are easy to copy.

Real-world example. On August 1, 2022, Nomad Bridge lost about $190 million. A routine upgrade set the contract's trusted root to zero, so messages with no valid proof were accepted. After the first attacker succeeded, hundreds of copycats replayed the same transaction with their own addresses and drained the bridge within hours. White hats later returned over $36 million. In 2025, Ionic Money lost about $6.9 million after accepting a counterfeit token as collateral.

How to prevent it.

• Validate every external input: numeric bounds, zero addresses, chain IDs, signatures, and nonces.
• Verify that every token, message, and admin input is authentic before it can affect balances.
• Write negative tests that deliberately feed the contract bad data.

6. Unchecked external calls (SC06)

What it is. Contracts often call other contracts to transfer tokens, route swaps, or pay refunds. An unchecked external call is one where the contract doesn't safely handle what happens next. The call might fail silently, return an unexpected value, or call back in with malicious code.

Business impact. Every external call hands control to code you didn't write. If your contract assumes the call worked, or that nothing else can happen until it finishes, attackers can profit from the gap.

Real-world example. On July 9, 2025, GMX V1 lost $42 million. An unsafe external interaction in its refund process let the attacker's contract re-enter before global state updated, distorting the price of GMX's liquidity token. Two days later, the attacker returned about $40.5 million in exchange for a bounty. The same month, Arcadia Finance lost $3.5 million to arbitrary calls routed through router addresses it never validated.

How to prevent it.

• Follow the checks-effects-interactions pattern: validate, update state, and only then call out.
• Prefer pull-based payments, and check every return value with wrappers such as OpenZeppelin's SafeERC20.
• Allowlist the contracts your protocol is permitted to call.

7. Arithmetic errors (SC07)

What it is. Smart contracts work with whole numbers, so every division rounds. Arithmetic errors are rounding, scaling, and precision bugs that each look harmless. Attackers repeat them thousands of times, usually with borrowed capital, until they add up to real money.

Business impact. These bugs hide in the formulas behind share prices, interest, and swap rates. They often survive testing because they only matter at extreme values, such as a nearly empty pool or a massive flash-loaned trade.

Real-world example. On November 3, 2025, Balancer V2 lost about $128 million across several chains. Balancer's preliminary report traced the loss to a rounding error in the scaling function used by batch swaps, and some funds were later recovered or frozen. Earlier that year, zkLend lost $9.5 million to a rounding error in its deposit logic, which the attacker repeated until a small discrepancy became a drain.

How to prevent it.

• Decide which way each calculation rounds, and make sure rounding favors the protocol.
• Use reviewed math libraries, and add invariant checks such as total assets versus user balances.
• Fuzz-test edge cases, including zero supply, first deposits, and maximum values.

8. Reentrancy attack (SC08)

What it is. A reentrancy attack happens when a contract sends funds or calls another contract before updating its own records. The receiving contract calls back in and withdraws again and again, while the original contract still thinks the balance is untouched.

Business impact. Reentrancy is the oldest well-known smart contract vulnerability, and it still shows up in new code. Hacken's 2025 report counts the GMX exploit as a reentrancy case, a sign that new hooks, callbacks, and integrations keep reopening old risks.

Real-world example. On June 17, 2016, an attacker exploited a reentrancy bug in The DAO, an early decentralized venture fund, and drained about 3.6 million ETH, worth roughly $50 million at the time. The fallout was so large that Ethereum hard-forked on July 20, 2016, to reverse the hack. The original chain continued as Ethereum Classic.

How to prevent it.

• Apply reentrancy guards to every function that changes state and makes external calls.
• Update balances before sending anything, following checks-effects-interactions.
• Treat token callbacks (ERC-777, ERC-721, and ERC-1155 hooks) as possible entry points.

9. Integer overflow and underflow (SC09)

What it is. Every number in a contract has a maximum size. An overflow happens when a calculation passes that limit and wraps around to a tiny number, like an odometer rolling back to zero. An underflow is the reverse. Solidity 0.8 and later revert on overflow by default, but unchecked blocks and inline assembly don't. Move's standard arithmetic also aborts on overflow, but its bit shifts don't: a left shift silently drops any bits that overflow, so developers have to check shifts themselves.

Business impact. A wrapped number can make a huge withdrawal look tiny, which usually breaks a pool's core math. Because math libraries are shared, one bug can expose every protocol that uses the library.

Real-world example. In May 2025, Cetus, the largest decentralized exchange on Sui, lost about $223 million. A shared math library had a custom overflow check for a left bit shift, but the check used the wrong threshold. A huge value passed the check, and the shift silently dropped its high bits. The protocol then calculated that a single token was enough to mint an enormous liquidity position. Sui validators froze about $162 million of the stolen funds, an intervention most chains can't offer.

How to prevent it.

• Avoid unchecked arithmetic unless the code is proven safe and covered by tests.
• Guard every unchecked operation, such as bit shifts in Move, and audit shared libraries as well as your own code.
• Fuzz-test minimum and maximum values around every calculation.

10. Proxy and upgradeability vulnerabilities (SC10)

What it is. Many protocols use upgradeable contracts: a proxy that holds the funds and points to logic contracts that can be swapped out. That flexibility creates two kinds of risk. Attackers may take control of the upgrade role or initialize a contract the team forgot to set up, then point the proxy at malicious code. The team itself can also cause damage: a careless upgrade that changes the storage layout can corrupt balances and settings without any attacker involved.

Business impact. Upgrades are often treated as routine maintenance, but each one changes the code that guards your users' funds. One mistake in setup or permissions can hand over control or lock everything permanently.

Real-world example. On November 6, 2017, a user found that the shared library behind Parity's multisig wallets had never been initialized. They initialized it, became its owner, and triggered its self-destruct function. Every wallet that depended on the library stopped working, freezing 513,774 ETH across 587 wallets. The funds are still inaccessible. The risk is current, too: in July 2025, Kinto lost $1.55 million after attackers initialized its proxies with a backdoored implementation before the team did.

How to prevent it.

• Use established proxy standards, and initialize contracts in the same transaction that deploys them.
• Put upgrades behind a timelocked multisig or governance process.
• Check storage layout compatibility, and audit every upgrade, not only the first version.

What are the most common smart contract vulnerabilities?

According to the OWASP Smart Contract Top 10: 2026, the most common smart contract vulnerabilities are access control flaws, business logic flaws, price oracle manipulation, flash loan–facilitated attacks, lack of input validation, unchecked external calls, arithmetic errors, reentrancy, integer overflow and underflow, and proxy and upgradeability flaws.

What is the OWASP Smart Contract Top 10?

The OWASP Smart Contract Top 10 is a ranked list of the most significant smart contract security risks, published by the Open Worldwide Application Security Project. The 2026 edition is based on 122 incidents from 2025, about $905.4 million in losses, and a survey of auditors, researchers, and incident responders.

What are the risks of smart contracts?

The main risk is that a flaw in the code or design lets attackers steal or freeze funds. Smart contracts are public, hard to change, and connected to other protocols, so attacks spread fast and are difficult to reverse. Key management, admin roles, and upgrades add operational risks on top of smart contract security vulnerabilities in the code.

How does a reentrancy attack work?

A contract sends funds to another contract before updating its own balance records. The receiving contract calls back in and withdraws again before the balance updates, repeating until the funds run out. The DAO lost about 3.6 million ETH this way in 2016.

Are overflow bugs still a risk with Solidity 0.8?

Yes, though the risk is lower. Solidity 0.8 and later revert on overflow by default, but unchecked blocks and inline assembly can still wrap silently. In Move, standard arithmetic aborts on overflow, but bit shifts don't. The $223 million Cetus exploit on Sui in 2025 came from a flawed overflow check on a left shift.

Can a smart contract audit find every vulnerability?

No audit can guarantee that, but an independent smart contract audit catches many of the logic, oracle, and upgrade flaws that automated tools miss. The strongest protection combines an audit before launch, a re-audit after major upgrades, and a continuous bug bounty program.