Fill Hijacking

Fill Hijacking is a potential issue in cross-chain messaging when leveraging Across protocol's liquidity.

Description

In addition to simply transferring funds, the system enables cross-chain message passing (intent) based on Account Abstraction (AA), allowing actions to be executed on the destination chain. To facilitate this, a relayer unlocks a portion of the user's locked assets on the origin chain and deposits a portion into Across’s SpokePool. Once all claims are successfully processed, the SpokePool on the destination chain performs the fill through a specific contract, which includes logic for executing AA-based operations.

Several potential issues can arise during this process:

• If there are no restrictions on which relayers can perform fills.

• If restrictions prevent effective use of Across’s liquidity.

Assuming a simple scenario where a single relayer is responsible for all fills and pays the execution gas costs upfront (to be reimbursed later), the relayer might be required to fill over 400 ETH, as shown in the above example. While this is an extreme case, even for less valuable assets, it's unrealistic to expect a single relayer to hold every token a user may want on the destination chain.

To make the best use of Across’s liquidity, instead of a single relayer fulfilling all fills, the system could allow multiple relayers to each fulfill part of the fills—similar to the now-deprecated "partial fill" mechanism.

However, if multiple relayers can perform fills, the system must handle already-filled cases gracefully. In Across, an already-filled request causes a revert. Therefore, if the relayer calls the fill function as shown below and a fill has already been hijacked, a DoS scenario can occur where the AA execution fails.

for (uint256 i; i < length;) {
    // ...
    SPOKEPOOL.fillRelay({
        // ...
    });
    // ...
}

In such a case, an attacker can intercept a specific fill without any loss, receive a reward from the Across protocol, and cause the AA execution to fail. If the system doesn’t properly handle partially filled scenarios, relayers may waste gas due to missed off-chain checks, and users suffer because their intended actions never execute.

Mitigation

Designate a contract to execute the AA logic only for the fill of the 0th segment with an exclusiveRelayer.

Use a low-level call to handle already-filled fills in advance.

// SPDX-License-Identifier: UNLICENSED
pragma solidity ^0.8.13;

import {Test, console2} from "forge-std/Test.sol";

contract SpokePool {
    error RelayFilled();

    function fillRelay() public {
        // if (fillStatuses[relayHash] == uint256(FillStatus.Filled))
        revert RelayFilled();
    }
}

contract Toast is Test {
    function test() external {
        SpokePool SPOKEPOOL = new SpokePool();
        for(uint256 i = 0; i < 0x5; i++) {
            (bool success, bytes memory data) = address(SPOKEPOOL).call(abi.encodeWithSignature("fillRelay()"));
            if(!success) {
                if(bytes4(data) != 0x8f260c60) revert(); // keccak256("RelayFilled()")
            }
        }
    }
}

Recommendation

To utilize more liquidity from Across relayers, distribute a portion of the locked assets as fees not only through Across protocol rewards but also to relayers—similar to how it's done in The Compact.