Vulnerabilities

• Block Randomness

  In this article, we discuss the use of pseudorandomness which is not cryptographically secure, allowing prediction or manipulation by an attacker.

• Array Parameter Location

  In this article, we discuss how improperly specified array parameter locations can impact proper smart contract function execution.

• Multiple Constructors

  In this article, we discuss a vulnerability in an earlier version of the Solidity compiler that allowed multiple constructors with ambiguous results.

• Unsafe Self-destruct

  In this article, we discuss unsafe uses of the contract self-destruct functionality in Ethereum that may lead to inadvertent loss of deployed logic and data.

• Strict Ether Balance Check

  In this article, we discuss how strict checks on ether balances may lead to undesirable smart contract behavior and possible exploits by attackers.

• Expects Optional ERC-20 Functionality

  In this article, we discuss the possibility of unexpected function failures when attempting to use optional ERC-20 functionality that may not be present.

• Array Length Assignment

  In this article, we discuss the potential for unauthorized manipulation of smart contract storage data through a vulnerability related to length assignment of dynamically-sized arrays.

• Increasing Length Array as Loop Variable

  In this article, we discuss the possibility of loops that use increasing length arrays as control variables running out of gas during processing.

• Unchecked Block with Subtraction

  In this article, we discuss the risks associated with unchecked arithmetic that may lead to unintended value wrapping.

• Possible Division by Zero

  In this article, we discuss the possibility of divide-by-zero errors in cases where unchecked variables are used as divisors.

• Use of tx.origin

  In this article, we discuss potential risks associated with use of tx.origin where msg.sender might be more appropriate, particularly for authorizations.

• Locked Ether

  In this article, we discuss the Locked Ether vulnerability that can lead to ether becoming frozen in a smart contract and permanently inaccessible to users.

• Unary Plus Expression

  In this article, we discuss the possibility of unary plus operators leading to incorrect program calculations in older versions of Solidity.

• Missing Events on Price Change

  In this article, we discuss how missing events on a smart contract that allows for changing price data can adversely impact external services relying on the event log.

• Signed Integer Array

  In this article, we discuss a vulnerability in older versions of the Solidity compiler that could incorrectly record storage values for signed integer arrays.

• Calls in Loop

  In this article, we discuss the potential risks of denial-of-service when making external calls inside of a loop.

• Empty Payable Fallback

  In this article, we discuss the potential for confusion and improper accounting due to an empty payable fallback function in a smart contract designed to receive and handle ether.

• Shadowing State

  In this article, we discuss the possibility of inadvertent logical errors caused by locally shadowing a state variable.

• Call Without Gas Budget

  In this article, we discuss the possibility of external contracts consuming all forwarded gas if the called code is malicious or flawed.

• Required tx.origin

  In this article, we discuss dangerous uses of tx.origin which may lead to inadvertent contract behavior or unauthorized access to protected contract functionality.

• Zero as Parameter

  In this article, we discuss the possibility of literal zero values passed to function parameters inadvertently leading to logical program errors.

• Reused msg.value

  In this article, we discuss how use of msg.value in a loop may lead to faulty logic that allows attackers to reuse the same ether payment repeatedly.

• Directional Override Character

  In this article, we discuss how special Unicode characters can be used to craft malicious code that may be unwittingly inserted into smart contract projects.

• Shadowing Builtin Name

  In this article, we discuss the possibility of inadvertently shadowing builtin symbols, potentially leading to subtle logical errors in smart contracts.

• Potential Reentrancy

  In this article, we discuss how functions that can make external calls may be vulnerable to reentrancy attacks that exploit inconsistent smart contract state.

• Unchecked Low Level Call

  In this article, we discuss the possibility of low-level calls silently failing, leading to potentially incorrect program logic including accounting errors.

• Unused Return from Function Call

  In this article, we examine potential dangers from failing to use the return value from function calls, which may lead to unintended program executions.

• Arbitrary transferFrom

  In this article, we discuss the possibility of ERC-20 token theft due to unsafe calls to transferFrom().

• Owner as Single Point of Failure

  In this article, we discuss the potential risks of having functionality restricted to a single owner whose private key may be lost or compromised.

• Swapped Shift Parameters

  In this article, we discuss how improper use of assembly shift instructions can lead to incorrect calculations that can adversely affect smart contract logic.

• uint to int Conversion

  In this article, we discuss the possibility of unsigned-to-signed integer casts silently overflowing.

• abi.encodePacked with Dynamic Types

  In this article, we discuss the possibility of collisions in outputs of abi.encodePacked when multiple dynamic arguments are used.

• Arbitrary Address Spoofing Attack with ERC-2771 and Multicall

  In this article, we discuss the possibility of malign interaction between the ERC-2771 and Multicall standards allowing for address spoofing and potential theft of funds.

• Unchecked Token Transfer

  In this article, we discuss the possibility of token transfers failing without reverting, which may lead to improper settlement in DeFi applications.

• Unbounded Pragma

  In this article, we discuss how an unbounded pragma specification can lead to compilation errors in vulnerable Solidity files.

