The getOrderDetailsString
function is susceptible to a hash collision, during the encoding of order details variables making it vulnerable to hash collisions. As a result, different sets of input data may produce identical hashes.
The function constructs a human-readable string representation of an order's details by concatenating various order fields such as ID, seller, token amount, price, and status.
The use of abi.encodePacked()
with dynamic types (string
, toString()
results, etc.) omits structural metadata such as lengths or delimiters, relying purely on the concatenation of byte sequences. If any field values are unpredictable or attacker-controlled, the final string can become ambiguous or misleading.
Likelihood:
Arises when values of the concatenated fields (e.g., order.id
, status
, tokenSymbol
) can be manipulated or are dynamic.
Becomes high-risk when the details
string is used in any verification logic, logs for dispute resolution, or off-chain indexing.
Impact:
Ambiguity in data representation: Misleading or overlapping output when similar-looking inputs produce identical strings.
Its recommended to replace abi.encodePacked()
with abi.encode()
when hashing multiple dynamic types to avoid potential collisions and ensure consistency.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.