12 Smart Contract Vulnerabilities With Real Hack Examples & Fixes

Smart contracts can move money, trigger rules, and run business logic without manual approval. That also means one small bug can become a costly exploit. Smart contract vulnerabilities often hide in access control, oracle data, input checks, and contract calls. This MOR Software guide explains the main risks, real hack cases, and practical fixes teams should review before launch.

Key Takeaways

• Smart contract vulnerabilities can start from small coding errors, weak role settings, unsafe external calls, or poor data checks, then turn into major fund losses after deployment.
• The 12 risks covered include reentrancy attacks, oracle manipulation and flash loan attacks, insecure randomness, business logic errors, force-feeding attacks, lack of input validation, denial of service, integer underflows and overflows, access control vulnerabilities, gas griefing, transaction order dependence attacks, and timestamp dependence.
• Stronger planning, secure patterns, testing, audit support, and long-term maintenance help teams find contract security weaknesses before users and funds enter the system.

What Are Smart Contract Vulnerabilities?

Smart contract vulnerabilities are weak points in a contract’s code, structure, or rules that attackers may abuse. These risks often come from coding errors, unsafe design choices, or security steps that were missed during development.

A smart contract vulnerability signals possible danger, but it does not always lead to an attack. It creates smart contract attack surfaces that may become harmful when teams leave them open.

Attack vectors are the routes attackers use to turn these flaws into real damage. Put another way, they are the methods used to exploit smart contract vulnerabilities in blockchain and gain value from a weakness.

12 Smart Contract Vulnerabilities And How To Fix Them

Blockchain smart contract vulnerabilities can put DeFi platforms, token systems, and decentralized apps at risk of major losses. Because contracts may hold funds and run code on their own, one small logic mistake can turn into a serious exploit. The table gives a short smart contract vulnerabilities list with the main risk and the safest fix before we break down each case.

Reentrancy Attacks

Reentrancy attack vectors happen because Solidity contracts run step by step. One instruction must finish before the contract moves to the next one. When a contract calls another contract, the first contract stops and waits for the reply. During that pause, the second contract may control the next action, which can lead to a repeated call loop.

A hostile contract, for one case, may call back into the first contract and withdraw assets again before the first withdrawal ends. The first contract may then fail to update its balance in time. Reentrancy can appear as single-function, cross-function, cross-contract, cross-chain, or read-only attacks. Public exploit records give many smart contract vulnerabilities examples tied to this issue.

How To Fix It: This contract flaw starts when the contract logic is unsafe. Developers should plan outside calls with care and update the contract state before sending funds, including reducing the ether balance before a transfer request runs. A reentrancy guard can stop repeated entry because it locks the function during execution. MOR Software supports secure design review, testing, and QC checks to help teams catch reentrancy risks before release.

Real Hack Example: In a 2024 reentrancy attack on Penpie, attackers stole about $27 million worth of ether, the native coin of Ethereum.

Oracle Manipulation And Flash Loan Attacks

Smart contracts use an oracle to read data from outside the blockchain platforms. This allows them to work with off-chain systems, including asset prices and market data. When oracle data is wrong or controlled by an attacker, the contract may run a false action. This problem is often called the oracle issue.

Many DeFi apps have lost funds through this route, with flash loans being a common tool. A flash loan is an unsecured loan that can be very large, as long as it is paid back in the same transaction. Attackers use this setup to push token prices away from fair value, take profit, and still follow the chain’s transaction rules.

How To Fix It: A safer design uses decentralized oracle logic, several trusted data feeds, or strong data checks before the contract acts. This makes defi smart contract vulnerabilities harder to abuse because attackers must control more than one data source. MOR Software can help design safer integration flows, test API logic, and review how outside data affects contract behavior.

Real Hack Example: Abracadabra, a decentralized crypto lending platform, was hit by a flash loan exploit that led to about $13 million in stolen ether.

Insecure Randomness

Cryptographic systems depend on random values when they create keys or run contract actions. The basic rule is simple: random numbers must be hard to guess. That sounds easy, but it is hard to do well. When randomness is weak or predictable, attackers may find ways to bypass protections that support smart contract vulnerabilities and their security model.

How To Fix It: Use cryptographic methods that follow accepted standards for random number generation. NIST runs research and publishes standards that help teams build safer random value systems.

Real Hack Example: The $FFIST crypto token was attacked, leading to a loss of about $110,000. The exploit was linked to a random value source that attackers could predict.

Business Logic Errors

