ArkProject: NFT Bridge

Summary

There is a logical inconsistency in the handling of the whitelist flag during contract initialization. If the whitelist flag is set to false by default, the initialize() function should explicitly set the whitelist flag to false to align with the intended contract design. Conversely, if the whitelist flag is intended to be true upon initialization, the initialize() function should ensure it is set to true. This issue could lead to improper flag settings during contract upgrades or reinitializations, potentially allowing unauthorized access or actions.

Vulnerability Details

If by design the whitelist enabled flag is set to false on initialization, the initialize() function should set the whitelist flag to false. This is because the contract is an upgradeable contract and the owner can change the whitelist flag to true at any time, When the contract is upgraded, and initialized again, the whitelist flag will remain true if it was set to true before the upgrade.

This violates the design of the contract, as the whitelist flag should be set to false on initialization.

On the other hand, if the whitelist flag is set to true on initialization, the initialize() function should set the whitelist flag to true, because on the first deployment, the whitelist flag will be set to false by default, and remain the same unless the owner changes it.

Locations:

• https://github.com/Cyfrin/2024-07-ark-project/blob/273b7b94986d3914d5ee737c99a59ec8728b1517/apps/blockchain/ethereum/src/Bridge.sol#L59C8-L60C52

Impact

The probability of this issue occurring is low, but the impact is high. If the whitelist flag is not correctly set during initialization, it could result in improper access control or authorization issues, especially after contract upgrades.

Tools Used

• Manual code review

Recommendations

• if the whitelist flag is set to false on initialization, set the whitelist flag to false in the initialize() function.