• Reentrancy Affecting Events Ordering

  In this article, we discuss the possibility of reentrant functions emitting events out-of-order in the transaction log, potentially affecting the behavior of external applications.

• Default Visibility

  In this article, we discuss the possibility of unspecified state variable visibility leading to unintended modifications of state by inheriting contracts.

• Unsafe Downcast

  In this article, we discuss the risk of possible bit truncation when making narrowing type casts, which may lead to unintended program behavior.

• No Parameter Validation in Constructor

  In this article, we discuss the possibility of deploying a contract in an undesired state by failing to check paramter values used in the contract's constructor.

• No Access Control on Payable Fallback

  In this article, we discuss the possibility of ether potentially becoming stuck for a user if a smart contract offers a payable fallback or receive function without controlling who may send ether to it.

• Uninitialized Local Storage

  In this article, we discuss the possibility of an uninitialized storage variable inadvertently overwriting existing contract storage in older versions of Solidity.

• Downcast of Number to Address

  In this article, we discuss how making narrowing downcasts of numeric to address types in earlier versions of Solidity may lead to logical errors and possible loss of funds.

• Missing Gap Variable

  In this article, we discuss the possibility of storage layout corruption due to failure to reserve space for upgrades when using OpenZeppelin's upgradeable contracts.

• Shadowing Reserved Keyword

  In this article, we discuss how using reserved keywords can cause compatibility issues in older Solidity versions where these were not disallowed by the compiler.

• Faulty Division Operation

  In this article, we discuss the potential for unintended consequences when using the division operation in complex arithmetic expressions in Solidity.

• Delegatecall in Loop

  In this article, we discuss how delegated calls in a loop that target functions using msg.value may lead to accounting errors.

• Same Named Contracts

  In this article, we discuss issues that may arise if contract names are reused in the same compilation unit.

• Struct with Mapping Deletion

  In this article, we discuss the possibility of mapping data associated with structs not being properly deleted, potentially leading to program logic errors.

• Unchecked Send

  In this article, we discuss the possibility of logical errors arising from silent failures to transfer ether using the builtin send function.

• abi.encode() with Nested Array

  In this article, we note the improper encoding of nested arrays in outdated versions of the Solidity compiler, which could lead to program logic errors.

• Enum Conversion Out of Range

  In this article, we discuss the possibility of program bugs due to casting out-of-range values to an enum type.

• Nested Struct in Mapping

  In this article we discuss the importance of avoiding old compilers with known bugs related to mappings containing nested structures.

• Unenforced State Maintenance Keywords

  In this article, we discuss how early versions of Solidity would not always enforce state maintenance keywords for functions, potentially leading to logic or compatibility issues.

• Uninitialized Function Pointer in Constructor

  In this article, we discuss the possibility of unexpected program behavior in older versions of Solidity when uninitialized function pointers were used in constructors.

• ERC-20 Interface

  In this article, we discuss the potential for smart contract interoperability issues that can be caused by failure to properly implement the ERC-20 token standard.

• ERC-721 Interface

  In this article, we discuss the possibility of logic failures or erroneous transactions if the ERC-721 specification is not adhered to.

• Uninitialized State Variable

  In this article, we discuss the possibility of uninitialized state variables inadvertently leading to logical errors in smart contracts.

• Unfuzzed State Variables

  This vulnerability occurs when state variables in a smart contract are not included in fuzz testing, potentially leaving unexplored edge cases or vulnerabilities.

• Signature Replay Attacks

  This vulnerability allows attackers to reuse valid signatures, potentially leading to unauthorized actions or fund transfers in smart contracts.

• Improper Diamond Pattern Implementation

  Improper implementation of the Diamond Pattern in smart contracts can lead to functionality issues, security vulnerabilities, and upgradeability failures.

• Unverified Parameters in Low-Level Calls

  This vulnerability allows potential exploitation through unverified parameters in low-level calls, risking unexpected behavior or unauthorized actions in smart contracts.

• Missing Revert Reason Tests in Test Functions

  Missing revert reason tests in smart contract test functions can lead to incomplete validation of error handling, potentially overlooking critical issues in contract logic.

• Insufficient Parameter Assertion

  This vulnerability arises when smart contract functions do not properly validate their input parameters, potentially leading to unexpected behavior or exploitation.

• Incomplete Constructor Tests in Test Functions

  Incomplete constructor tests in smart contract test functions can lead to missed initialization issues and potential vulnerabilities in the contract's initial state.

• Function Selector Clash

  Function selector clashes occur when different function signatures hash to the same four-byte selector, potentially causing incorrect function execution and security vulnerabilities.

• Missing Events Assertion in Test Functions

  Missing event assertions in smart contract test functions can lead to incomplete testing of contract behavior, potentially overlooking critical issues in event emissions.

• Unfuzzed Local Variables in Test Functions

  Unfuzzed local variables in smart contract test functions can lead to incomplete test coverage, potentially missing critical bugs or vulnerabilities.