Smart contract security is the practice of finding and fixing the flaws that let attackers drain funds from Ethereum apps. Because contracts are public, hold money, and usually cannot be edited once deployed, a single bug can be permanent and costly. This guide tours the common flaws and what an audit really catches.
Why are smart contracts such a tempting target?
Smart contracts are tempting targets because they are public, often hold large sums, and usually cannot be changed after launch, so a flaw is both visible and permanent. Anyone can read the code looking for mistakes. The prize for finding one can be millions of dollars. And the contract often cannot be patched the way a website can. That combination is unique to on-chain software.
The permanence is the part newcomers underestimate. When a normal company finds a bug, it pushes a fix and moves on. When a deployed contract has a bug, the code keeps running exactly as written until someone deploys a replacement. Many contracts are not built to allow that. Meanwhile the code is fully public, so attackers can study it at leisure, and the funds it controls are right there to take. An exploit is not a data breach to be cleaned up later. It is usually an irreversible transfer of money.
A useful picture is a bank vault with a glass front and a published blueprint. The valuables are visible, the locking mechanism is open for anyone to inspect, and once money leaves, there is no calling the bank to reverse it. That is why security work happens before deployment, not after, and why the stakes are so high. Because you self-custody when using these contracts, their flaws become your risk directly, a theme our overview of DeFi yield risks for investors returns to. The next section names the flaws that show up most often.
What are the most common smart contract vulnerabilities?
The most common vulnerabilities are reentrancy, oracle manipulation, access-control mistakes, signature replay, and economic exploits like flash-loan attacks. Each is a different way of tricking a contract into doing something its authors did not intend. Knowing the names helps you read incident reports and judge how seriously a project takes safety.
The table gives a plain-language version of each.
Vulnerability | What goes wrong | Plain-language version |
|---|---|---|
Reentrancy | A contract is called back before it updates its records | Withdrawing from an ATM that forgets to subtract the first withdrawal |
Oracle manipulation | A contract trusts a price feed an attacker can distort | Faking the exchange rate a loan relies on |
Access control | A sensitive function is left open to anyone | Leaving the manager's keys in the front door |
Signature replay | A valid signed message is reused where it should not be | Using the same signed check twice |
Integer overflow / underflow | A number wraps past its limit to a wrong value | An odometer rolling from all nines back to zero |
Front-running / MEV | Someone reorders or inserts transactions to profit | Cutting the queue once they see your order |
Denial of service | A function is made to fail or get stuck so others cannot use it | Jamming the lock so no one can open the door |
Timestamp dependence | Logic relies on block time a proposer can nudge | Trusting a clock the other player can set |
Economic / flash-loan | Borrowing a huge sum briefly to bend a market or rule | Renting enough chips to swing the whole table for one hand |
Each maps to a real failure mode. Reentrancy and access-control bugs are coding mistakes, where the logic simply does the wrong thing in the wrong order or fails to check who is calling. Access-control failures have been among the costliest: in 2017, a flaw in the widely used Parity multi-signature wallet library let one user trigger a function that permanently froze roughly 500,000 ETH belonging to others. Integer overflow was a common early bug, where a balance could wrap past its maximum to a garbage value, though modern Solidity (version 0.8 and later) checks for it automatically, so today it mainly signals risky legacy code. Front-running, a form of the broader "maximal extractable value" or MEV, is when someone watches the pending-transaction pool and jumps ahead of your trade to profit. Oracle manipulation and economic exploits are subtler. The code may be correct, yet still be gamed by someone who distorts the prices or liquidity the contract depends on, which is why how a contract sources its data matters (source: Ethereum.org oracles documentation). Flash loans make the economic attacks worse. They let an attacker briefly command huge capital with no collateral, then use it to bend a market within a single transaction. The variety is the point: securing a contract means defending against both broken code and clever economics.
How does a reentrancy attack actually work?
Reentrancy works when a contract sends money out before it updates its own records. That lets the attacker's code call back in and withdraw again before the first withdrawal is recorded. The contract keeps paying because, as far as its unupdated books show, the balance is still there. It is a timing flaw, not a broken lock.
Walk through it slowly, because the sequence is the whole trick. Imagine a vault contract that, when you withdraw, first sends you the ETH and only afterward sets your balance to zero. An attacker writes a contract that, the instant it receives the ETH, immediately calls "withdraw" again. Because the balance has not yet been zeroed, the vault thinks the attacker is still owed money. So it pays a second time, then a third, looping until the vault is drained. The fix is simple in hindsight: update the balance before sending the money, so the second call sees zero.
This is not a hypothetical. The most famous case was the 2016 attack on "The DAO," an early Ethereum investment fund (source: Consensys smart contract best practices). It used exactly this flaw to drain roughly a third of the funds in the contract. The event was so serious it split the Ethereum community over how to respond, and led to the fork that created Ethereum and Ethereum Classic. Reentrancy is not just history, either: as recently as September 2024, the Penpie protocol lost about $27 million to a reentrancy bug, showing the same class of flaw still bites modern, audited code. Modern tools and standard patterns make reentrancy far easier to prevent now, which is why auditors check for it first. But it remains the textbook example of how a tiny ordering mistake becomes a catastrophic loss, and variations still appear in new code.
What does a security audit actually catch, and what does it miss?
A security audit catches known bug patterns and common mistakes, but it cannot guarantee a contract is safe, especially against novel logic flaws and economic attacks. Auditors read the code, run automated tools, and test against a checklist of known vulnerabilities, which removes a large share of risk. What they cannot do is prove the absence of every possible flaw.
The split between caught and missed is worth understanding honestly. Audits reliably catch the well-documented patterns: reentrancy, access-control gaps, and many coding errors. These match known signatures that tools and reviewers spot quickly (source: Ethereum.org smart contract security). They struggle with two things. The first is genuinely novel logic bugs that no checklist anticipates. The second is economic exploits, where every line is correct but the system can still be gamed with enough capital. An audit is also a snapshot, so later upgrades or changed market conditions can introduce risks the audit never saw.
This is why "audited" should be read as a floor, not a guarantee. Many exploited protocols had been audited, sometimes by reputable firms, because the flaw lay outside what the audit examined. From Blofin's operational perspective, the exploits we see cluster in newer, complex protocols and in cross-chain bridges, where code is intricate and large sums pool together, so we treat an audit as a minimum bar rather than a clean bill of health. A sensible reader uses an audit as one input among several, alongside how long the contract has run untouched and how much value has trusted it.
What can a 2026 exploit teach beginners?
The largest exploit of 2026 was a bridge attack on a staking protocol in April that drained roughly $292 million, and its lesson is that bridges concentrate risk. A bridge holds large pools of assets while moving them between networks, so a single flaw in that complex machinery can expose enormous sums at once. It is the clearest recent example of where danger clusters.
The episode rhymes with a pattern, not a fluke. Bridges have repeatedly been among the most costly targets in crypto (source: Chainalysis: crypto bridge hacks). They combine three risk multipliers: they hold a lot of value, their code is unusually complex, and they connect systems that each have their own assumptions. When an attacker finds the seam between those systems, the payout is large. The April 2026 attack triggered a wave of withdrawals across DeFi as users pulled funds to de-risk (source: CoinGabbar: top DeFi protocols 2026). One exploit can shake confidence well beyond the protocol involved.
For a beginner, the takeaways are practical rather than technical. Treat bridges and brand-new, complex protocols as higher-risk by default, regardless of marketing. Do not assume that a large, well-known name cannot be exploited, because size attracts attackers. And remember that an on-chain loss is usually permanent, so the time to be cautious is before you deposit, not after the headlines. Caution is not pessimism here; it is the rational response to irreversible software.
How can a beginner judge a contract's risk?
A beginner can judge contract risk by checking a few practical signals. Has the code been audited? How long has it run without incident? How much value already trusts it, and can it be changed? None of these is a guarantee, but together they paint a useful picture. The goal is to stack the odds, not to find certainty.
A short mental checklist covers most of it. First, look for a published audit from a known firm, treating it as a floor rather than proof. Second, favor contracts that have run untouched for a long time and held significant value, since survival is its own evidence, sometimes called the Lindy effect. Third, be wary of brand-new protocols offering unusually high returns, because outsized yield often signals outsized risk, a link our guide on DeFi yield for investors explains. Fourth, check whether the contract is upgradeable, which is a double-edged trait covered in the pillar's guide on contract upgradability.
The honest bottom line is that you are managing risk, not removing it. Even the most careful checklist cannot rule out a novel exploit, which is why sizing your exposure matters as much as vetting the contract. Never commit more to a single protocol than you can afford to lose entirely, and spread risk rather than concentrating it. Because you self-custody, the discipline is yours to apply, and our overview of how crypto wallets work covers the custody side of that responsibility.
Frequently asked questions
Does an audit mean a contract is safe?
No, it means a contract passed a review against known issues, which lowers risk but does not remove it. Audits catch common patterns like reentrancy and access-control errors, but they can miss novel logic flaws and economic attacks where the code is technically correct. Many exploited protocols had been audited. Treat an audit as a minimum bar and one signal among several. How long the contract has operated and how much value it safely holds matter just as much. An audit is not a guarantee of safety.
What is reentrancy in plain words?
Reentrancy is when a contract pays out before it updates its records, letting an attacker withdraw repeatedly before the first withdrawal is counted. Picture an ATM that hands you cash but forgets to subtract it from your balance until later, so you keep withdrawing the same money. The fix is to update the balance first, then send the funds. It was the flaw behind one of Ethereum's most famous early hacks, and auditors now check for it as a priority.
Can I get my money back after an exploit?
Usually not, because on-chain transfers are irreversible and there is no central authority to reverse them. In rare cases, attackers return funds, protocols reimburse users from a treasury, or a whitehat recovers assets, but none of these is guaranteed or common. This permanence is exactly why caution before depositing matters so much. The realistic assumption is that funds lost to an exploit are gone, which should shape how much you are willing to expose to any single contract.
Are new protocols riskier than established ones?
Generally yes. A brand-new protocol has not been tested by time, real usage, or determined attackers, so unknown flaws are more likely to surface. Established contracts that have held large sums untouched for a long time have, in effect, survived continuous attempts to break them. This is not a guarantee, since even old protocols get exploited, but time-in-service is meaningful evidence. Unusually high yields on a new protocol are a particular warning sign, because they often compensate for elevated risk.
What is a flash-loan attack?
A flash-loan attack uses a special loan that is borrowed and repaid within a single transaction, with no collateral, to briefly command enormous capital. The attacker uses that capital to distort a price or drain a pool, profits from the distortion, and repays the loan, all in one atomic step. Because the code often behaves exactly as written, these attacks exploit economic design rather than a coding bug, which makes them hard for audits to catch. They are a signature example of an economic exploit.
How do I check whether a contract is audited?
Most reputable projects publish their audit reports on their website or documentation, often naming the firm that performed the review. Block explorers can show whether a contract's code is verified and public, which lets reviewers inspect it, though verification is not the same as an audit. Be cautious if a project cannot point to any audit or hides its code. Even then, remember that an audit is a floor, so confirming one exists is a starting point for your own judgment, not the end of it.
Researched and written by the Blofin Academy editorial team with AI-assisted drafting. Primary sources include the Ethereum.org smart contract security documentation, with vulnerability patterns and 2026 incident context drawn from established security research and current DeFi reporting. All facts independently verified against cited sources current as of June 2026.
This article is for informational purposes only and does not constitute financial advice, investment guidance, or a recommendation to buy, sell, or hold any digital asset. Smart contracts carry technical risk including the permanent, irreversible loss of funds, and no audit or checklist can guarantee safety. Cryptocurrency markets involve significant risk and you should conduct your own research and consult qualified professionals before making decisions.