A business logic error is a design mistake inside one contract or across several contracts. This mistake makes the contract act in a way the team did not plan. Attackers can abuse these logic flaws to move funds, change outcomes, or break key rules. The same risk can appear in AI smart contracts when the control rules, data flow, or decision paths are poorly planned.

How To Fix It: Developers should test all contract code, including every mix of business rules. The real behavior must match the intended design in each case. Teams should use manual review, automated checks, and expert code analysis to find possible logic mistakes before launch.

Real Hack Example: SIR.trading, a DeFi protocol, suffered a logic flaw attack in March 2025. The incident caused about $355,000 in stolen funds.

Force-Feeding Attacks

Force-feeding attacks abuse one basic fact: developers cannot fully stop a smart contract from receiving ether. An attacker can send ether to a contract and change its visible balance. This may break any internal rule that depends only on the contract’s expected balance, including reward logic that pays out when a balance passes a set level.

How To Fix It: This type of balance change cannot be fully blocked. A contract should never treat its own ether balance as the only check inside a function. The real balance can be higher than the value tracked in the contract’s internal records.

Lack Of Input Validation

Every blockchain software development system must check inputs, and this rule has shaped safe development for many years. It is risky to assume that users will always send valid data. Attackers can submit crafted inputs that crash logic, briefly block contract access, or make the system behave in strange ways. The bigger danger is input that changes data or contract behavior, since this can be used to control the contract.

How To Fix It: Developers should check each input before the contract uses it. Extra checks should also sit inside the contract in case unsafe data passes the first guard and reaches the processing step. MOR Software’s testing and secure development practices can help teams detect smart contract security vulnerabilities tied to bad inputs, error handling, and unsafe data flow.

Real Hack Example: Onyx, a DeFi protocol, lost $3.8 million after attackers abused an input validation weakness.

Denial Of Service

Like other web-based systems, smart contracts can still face DoS attacks. When attackers flood a service, including authentication or contract calls, they may stop other contracts from running or cause sudden reverts where unused gas comes back and the state returns to its earlier point. These smart contract vulnerabilities can let attackers twist auction results or financial values for their own gain.

How To Fix It: The best defense is to make each attack too costly to repeat. Time-lock puzzles and gas fees can raise the cost for anyone trying to abuse the system. Calls should also go only to trusted contracts, which lowers the chance that a DoS issue becomes a serious failure.

Real Hack Example: This was not a direct exploit case, but in April 2025, Ethereum Improvement Proposal 7907 was approved to help protect contracts from DoS risks linked to gas metering.

Integer Underflows And Overflows

Integer underflows and overflows happen when a math result moves past the allowed fixed range, such as 0 to 255 for the uint8 type. Any value above 255 wraps back to 0, and any value below 0 turns into 255. These wrong number changes can alter contract state and logic, which then leads to invalid actions.

How To Fix It: Since Solidity 0.8.0 came out near the end of 2020, the compiler blocks code that may cause integer underflow or overflow. Teams should review contracts built with older compiler versions, especially any function that handles math, or use a library like SafeMath to catch these number risks.

Real Hack Example: The Cetus decentralized exchange hack in May 2025 caused about $223 million in losses, and the root cause was a missing overflow check.

Access Control Vulnerabilities

Anyone can view and interact with public blockchain systems. Confidential or sensitive data should not be stored on-chain unless it is encrypted. Functions and state variables inside a contract may also be visible to other contracts, which creates room for misuse when access rules are weak.

How To Fix It: Developers should set clear access rules with the principle of least privilege, then use Solidity visibility settings for state variables and functions so each item has only the access it truly needs, which helps reduce common smart contract vulnerabilities.

Real Hack Example: KiloEx, a decentralized exchange, lost about $7 million because its contract had weak access control.

Gas Griefing

Users need to pay gas fees when they send a transaction or run a smart contract on the Ethereum network. These fees reward validators, formerly miners, for using resources to check transactions. Gas prices move based on network demand, supply, and capacity at that moment.

Gas griefing happens when someone gives enough gas for the target contract but not enough for its subcalls to other contracts. If the target contract fails to check whether a subcall has enough gas, that follow-up call may not run as planned. This smart contract vulnerabilities case can damage the app’s logic in ways users may not notice at first.

How To Fix It: There is no full method that can block gas griefing in every case. Developers should write the contract so it controls the gas sent to subcalls, rather than leaving that choice to the user. Still, if gas costs rise too much, the whole transaction may fail.

Transaction Order Dependence Attacks

