Root + Impact

Description

• Normal behaviour

  The owner may call setAllowedSellToken(token, false) to block a token that is no longer deemed safe or desirable.
  The intuitive expectation is that no further trades involving that token should be possible.

• Specific issue

  buyOrder never checks the allowedSellToken mapping.
  If a sell order was created while the token was allowed, that order remains fillable even after the owner later sets the token to false. Consequently, the supposedly-blocked asset can still change hands via the orders already sitting in the orderbook.

Risk

Likelihood: Medium

• Reason: Requires the owner to disable a token after orders already exist.

Impact: High

• Impact: Defeats the admin’s intention to halt trading (e.g., in an emergency),
  potentially exposing users to a compromised, risky or depreciated asset.

  
  

Proof of Concept

In the proof-of-concept, the owner first enables a previously unsupported ERC-20 by calling setAllowedSellToken(token, true). While the token is permitted, a seller creates a normal sell order for it. Next, the owner decides the asset is unsafe and disables it with setAllowedSellToken(token, false), intending to freeze all trading. Despite this change, any buyer can still execute buyOrder(orderId) and the transaction completes without error, because buyOrder never consults the allowedSellToken mapping. The order is filled, fees are collected, and the supposedly banned token changes hands—proving that disabling a token does not actually stop existing orders from being bought.

Recommended Mitigation

Add a guard at the start of buyOrder