The Ultimate Guide to Solidity Attack Vectors: 30+ Security Risks Every Developer Must Know

Smart contracts may seem like the backbone of blockchain’s trustless promise, but they’re often riddled with potential attack vectors.

Whether you’re a developer, security researcher, or simply someone who wants to understand what makes Solidity tick (and break), this guide is your ultimate cheat sheet to identifying vulnerabilities.

Here’s a breakdown of attack vectors you should be aware of.

1. Arithmetic Over/Underflows

Arithmetic operations in Solidity can cause unexpected results when they exceed the range of a data type.

For example, subtracting 1 from 0 in an uint256 leads to a wrap-around, producing the maximum possible value (2^256 - 1). Attackers can exploit this behavior to manipulate token balances, bypass limits, or even trigger unintended contract logic.

While overflow/underflow checks are enforced in newer versions of Solidity, older contracts remain highly vulnerable to this exploit.

2. Assert Violations

The assert function in Solidity is used to validate critical assumptions that should never fail.

However, attackers can leverage unexpected edge cases or malformed input to trigger these violations.

When assert fails, it reverts the transaction, consuming all the gas sent along with it.

This could be exploited to create denial-of-service (DoS) scenarios, particularly in contracts where triggering an assert violation causes cascading effects in functionality.

3. Authorization via tx.origin

Contracts that use tx.origin for access control introduce a major security flaw.

The tx.origin global variable refers to the address that initiated the transaction, even if it passed through multiple intermediate contracts.

Attackers can trick users into executing malicious contracts, where the victim’s address is passed as tx.origin.

This bypasses the intended security mechanisms, granting unauthorized access to sensitive contract functions.

4. Block Timestamp Manipulation

The block.timestamp variable, which records the time of block creation, can be manipulated by miners within a small permissible range.

If a contract relies on timestamps for critical functions like randomness generation, staking rewards, or time-based access control, it becomes vulnerable.

For instance, a miner can manipulate the timestamp to claim an undeserved reward or disrupt the sequence of time-sensitive transactions.

5. Delegatecall Vulnerabilities

Delegatecall is a powerful feature in Solidity that allows one contract to execute another contract’s code in its own context, including access to its storage.

While useful, this can lead to severe vulnerabilities when improperly used.

A malicious callee contract could exploit the storage layout of the caller to manipulate data, steal funds, or corrupt critical contract state.

Even minor differences in storage layouts between the caller and callee could result in catastrophic outcomes.

6. Delegatecall to Untrusted Callee

Making a delegatecall to an unverified or malicious contract compounds the risks further.

In such cases, the callee can overwrite storage variables, such as ownership records or balances, leading to loss of control over the contract.

This is particularly problematic in upgradable proxy contracts, where the implementation contract is referenced via delegatecall.

Attackers can replace the implementation with a malicious one to take over the entire system.

7. DoS with (Unexpected) Revert

Unexpected reverts occur when an external contract deliberately fails an interaction.

For example, an attacker can deploy a contract whose fallback function always reverts, preventing a victim contract from completing a critical operation.

This is especially problematic in scenarios involving loops over arrays of addresses, as a single revert could block the execution of the entire function, effectively locking the contract or disrupting its workflow.

8. DoS with Block Gas Limit

Ethereum blocks have a gas limit, and contracts that process large arrays or data structures risk exceeding it.

Attackers can exploit this by deliberately inflating the data processed by a function, causing it to fail due to insufficient gas.

This can lead to a denial-of-service attack, where legitimate users are unable to interact with the contract.

Such issues are particularly prevalent in poorly designed token distribution mechanisms or auctions.

9. Encryption Protections

A common misconception in Solidity is that data stored on-chain is private or secure.

Contracts that implement encryption often mishandle keys or fail to understand that all data on-chain is inherently public.

Attackers can analyze the blockchain to extract encryption keys or other sensitive data, compromising the intended protections.

This flaw is particularly dangerous in applications requiring confidentiality, such as sealed-bid auctions or secret-sharing schemes.

10. Entropy Illusion

Generating randomness on-chain is notoriously difficult.

Using predictable variables like block.timestamp, block.number, or blockhash for randomness gives attackers or miners the ability to influence the outcome.