A smart contract becomes visible to the network when it enters the pending transaction pool. This allows a block producer to choose transactions that pay higher gas fees. A user may add a priority fee, or tip, to push their transaction ahead of others in the same block. This also gives attackers a chance to spot profitable actions and send a copied transaction with a higher fee, so their version runs first. These attacks move in tiny time windows, so bots or miners often handle them.

How To Fix It: These attack vectors are hard to stop fully. One method is to accept only transactions below a set gas price. Another method is a commit-and-reveal design, where the user first sends a hashed answer and reveals the real value later, after others can no longer copy it in time. Smart contract vulnerability detection tools can also scan code for frontrunning risks, while consensus mechanism may watch pending transactions for strange patterns.

Timestamp Dependence

The node that runs a smart contract also creates timestamp values. Since Ethereum is a distributed system, no one can fully prove that every node has the same time. A node may change the timestamp it uses. That altered value can support a logic attack against a contract that depends on block.timestamp for time-based actions.

How To Fix It: To avoid that vulnerability, developers should not use block.timestamp as a control check, logic gate, or randomness source.

Security Patterns That Help Limit Smart Contract Vulnerabilities

Smart contract safety should start before the audit stage. Blockchain developers need safer logic from the first design step because deployed contracts are hard to change and often hold high-value assets. Security patterns give teams tested ways to limit risky flows, manage contract actions, and make behavior easier to test.

These patterns cannot remove every risk, but they create safer default choices. They help teams avoid mistakes in fund movement, outside calls, permission checks, and balance tracking. When teams pair them with automated tests, manual review, formal checks, and third-party audits, the chance of a major exploit drops.

Check, Update, Then Interact Pattern

This is one of the strongest ways to block reentrancy attacks. The contract should check all needed rules first, change its own state second, and only then call outside contracts or addresses. This order matters because outside calls may hand control to another contract. If funds leave before balances change, an attacker may call the function again and take more than allowed. A safer flow lowers the user balance before ether or tokens are sent.

Single-Entry Lock

A reentrancy guard places a lock on sensitive functions so the same function cannot start again before the first run ends. This works well for withdrawals, token transfers, staking rewards, lending pools, and any logic that calls outside contracts. Developers often add a modifier that rejects repeated calls while the function is active. This pattern should not replace clean logic, but it gives extra protection when outside calls are needed.

Operation Lock Pattern

The mutex pattern locks a contract or function during a sensitive action. The lock is removed after the action finishes. If a second call tries to enter during that period, the contract rejects it. This helps functions that change balances, pay rewards, run swaps, or move user funds. Developers must release the lock correctly because a bad mutex can block later users by mistake.

User-Claim Payment Pattern

Instead of paying users inside the same action, the contract records each amount and lets users withdraw later. This lowers the risk from failed transfers, hostile fallback logic, and denial-of-service cases. In an auction contract, refunding all losing bidders inside one call can create danger. A safer setup stores each refund and lets every bidder claim it on their own.

Contract Balance Cap Pattern

This pattern sets a maximum amount of ether or tokens that a contract can hold. If an exploit occurs, the largest possible loss becomes smaller. It works well for early protocols, test-stage contracts, and systems that do not need large balances. Teams can pair this with withdrawal caps, circuit breakers, and staged fund release rules to limit damage.

Role-Based Access Pattern

Sensitive functions should only open for the right roles. Admin tasks, upgrades, minting, pausing, fund transfers, and parameter edits need strict checks. Least privilege should guide the setup, so every role gets only the rights it needs. Weak permissions can let attackers or unapproved users change settings, remove funds, or control protocol actions.

Pause And Circuit Breaker Pattern

A pause function lets trusted roles stop risky actions when strange behavior appears. It can protect users during an exploit, oracle failure, liquidity issue, or sudden bug. The pause option should cover key functions only, unless the whole system must stop. Teams also need clear rules for who can pause operations and how the contract returns to normal.

Value Flow Limit Pattern

Rate limits control how much value can pass through a contract during a set time. This slows attackers and gives teams more time to react. It fits withdrawals, swaps, minting, bridge transfers, and reward claims. These limits must protect the protocol without blocking normal users.

Hidden-Then-Revealed Action Pattern

This pattern helps lower frontrunning and transaction order risks. Users first send a hashed form of their action, then reveal the real value later. Since others cannot see the action at once, attackers have fewer chances to copy or front-run it. This works for auctions, voting, games, and any contract where hidden data shapes the result.

Controlled Upgrade Pattern

Many smart contract platforms use proxy models so teams can change logic after launch. This gives useful flexibility, but it also adds risk. Upgrade rights must stay locked down, upgrade actions should include a delay, and users should get time to review major changes before they go live. A weak upgrade path can turn into a single failure point.

Safe Default Behavior

Contracts should reject unsafe actions as the default choice. If a condition is unclear, input is bad, or an outside call fails, the contract should stop instead of moving forward with uncertain state. This pattern lowers strange outcomes and makes the contract easier to review during testing and audits.

These patterns help developers build contracts that are harder to attack and simpler to maintain. The safest path is to apply them during design, not after bugs appear in live systems. Every outside call, input, role, timestamp, and balance check should be treated as a possible attack surface.

Best Practices To Prevent Smart Contract Vulnerabilities Before Launch

These best practices help developers build stronger protection around smart contract vulnerabilities before users and funds enter the system:

• Work With Reviewed Code Bases: Use proven libraries and checked components, and read all documents carefully so the code is used in the right way.
• Run Full Test Coverage: Aim for 100% branch coverage, test with different user types, and use fuzz testing, including the Foundry model, to catch errors.
• Request A Security Review: Work with MOR Software for smart contract review, secure development support, and QC testing to find possible weaknesses before launch.
• Handle ERC20 Calls Safely: When working with ERC20 tokens, use SafeERC20 to manage token actions that may fail.
• Use Multi-Signature Ownership: MultiSig wallets can manage contract ownership and lower the risk of one person becoming a single failure point.
• Pin Solidity Compiler Versions: Lock Solidity versions to avoid known compiler bugs and keep builds stable, such as using 0.8.10 instead of ^0.8.10.
• Review Outside Contract Calls: Check third-party contracts for bugs, audits, and correct use before your contract calls them, so outside risks stay lower.
• Treat Delegatecall With Care: Know that delegatecall runs code inside the caller’s contract state while keeping msg.sender and msg.value.
• Use msg.sender For Access Checks: Choose msg.sender instead of tx.origin for authentication to avoid access control bugs.
• Stop Number Wraparound Bugs: Use Solidity versions above 0.8 or use SafeMath when older compiler versions are required.
• Scan Code With Static Tools: Use tools like Slither for static analysis, and pair them with ethernet smart contract vulnerability detection workflows when teams review EVM-based contracts before launch.
• Check Function Inputs: Validate every argument users send so malicious input cannot reach unsafe logic.
• Watch Integer Division Rounding: Use multipliers for precision or keep the numerator and denominator as separate values.
• Set Visibility On Purpose: Mark visibility for functions and storage variables so they do not become reachable by accident.
• Do Not Use extcodesize To Identify EOAs. extcodesize can return 0 while a contract is still being created, which may cause unsafe checks.
• Limit High-Risk Functions: Add access rules to protect functions that can change funds, ownership, upgrades, or system settings.
• Add Emergency Pause Logic: Use pausable contracts so teams can stop risky actions during urgent events.
• Choose Pull Payments Over Push Payments: Let users claim funds themselves instead of sending payments to many users in one contract action.

How MOR Software Helps Teams Reduce Smart Contract Vulnerabilities In Real Projects

Smart contract vulnerabilities often come from small gaps in logic, access rules, input checks, or external contract calls. These issues are hard to fix after launch, so teams need secure planning before the first deployment.

MOR Software helps businesses build enterprise blockchain and Web3 products with a stronger engineering process. We support system design, backend development, smart contract development, API connection, QA testing, and long-term maintenance. Our team can review how smart contracts connect with wallets, payment flows, databases, admin tools, and third-party services, so risky logic does not sit unnoticed.

We also help teams set up testing workflows for edge cases, role permissions, transaction flows, and contract-related features. For projects that need deeper blockchain security review, MOR Software can work with your team and external audit partners to prepare code, fix issues, and support post-audit changes.

This helps businesses move from ‘it works in testing’ to a safer production-ready system, with clearer logic, better checks, and fewer hidden risks before users and funds are involved.

Conclusion

Smart contract vulnerabilities can turn a strong Web3 idea into a risky product if teams skip secure design, testing, and review. The safest path starts before deployment, with clear logic, strict access rules, trusted data flows, and careful contract checks. 

MOR Software helps businesses build blockchain and Web3 products with safer engineering, QA testing, integration support, and maintenance. Contact us to discuss your project and reduce hidden contract risks before launch.