Solidity Vulnerability Glossary
A comprehensive reference to common smart contract security vulnerabilities. Each entry explains the vulnerability in plain language, shows vulnerable and safe code patterns, and references real-world exploits.
Reentrancy Attack
A reentrancy attack tricks a smart contract into making an external call before updating its own state, allowing an attacker to repeatedly drain funds in a recursive loop.
Read more →Integer Overflow / Underflow
Integer overflow and underflow occur when arithmetic operations exceed the maximum or minimum value a data type can hold, silently wrapping around to an unexpected value.
Read more →Access Control Vulnerability
Access control vulnerabilities occur when critical contract functions lack proper permission checks, allowing unauthorized users to call admin-only operations like minting, pausing, or upgrading contracts.
Read more →Flash Loan Attack
Flash loan attacks use uncollateralized loans borrowed and repaid within a single transaction to manipulate prices or exploit vulnerabilities — with millions of dollars at risk.
Read more →Front-Running / MEV
Front-running occurs when a miner or bot observes a pending transaction and inserts their own transaction ahead of it to profit — for example, by buying an asset before a large trade executes.
Read more →Delegatecall Vulnerability
The delegatecall opcode runs code from another contract in the caller's storage context. Misuse allows an attacker to overwrite critical storage slots — including ownership variables.
Read more →Oracle Manipulation
Oracle manipulation attacks feed false price data into a smart contract to trigger actions at artificially inflated or deflated prices — often combined with flash loans.
Read more →Signature Replay Attack
A signature replay attack reuses a valid cryptographic signature from one transaction or context to authorize another unintended transaction — often draining funds or bypassing authorization.
Read more →Unchecked Return Values
When a low-level call or external function fails silently and its return value is not checked, the contract may continue executing as if the operation succeeded — leading to lost funds or broken logic.
Read more →Self-Destruct Abuse
The selfdestruct opcode deletes a contract and forcibly sends its Ether balance to any address — even contracts not designed to receive it, breaking accounting assumptions.
Read more →Timestamp Dependence
Using block.timestamp for randomness or time-sensitive logic is unsafe because miners can manipulate timestamps within a ~15-second window to influence outcomes in their favor.
Read more →tx.origin Authentication
Using tx.origin for authentication instead of msg.sender allows phishing attacks where a malicious contract tricks a victim into authorizing transactions against their own contract.
Read more →Uninitialized Storage Pointer
Uninitialized storage pointers in Solidity can accidentally point to critical storage slots, allowing unintended overwrites of contract state — including ownership variables.
Read more →Denial of Service (DoS)
Denial of service vulnerabilities allow an attacker to permanently or temporarily break a contract's core functions — for example, by causing a required external call to always fail.
Read more →Proxy Storage Collision
Storage collisions in proxy contracts occur when the proxy and the implementation contract store variables at the same storage slot, causing one to silently overwrite the other.
Read more →