Summary

The Bridge::depositToken function in the Ark protocol fails to properly lock tokens during the deposit process. This vulnerability could lead to inconsistencies between the bridge's state and the actual token ownership, potentially disrupting the bridge's normal operation and compromising its integrity.

Vulnerability Details

The Bridge::depositToken function is intended to deposit tokens into the bridge for transfer to the L2 network. However, the function does not effectively lock the tokens in the Escrow contract as expected.

The issue stems from the following sequence of events through the test function below:

1. The bridge contract is given approval to transfer all tokens of a specific collection (e.g., erc721C1) from the user (e.g., Alice).

2. The Bridge::depositToken function internally calls Escrow::_depositIntoEscrow.

3. Escrow::_depositIntoEscrow attempts to transfer the tokens using IERC721(collection).transferFrom(msg.sender, address(this), id).

The problem arises because msg.sender in the context of _depositIntoEscrow is the bridge contract, not the original token owner. Although the bridge has approval to transfer tokens, it is not the owner, which may cause the transferFrom call to fail silently without reverting the transaction.

This is highlighted by the failing test testDeposit2TokensERC721WhitelistedAreNotEscrowed(), where the assertions checking if the tokens are escrowed return false instead of the expected true.

Assuming you have the right for Ark project and using Foundry, follow these steps:

In Escrow.sol contract, add this function at the end of the contract:

In Bridge.t.sol import Escrow contract:

Declare contract instance:

In setUp function add the following:

Copy and past the following test function:

Run this command: forge test --mt testDeposit2TokensERC721WhitelistedAreNotEscrowed -vv
You should get this output:

Impact

The impact of this vulnerability is severe:

• Inconsistent State: The bridge may believe it has locked tokens that are still under the control of the original owner, leading to a discrepancy between the bridge's state and the actual token ownership.

• Bridge Integrity: The core functionality of the bridge is compromised, as it cannot guarantee that tokens deposited for transfer to L2 are securely held.

Tools Used

Manual review - Foundry

Recommendations

Consider the following recommendation:
Direct Transfer: Instead of relying on transferFrom, implement a direct safeTransferFrom call in the Bridge::depositToken function: