Compiled list of solidity vulnerabilities

Security in Solidity code plays a big part in the Ethereum eco system, here is a list of vulnerabilities I compiled from online resources, hopefully this would come in handy for fellow devs and auditors. The link is an interactive whiteboard, I will be updating it as I go.


@fasteater This is great!

Ideas for additions:

  • Replay attacks:

    • Vulnerability: Signed messages that are intended to be used once are reused in a malicious way.
    • Preventative: Replay protection by storing the hash of “spent” signed messages that may include contract address, function signature, the signer address, a nonce, and chain id (post-Istanbul, no way to check current chain id right now)
    • Note: Using the signatures themselves or hashes of the signatures rather than hashes of the messages for replay protection may open the contract up to replay attacks due to signature malleability:
  • Under DOS, it may be worth mentioning that a call or transfer to external address can cause the whole transaction to revert if the called function or fallback function in the external address’s contract reverts.


thanks Chris! Replay attack sounds sweeet, I will dig into these a bit more and add to the list!

1 Like

Nice Start Rick! Some more common mistakes/vulnerabilities include

  1. Using strict checks. Some people write conditions like if (this.balance == maxAmount) stop; Instead of strict checks, something more forgiving should be used like if (this.balance >= maxAmount) stop;.
  2. Allowing editing of a arbitrary index of an Array. Due to how Solidity work, there are only 2^256 storage slots and hence and Array of size 2^256 actually uses memory used by other variables as well. So, if you allow arbitrary modification of array, the attacker can use it to change other variables.
  3. Overshadowing of variables. Specially when inheriting. It’s not really a vulnerability and solidity compiler now warns when this happens iirc but I have seen plenty of contracts falling prey to this.

thanks for the input Mudit, good to see u here! :smile:


do you have any link I can read more about point 2? not sure if I understand it correctly. 1 and 3 are already included in the chart.

1 Like

I don’t know about any write ups that explain this vulnerability. Perhaps I’ll write something up over this weekend. Meanwhile, Sample code that shows this vulnerability is:

contract game {
    address owner;
    address[] players;
    constructor() public {
        players.length = uint256(0) - uint256(1);
    function claimPlayerSpot(uint256 _index) public {
        players[_index] = msg.sender;

Anyone can override the owner address using the claimPlayerSpot() in this code.


Ethernaut AlienCodex (part 2) uses this vulnerability.

@ylv-io wrote a community solution: