stake.link

Summary

The WrappedTokenBridge::_buildCCIPMessage() method, responsible for preparing the message that is going to be sent with Chainlink CCIP, is using a hardcoded value for extraArgs parameter. This is explicitly advised against by the Chainlink CCIP documentation, as it may lead to the incompatibility with the future versions of CCIP.

Vulnerability Details

The WrappedTokenBridge::_buildCCIPMessage() method is implemented as follows:

The method uses a hardcoded value of Ox for the extraArgs parameter of Client.EVM2AnyMessage struct. This value is technically correct for now, as it sets the only member of Client.EVM2AnyMessage struct - gasLimit - to zero.

In the case of CCIP token transfer without data, zero is the correct value for gasLimit, as stated in the documentation.

However, the documentation also explicitly states here that the hardcoded value for extraArgs should never be used:

DO NOT HARDCODE EXTRAARGS
To simplify this example, extraArgs are hardcoded in the contract. For production deployments, make sure that extraArgs is mutable. This allows you to build it off-chain and pass it in a call to a function or store it in a variable that you can update on-demand. This makes extraArgs compatible with future CCIP upgrades.

If Chainlink releases the new version of EVMExtraArgs, the hardcoded value may become incompatible. As a result the core contract's funtionality - wstLINK transfer - will cease to work.

Impact

The WrappedTokenBridge can be incompatible with future versions of Chainlink CCIP.

Tools Used

Manual review

Recommendations

Follow the pattern used in RESDLTokenBridge.sol contract. Instead of using a hardcoded value, introduce the state variable extraArgs with a corresponding setter method in order to be able to update the extra arguments whenever needed.