For example, in lotteries or games of chance, a miner could manipulate these values to ensure a favorable result.

This predictability undermines the fairness and security of randomness-dependent applications.

11. Flash Loan Exploits

Flash loans allow users to borrow substantial amounts of funds without collateral, provided the loan is repaid in the same transaction.

While legitimate use cases exist, flash loans have become a weapon of choice for attackers.

They exploit these loans to manipulate prices, drain liquidity pools, or exploit logic flaws in protocols.

Notable attacks include price oracle manipulation, draining funds via improperly secured lending protocols, or cascading liquidations in DeFi ecosystems.

12. Front Running

Front running occurs when an attacker intercepts and pre-empts a transaction in the mempool before it is mined.

By paying a higher gas fee, the attacker can prioritize their own transaction over the victim’s.

This is especially dangerous in DeFi protocols, where transactions like token swaps or arbitrage opportunities rely on specific price conditions.

Attackers can exploit this to manipulate markets, steal arbitrage opportunities, or disrupt critical operations by altering the expected order of transactions.

13. Floating Points and Numerical Precision

Solidity does not support floating-point numbers, and developers often rely on integers to represent fractional values by scaling them (e.g., using 1e18 for decimals).

However, calculations involving scaling are prone to rounding errors.

Attackers can exploit precision issues in financial contracts, such as exchanges or lending platforms, to siphon off small amounts of funds over time.

These seemingly negligible discrepancies can accumulate into significant losses.

15. Improper Library Implementation

Solidity allows developers to use libraries for reusable code, but improper implementation can lead to vulnerabilities.

Libraries that rely on delegatecall execute in the context of the calling contract, inheriting its storage and permissions.

If the library contains insecure code or is replaced by a malicious version, it can corrupt the contract’s storage, steal funds, or gain unauthorized access.

This makes ensuring the integrity and security of libraries a critical part of contract design.

16. Insufficient Gas Griefing

Gas is the fuel that powers the Ethereum Virtual Machine, and insufficient gas griefing exploits this fundamental mechanism.

Attackers can force a contract to consume an excessive amount of gas during execution, either by inflating the input data or triggering expensive operations.

This can lead to out-of-gas exceptions, denying service to legitimate users.

In cases where external calls are involved, attackers can deliberately provide less gas than required, disrupting the contract’s intended functionality.

17. Outdated Compiler Version

Using outdated versions of the Solidity compiler exposes contracts to known vulnerabilities that have been patched in newer releases.

Attackers often review old compiler versions to identify weaknesses, such as unchecked arithmetic, flawed optimizations, or insecure defaults.

Deploying contracts with an outdated compiler creates an unnecessary attack surface, leaving them vulnerable to exploits that could have been mitigated with an update.

18. Re-Entrancy

Re-entrancy occurs when a contract makes an external call to another contract, and the called contract re-enters the original contract before the initial execution is complete.

This exploit is commonly used to drain funds by repeatedly calling a vulnerable function before the contract can update its state.

A classic example is the infamous DAO hack, where the attacker manipulated a withdrawal function to recursively transfer funds without updating the contract’s balance.

19. Price Manipulation

Price manipulation exploits weaknesses in price oracle mechanisms.

Attackers can manipulate off-chain or on-chain oracles by influencing the data they provide, such as altering token prices in decentralized exchanges with low liquidity.

This attack is prevalent in DeFi protocols that rely on oracles for critical operations like liquidations, swaps, or collateral calculations.

By feeding false price data, attackers can trigger unintended liquidations, extract arbitrage profits, or destabilize protocols.

20. Shadowed State Variables

Shadowed state variables occur when a child contract declares a state variable with the same name as one in its parent contract, effectively overriding it.

This behavior can create unexpected outcomes when interacting with the contract, as the overridden variable in the parent contract remains accessible but becomes unused.

Attackers can exploit this to confuse users or developers, potentially introducing vulnerabilities that give the attacker control over the contract’s behavior.

21. Signature Replay Attacks

Signature replay attacks involve reusing a valid signature in a different context to perform unauthorized actions.

For example, if a contract accepts signed messages for approvals or actions, an attacker could reuse the same signature to repeat the action, such as transferring tokens multiple times.

