Lines of code

Vulnerability details

Impact

In the sendNative function of the AxelarDepositService contract, the wrappedToken address is treated as weth-like and the wrappedToken’s deposit function is called.
If the wrappedToken address is TokenType.External token and is not weth-like and the fallback function is implemented, the deposit function will execute successfully.

Considering that wrappedToken is not weth-like, and the fallback function is implemented, a malicious user sends some wrappedTokens to the AxelarDepositServiceProxy contract.
Later, when the user calls the sendNative function, the deposit function will send the user’s ETH to the wrappedToken contract, and then send the wrappedToken provided by the malicious user to the gateway. This will cause the user’s ETH to be lost.

#Proof of Concept

The following contract indicates that when the token implements the fallback function, the deposit function call will succeed

pragma solidity 0.8.9;

interface IWETH9 {
    function deposit() external payable;
    function withdraw(uint256 amount) external;
}

contract A{
    function sendNative(address token) external payable{
        IWETH9(token).deposit{value: msg.value }();
    }
}

contract token {
    fallback() external payable {}
}

Tools Used

None

Recommended Mitigation Steps

Consider adding a whitelist to the wrappedToken address. Only when wrappedToken is a whitelisted address, the sendNative functions are allowed to be called

The text was updated successfully, but these errors were encountered:

All reactions