1. Reentrancy

This occurs when an external contract repeatedly calls back into the vulnerable contract before the previous execution is completed. This can drain funds if the contract updates balances after sending Ether.

1
pragma solidity ^0.8.0;
2

3
contract Reentrancy {
4
    mapping(address => uint) public balances;
5

6
    function deposit() external payable {
7
        balances[msg.sender] += msg.value;
8
    }
9

10
    function withdraw() external {
11
        require(balances[msg.sender] > 0, "No balance");
12
        (bool sent, ) = msg.sender.call{value: balances[msg.sender]}("");
13
        require(sent, "Failed to send Ether");
14
        balances[msg.sender] = 0;
15
    }
16
}

2. Ownership Takeover

If an initialization function is left unprotected, anyone can call it and take ownership of the contract, potentially allowing them to modify critical settings or withdraw funds.

1
contract Ownable {
2
    address public owner;
3

4
    function initialize() public {
5
        owner = msg.sender;
6
    }
7
}

3. Timestamp Dependence

Using block.timestamp for critical logic (such as randomness or time-based access) is risky because miners can slightly manipulate timestamps, leading to unfair advantages.

1
if (block.timestamp % 2 == 0) {
2
    // Winner!
3
}

4. Gas Limit and Loops

Unbounded loops can exceed the gas limit, causing transactions to fail. Attackers can exploit this to make a function unusable (e.g., preventing fund withdrawals).

1
address[] public users;
2

3
function rewardAll() public {
4
    for (uint i = 0; i < users.length; i++) {
5
        payable(users[i]).transfer(1 ether);
6
    }
7
}

5. Denial of Service (DoS) with Throw

If a contract depends on external calls that can fail (e.g., sending Ether), a single failing transaction can block the execution of a loop, disrupting functionality for others.

1
function payUsers(address[] calldata users) public {
2
    for (uint i = 0; i < users.length; i++) {
3
        require(payable(users[i]).send(1 ether));
4
    }
5
}

6. Transaction Ordering Dependence (TOD)

When contracts rely on transaction order, attackers can use front-running strategies (paying higher gas fees) to manipulate the outcome of auctions, trading, or other priority-based logic.

1
function bid() public payable {
2
    require(msg.value > currentBid, "Low bid");
3
    currentBidder = msg.sender;
4
    currentBid = msg.value;
5
}

7. Unchecked External Call

Not checking the return value of call() can lead to security risks. If a call fails but isn’t handled properly, the contract might continue execution with unexpected behavior.

1
address target = 0xAbC...;
2
(bool success, ) = target.call(abi.encodeWithSignature("foo()"));
3
// Not checking success

8. Unchecked Math (Pre-Solidity 0.8.x)

Older versions of Solidity did not include built-in overflow and underflow protection, leading to issues where uint values could wrap unexpectedly.

1
uint x = 0;
2
x -= 1; // wraps to 2^256 - 1

9. Unsafe Type Inference

Using var for variable declaration can result in unintended type inference, which might cause overflows or unintended behavior in mathematical operations.

1
var x = 0; // inferred as int, not uint

10. Implicit Visibility Level

Solidity functions default to public if no visibility modifier is specified. This can unintentionally expose internal functions, allowing unauthorized access.

1
function updateOwner() {
2
    owner = msg.sender;
3
}

1. Escrow Manipulation

Weak escrow logic can allow users to withdraw funds multiple times or before they should be able to, leading to unauthorized fund losses.

1
mapping(address => uint) public deposits;
2

3
function withdraw() public {
4
    require(deposits[msg.sender] > 0);
5
    payable(msg.sender).transfer(deposits[msg.sender]);
6
}

2. Token Supply Manipulation

If minting logic lacks proper access controls, anyone could increase the total supply of tokens, leading to inflation and loss of value.

1
function mint(address to, uint amount) public {
2
    balances[to] += amount;
3
    totalSupply += amount;
4
}

3. Kill-Switch Mechanism

Contracts with emergency stop functions or selfdestruct() can lead to centralized control or unexpected shutdowns, potentially causing financial loss.

1
function emergencyStop() public {
2
    require(msg.sender == owner);
3
    selfdestruct(payable(owner));
4
}

4. User Balance Manipulation

Allowing arbitrary balance updates without validation can let attackers increase their balance or decrease others’, leading to theft or disruption.

1
function setBalance(address user, uint amount) public {
2
    balances[user] = amount;
3
}

References

• Hacken - Blockchain Security Services
• Hacken Kalmar Smart Contract Audit Report (2021)
• OWASP Smart Contract Top 10