This is especially problematic in systems where the signed message lacks sufficient context (e.g., expiration timestamps or unique identifiers) to differentiate between legitimate and replayed transactions.

22. Short Address/Parameter Attacks

Short address attacks exploit Ethereum’s lack of strict parameter validation during transaction encoding.

When a user submits a transaction with insufficiently padded input data, the EVM shifts the remaining parameters, altering their interpretation.

This misalignment can cause unexpected results, such as transferring tokens to the wrong address or executing unintended logic.

While modern Solidity versions mitigate this issue, contracts compiled with older versions may still be vulnerable.

23. State Variable Default Visibility

State variables in Solidity default to private visibility if not explicitly declared.

However, many developers mistakenly assume they are completely hidden from external actors.

In reality, blockchain data is transparent, and private variables can be read off-chain using tools like Etherscan or by querying the blockchain directly.

This misunderstanding can lead to over-reliance on default visibility, inadvertently exposing sensitive data such as keys, passwords, or internal states.

24. Unexpected Ether Balance

This occurs when a contract’s Ether balance changes unexpectedly due to external transfers or direct funding via mechanisms like selfdestruct.

If the contract’s logic assumes complete control over its balance (e.g., using the balance for conditional checks or state updates), an attacker can disrupt this logic by sending Ether to the contract without invoking its functions.

This can lead to unintended behavior, such as bypassing access control or causing failures in balance-dependent calculations.

25. Unprotected selfdestruct Instruction

The selfdestruct function allows a contract to remove itself from the blockchain and transfer its remaining Ether to a specified address.

If this function is exposed without proper restrictions, an attacker could trigger it and destroy the contract.

This not only results in loss of functionality but can also lead to unintended consequences, such as permanently locking funds in contracts that interact with the destroyed one.

26. Typographical Errors

Typographical errors, or typos, in smart contract code can introduce critical vulnerabilities.

A simple mistake, such as a misspelled variable name or function call, can lead to logic flaws, broken access control, or incorrect contract behavior.

For example, declaring a variable with an unintended scope or visibility modifier due to a typo can expose sensitive data or functionality.

These errors are especially dangerous because they often go unnoticed during audits or testing.

27. Bypass Contract Size Check

Some contracts impose size checks on other contracts they interact with to ensure legitimacy or compatibility.

However, attackers can bypass these checks by using a proxy or upgradeable contract pattern, which separates logic and storage into different contracts.

The proxy remains small, but its behavior is controlled by an external, larger logic contract, effectively bypassing the size constraint.

This can trick size-reliant validations and allow attackers to introduce malicious logic.

28. Divide Before Multiply

Division operations in Solidity truncate results for integers, which can lead to precision loss if division occurs before multiplication in a calculation.

Attackers can exploit this to create unintended behavior or inaccuracies in financial calculations, token distributions, or other critical operations.

For instance, using (x / y) * z instead of (x * z) / y may result in a significant loss of precision, especially when working with small numbers or fractional operations.

29. Public burn() Function

A poorly implemented burn() function that is publicly accessible and lacks proper restrictions can allow anyone to destroy tokens, even those owned by other users.

Attackers can exploit this to manipulate token supply, destroy competitors’ holdings, or disrupt the ecosystem of a token.

Without safeguards, such as verifying ownership or imposing access control, the burn() function becomes a critical point of failure.

30. Hiding Malicious Code in External Contracts

Attackers often hide malicious logic in external contracts that interact with the primary smart contract.

These external contracts may appear benign or serve legitimate purposes but execute harmful actions when called.

For instance, a seemingly safe library might contain backdoors that transfer funds, manipulate state variables, or disrupt execution flow.

Since external contracts can be updated or controlled by attackers, relying on them without thorough verification poses significant risks.

Final Thoughts

These attack vectors highlight the complexities of writing secure Solidity contracts.

A thorough understanding of these vulnerabilities is essential for developers to build robust and resilient applications.

While this list captures many common exploits, the evolving nature of the Web3 ecosystem means new attack vectors could emerge at any time.

Stay vigilant and keep learning, Web3 security is a journey, not a destination.