Hash Collision

Overview

The hash collision detector identifies uses of abi.encodePacked with two or more dynamic-length arguments (strings, bytes, or dynamic arrays). Packed encoding concatenates values without length prefixes, so abi.encodePacked("ab", "c") and abi.encodePacked("a", "bc") produce the same output. When the result is hashed (e.g., for signatures, Merkle trees, or storage keys), distinct inputs map to the same hash — enabling collision attacks.

Why This Is an Issue

If a contract uses keccak256(abi.encodePacked(str1, str2)) for identity verification, access control, or Merkle proofs, an attacker can craft different input pairs that produce identical hashes. This can bypass authentication, forge Merkle proofs, or cause storage key collisions. The Solidity documentation explicitly warns against this pattern.

How to Resolve

// Before: Vulnerable — dynamic types in encodePacked
bytes32 hash = keccak256(abi.encodePacked(name, symbol));

// After: Fixed — use abi.encode (includes length prefixes)
bytes32 hash = keccak256(abi.encode(name, symbol));

Detection Methodology

EncodePacked identification: Detects calls to abi.encodePacked by identifying the corresponding ABI encoding pattern in bytecode (no length/offset headers).
Argument type analysis: Determines whether two or more consecutive arguments are dynamic types (strings, bytes, arrays).
Hash usage: Confirms the packed encoding result is passed to a hash function (KECCAK256).
Severity scoring: Higher severity when the hash is used for access control or Merkle verification.

Limitations

False positives: Uses of abi.encodePacked with a single dynamic argument or only fixed-size arguments are safe but may be flagged if argument types cannot be fully resolved. False negatives: Custom encoding routines that replicate packed behavior without using the built-in are not detected.

Signature Verification — detects improper signature hash construction
Access Control — detects missing authorization checks