Blog
HADESS
Cyber Security Magic

Smart Contract Security: Solidity Vulnerabilities, Reentrancy, and Auditing

Smart Contract Security: Solidity Vulnerabilities, Reentrancy, and Auditing

Part of the Cybersecurity Skills Guide — This article is one deep-dive in our complete guide series.

By HADESS Team | February 28, 2026 | Updated: February 28, 2026 | 5 min read

Smart contracts on Ethereum and EVM-compatible chains handle billions in assets. Solidity, the dominant smart contract language, has language-level features and EVM behaviors that create vulnerability classes not found in traditional software. A single bug can mean permanent, irreversible loss of funds.

Reentrancy

Reentrancy is the most historically significant smart contract vulnerability. It occurs when a contract calls an external address before updating its own state, allowing the external contract to re-enter the calling function.

solidity // Vulnerable function withdraw(uint amount) external { require(balances[msg.sender] >= amount); (bool success, ) = msg.sender.call{value: amount}(""); require(success); balances[msg.sender] -= amount; // State update AFTER external call }

// Fixed — checks-effects-interactions pattern function withdraw(uint amount) external { require(balances[msg.sender] >= amount); balances[msg.sender] -= amount; // State update BEFORE external call (bool success, ) = msg.sender.call{value: amount}(""); require(success); } `

Cross-function reentrancy occurs when the re-entrant call targets a different function that reads the stale state. Cross-contract reentrancy involves multiple contracts that share state. Read-only reentrancy exploits view functions that return incorrect values during reentrancy.

Use OpenZeppelin's ReentrancyGuard as defense in depth:

`solidity
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";

contract Vault is ReentrancyGuard { function withdraw(uint amount) external nonReentrant { // protected against reentrancy } } `

Flash Loan Vulnerabilities

Flash loans enable attackers to execute exploits that require large capital, all within a single transaction:

`solidity
// Vulnerable price oracle using spot price
function getPrice() public view returns (uint) {
return reserveA / reserveB; // Manipulable within a single tx
}
`

Defend against flash loan attacks by using time-weighted average prices (TWAPs) from oracles like Chainlink or Uniswap V3 TWAP. Never use spot prices from AMM reserves as the sole price source for lending, liquidation, or collateral valuation.

Common Solidity Vulnerabilities

Access control flaws — missing modifiers on privileged functions:

`solidity
// Vulnerable: anyone can call
function setPrice(uint newPrice) external {
price = newPrice;
}

// Fixed: restricted access function setPrice(uint newPrice) external onlyOwner { price = newPrice; } `

Integer overflow/underflow — Solidity 0.8+ includes built-in overflow checks. For older contracts, SafeMath was necessary. If you are auditing contracts compiled with Solidity < 0.8, check every arithmetic operation. Unchecked return values — low-level calls (call, delegatecall, send) return a boolean but do not revert on failure. Ignoring the return value means the contract continues as if the call succeeded.

Frontrunning — transactions in the mempool are visible before execution. Attackers can see a pending transaction and submit their own with higher gas to execute first. Commit-reveal schemes, private mempools (Flashbots Protect), and batch auctions mitigate this.

Delegatecall contextdelegatecall executes code in the context of the calling contract, including its storage layout. If the storage layouts do not match, state corruption occurs. This is the mechanism behind proxy upgrade vulnerabilities.

tx.origin authenticationtx.origin returns the original external caller, not the immediate caller. Contracts that check tx.origin for authentication are vulnerable to phishing attacks through intermediary contracts. Always use msg.sender.

Auditing Tools and Process

Static analysis:

  • Slither — fastest, catches common patterns, integrates with CI
  • Solhint — linting for code style and security rules

Dynamic analysis:

  • Foundry (forge test) — Solidity-native testing framework with fuzzing via forge fuzz`
  • Echidna — property-based fuzzer that tests contract invariants
  • Mythril — symbolic execution that explores all reachable states

Formal verification:

  • Certora Prover — verifies mathematical properties of contract behavior
  • Halmos — symbolic testing framework for Foundry

A thorough audit combines automated tools with manual review. Tools find known patterns; manual review finds business logic flaws, economic attacks, and protocol-level vulnerabilities that tools cannot model.

Related Career Paths

Smart contract auditing maps to the Security Researcher career path. Demand for auditors with Solidity expertise exceeds supply, especially for complex DeFi protocols.

Next Steps

Related Guides in This Series

Take the Next Step

Browse 80+ skills on HADESS. Go to the browse 80+ skills on hadess on HADESS.

See your certification roadmap. Check out the see your certification roadmap.

Get started freeCreate your HADESS account and access all career tools.

Frequently Asked Questions

How long does it take to learn this skill?

Most practitioners build working proficiency in 4-8 weeks of dedicated study with hands-on practice. Mastery takes longer and comes primarily through on-the-job experience.

Do I need certifications for this skill?

Certifications validate your knowledge to employers but are not strictly required. Hands-on experience and portfolio projects often carry more weight in technical interviews. Check the certification roadmap for relevant options.

What career paths use this skill?

Explore the career path explorer to see which roles require this skill and how it fits into different cybersecurity specializations.

HADESS Team consists of cybersecurity practitioners, hiring managers, and career strategists who have collectively spent 50+ years in the field.

Leave a Reply

Your email address will not be published. Required fields are marked *