Reentrancy Attack via Malicious ERC-20 Token During Sell Order Creation
The createSellOrder()
function allows users to create sell orders by transferring ERC-20 tokens into the contract. However, the function performs an external call to IERC20(_tokenToSell).safeTransferFrom()
before updating its internal state (orders[orderId]
assignment). This introduces a reentrancy vulnerability.
A malicious ERC-20 token can override its transferFrom()
function to include a callback to createSellOrder()
or another contract function that relies on the internal state. Since the orders[orderId]
storage is not written before the external call, reentrant calls can result in:
Order ID reuse, since _nextOrderId++
increments but the mapping isn't populated yet.
Double bookings, where multiple orders share the same ID or overwrite each other.
Denial of Service (DoS) by locking up the order creation logic through repeated reentrancy loops.
This violates the Checks-Effects-Interactions pattern, which is a best practice in Solidity to prevent such exploits.
Likelihood:
Can be triggered by anyone using a malicious ERC-20 token.
Requires minimal setup by attacker.
Impact:
Leads to broken order logic, overwritten data, inconsistent internal state.
May cause denial-of-service or fund loss through corrupted order mapping.
Malicious Token Contract (simplified):
This allows the attacker to recursively call createSellOrder()
while _nextOrderId
is incremented but orders[orderId]
is not yet written — leading to corrupted order data.
Apply the Checks-Effects-Interactions pattern:
Always update internal state before any external call (especially safeTransferFrom
or call()
).
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.