Solidity Security Vulnerabilities: A 2026 Guide

Solidity security vulnerabilities cause the majority of value lost in Web3. Because deployed contracts are immutable and hold assets directly, a single flaw can drain a protocol in one transaction. This guide covers the highest-impact classes of Solidity security vulnerabilities, from reentrancy to oracle manipulation, each with a real, audit-grade example and the detection and prevention practices that address it.

The vulnerability classes that matter

1. Reentrancy

Reentrancy occurs when an external call transfers control to an attacker contract before the caller updates its own state, allowing the attacker to re-enter the same function and repeat an action, such as a withdrawal. The July 2023 Curve incident showed this can even originate in the compiler: Vyper versions 0.2.15, 0.2.16, and 0.3.0 shipped a reentrancy lock that did not share a global slot across functions, enabling cross-function reentrancy. Attackers drained more than $61 million across affected pools, including Curve’s CRV/ETH, Alchemix’s alETH-ETH, JPEG’d’s pETH-ETH, and Metronome’s sETH-ETH, before whitehat hackers began recovering funds within days. Prevention: apply the checks-effects-interactions pattern, use a reentrancy guard, and never assume a lock modifier compiles to what you expect. And don’t lean on an AI agent to catch this for you when it writes the code. One study found reentrancy in 10 of 17 compilable contracts generated by Meta AI and in 9 of 19 generated by ChatGPT. It’ll write the order confidently wrong.

2. Access control and privileged-function errors

Access control failures were the single largest category of smart contract losses in 2024: the OWASP Smart Contract Top 10 ranks Improper Access Control first (SC01:2025), attributing $953.2 million of the $1.42 billion lost across 149 documented incidents to this class. They include functions missing an owner or role check, initializers that anyone can call, and admin keys with no timelock. A classic pattern is an unprotected initialize() call on an upgradeable contract, which allows an attacker to claim ownership after deployment. Prevention: gate privileged functions with explicit modifiers, initialize during deployment or behind an initializer guard, prefer role-based access control over a single owner, and place administrative actions behind a timelock and multisig.

3. Integer overflow, underflow, and unchecked math

Before Solidity 0.8, arithmetic wrapped silently. The 2018 batchOverflow bug in the Beauty Ecosystem Coin ERC-20 token (recorded as CVE-2018-10299, weakness class CWE-190) multiplied a recipient count by a huge value, causing overflow and minting an astronomical balance from nothing. Solidity 0.8 added built-in overflow checks, but the risk did not disappear: developers reintroduce it with unchecked blocks, low-level assembly, unsafe casts to smaller types, and off-by-one accounting. Prevention: keep arithmetic in checked mode, justify every unchecked block, and bound-test all casts and downcasts.

4. Oracle and price dependency

Protocols that read an asset price from a manipulable source can be tricked into mispricing collateral. In October 2022, a trader rapidly bought large quantities of the thinly traded MNGO token on the exchanges feeding the Mango Markets oracle, then used the artificially inflated value of those positions as collateral to withdraw over $110 million in digital assets, per the CFTC's charging documents. Chainalysis reported $403.2 million in losses across 41 oracle manipulation attacks in 2022 alone. Prevention: use time-weighted average prices, aggregate multiple independent feeds, add sanity bounds and staleness checks, and never use a spot price from a low-liquidity pool as a lending oracle.

5. Delegatecall and proxy-upgrade risks

delegatecall executes another contract’s code in the caller’s storage context, which is the foundation of upgradeable proxies and a rich source of bugs: storage-layout collisions, uninitialized implementations, and hijacked upgrade slots. Dedaub’s disclosure of the CPIMP attack showed the extreme case. Attackers front-ran uninitialized proxies and inserted a malicious middleman that forwarded calls to the real implementation while restoring itself in the implementation slot every transaction, staying invisible to block explorers. It affected proxies across protocols, including EtherFi, Pendle, and Orderly, exposing tens of millions of dollars in value. Prevention: Initialize atomically, validate storage layouts during upgrades, and continuously monitor implementation slots.

6. Improper input validation

Contracts that trust caller-supplied addresses, amounts, or calldata without validation expose themselves to arbitrary external calls, token approvals routed to attacker addresses, and unexpected reverts. Prevention: validate every external input, restrict which target addresses a contract is allowed to call, and be especially careful with any function that forwards arbitrary calldata.

7. Front-running and MEV exposure

Because the mempool is public, anyone can observe a pending transaction and place their own around it. This is the basis of Maximal Extractable Value (MEV): sandwich attacks on swaps, front-run liquidations, and stolen arbitrage. It is an ordering problem, not a code bug, but contract design decides how exposed you are. Prevention: enforce slippage limits and deadlines, use commit-reveal schemes for sensitive ordering, and route sensitive transactions through private relays where appropriate.

8. Signature and replay issues

Signature-based flows, such as permit approvals and meta-transactions, break when a signature can be replayed on another chain or reused after its intended action. Missing nonces, absent domain separators, and unbounded deadlines are the usual root causes, allowing an Externally Owned Account (EOA) authorization to be executed more than once. Prevention: follow EIP-712 typed data with a chain-specific domain separator, track a nonce per signer, and enforce deadlines.

9. Rounding and precision in accounting

Fixed-point math and integer division introduce rounding that attackers can compound. A common pattern is the vault-share inflation attack, in which a tiny initial deposit combined with a donated balance skews the share price, causing later depositors to receive zero shares. Prevention: round in the protocol’s favor, seed vaults with an initial deposit, and use virtual shares. This is exactly the kind of property where formal verification is valuable, applied to critical invariants such as share-to-asset monotonicity.

How Dedaub finds Solidity security vulnerabilities in deployed contracts

Most guides stop at source code. The harder problem is the contract already live onchain, often unverified, that your protocol interacts with. The Dedaub Security Suite starts at the bytecode level. Its decompiler lifts raw bytecode into a structured, Solidity-like representation, reconstructing function boundaries, storage layouts, control-flow graphs, and inferred Application Binary Interfaces (ABIs), achieving 99.98% coverage of deployed contracts across the EVM ecosystem. More than 100 proprietary algorithms then analyze control flow and cryptographic misuse, and flagged contracts are automatically fuzzed. This is how issues with dependencies and third-party contracts become visible even without the source code.

For detection at scale, DedaubQL lets teams query decoded onchain data (blocks, transactions, logs, and token ledgers) on an SQL foundation and express protocol-specific invariants that raise an alert only when something anomalous occurs.

Closing

Solidity security vulnerabilities are well understood in terms of categories, yet they keep draining protocols because a single missed check in immutable code is enough. Treat this list as a baseline for your reviews and threat models, pair pre-deployment audits with continuous onchain monitoring, and give the contracts you depend on the same scrutiny as your own.