The current implementation inadvertently permits any user to register new collections in _whiteList
and collections
by withdrawing tokens that is transferred when _whiteListEnabled
is set to false
, despite the intended restriction to only allow the owner to manage these collections. This oversight will introduce a significant management efforts and security risk as well.
The system utilizes two key mechanisms for managing whitelisted collections: _whiteListEnabled
and _whiteList
. The _whiteListEnabled
flag determines whether the bridge is accessible for general NFT transfers or limited to whitelisted collections only. When _whiteListEnabled
flag is enabled, _whiteList
serves as a registry of collections' whitelist statuses.
A critical flaw emerges when collections are transferred through the bridge while _whiteListEnabled
is deactivated (false). During this period, newly withdrawn collections are added to both _collections
and _whiteList
, contrary to the intended design. This misconfiguration allows any user to indirectly influence the whitelist by withdrawing collections, leading to unauthorized collections being whitelisted within Bridge.sol
. This situation complicates the owner's ability to manage the whitelist effectively. Furthermore, the absence of a mechanism to remove entries from _collections
exacerbates the issue, as it leads to an overloaded whiteList
operation due to irrelevant collections.
Disabling _whiteListEnabled
temporarily renders the control over whitelist collections virtually impossible:
The bridge's management system becomes cluttered with numerous, unrelated collections, making it challenging to manage the whitelist efficiently.
Even after the owner meticulously reviews and adjusts the whitelisted collections, attackers can exploit the system by delaying withdrawals until _whiteListEnabled
is reactivated. This forces the owner into a continuous cycle of reviewing and correcting the whitelist, which is practically unfeasible.
Once _whiteListEnabled
is activated, managing whitelists will be practically impossible due to spams.
Manual
To address this vulnerability, the _whiteListCollection
call should be eliminated in withdrawTokens
. The management of collections
and _whiteList
should be strictly reserved for the owner, utilizing the whiteList
function.
Please, do not suppose impacts, think about the real impact of the bug and check the CodeHawks documentation to confirm: https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity A PoC always helps to understand the real impact possible.
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.