xanoutas/solidity-security-findings huggingface dataset:
user might not be able to recevie the refund gas fee
Audit: 2024-08-axelar-network-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/interchain-token-service/contracts/utils/GatewayCaller.sol#L51
https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/interchain-token-service/contracts/utils/GatewayCaller.sol#L61
https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/interchain-token-service/contracts/utils/GatewayCaller.sol#L101
https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/interchain-token-service/contracts/utils/GatewayCaller.sol#L113


# Vulnerability details

## Impact
In `GatewayCaller.callContract` and `GatewayCaller.callContractWithToken`, `tx.origin` is used to receive the refund gas fee. There are some case in L2 that the user might not be able to receive the refund gas fee.

## Proof of Concept
Take [GatewayCaller.callContractWithToken](https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/interchain-token-service/contracts/utils/GatewayCaller.sol#L35-L69)
```solidity
 35     function callContract(
 36         string calldata destinationChain,
 37         string calldata destinationAddress,
 38         bytes calldata payload,
 39         MetadataVersion metadataVersion,
 40         uint256 gasValue
 41     ) external payable override {
 42         if (gasValue > 0) {
 43             if (metadataVersion == MetadataVersion.CONTRACT_CALL) {
 44                 // slither-disable-next-line arbitrary-send-eth
 45                 gasService.payNativeGasForContractCall{ value: gasValue }(
		 ...
 51                     tx.origin <<<--- Here
 52                 );
 53             } else if (metadataVersion == MetadataVersion.EXPRESS_CALL) {
 54                 // slither-disable-next-line arbitrary-send-eth
 55                 gasService.payNativeGasForExpressCall{ value: gasValue }(
		 ...
 61                     tx.origin <<<--- Here
 62                 );
		 ...
 69     }
```

Quting for [tx.origin](https://docs.optimism.io/chain/differences):
>If the transaction is an L1 ⇒ L2 transaction triggered by a smart contract on L1, then tx.origin is set to the aliased address of the address that triggered the L1 ⇒ L2 transaction. Otherwise, this opcode behaves normally.

So please consider in a case that:
1. a `MESSAGE_TYPE_INTERCHAIN_TRANSFER` tx is bridge from ETH to OPTIMISM by optimism's bridge
2. after OPTIMISM receives the tx, it will calls [InterchainTokenService.interchainTransfer](https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/interchain-token-service/contracts/InterchainTokenService.sol#L454-L478)
3. in [InterchainTokenService._transmitInterchainTransfer](https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/interchain-token-service/contracts/InterchainTokenService.sol#L1148-L1
TokenHandler contact can't handle rebase token as expect.
Audit: 2024-08-axelar-network-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/interchain-token-service/contracts/TokenHandler.sol#L45-L79


# Vulnerability details

## Impact
Rebasing tokens are tokens that have each holder's balanceof() increase/decrease over time. If the balance of rebase token is increased, the incremental amount of token will be stuck in the contract, and if the balance is decreased, the last user might can't get his token back.
## Proof of Concept
As [TokenHandler.giveToken](https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/interchain-token-service/contracts/TokenHandler.sol#L45-L79) shows, the function use `amount` directly without future calculation. 
```solidity
 45     function giveToken(bytes32 tokenId, address to, uint256 amount) external payable returns (uint256, address) {
 46         address tokenManager = _create3Address(tokenId);
 47
 48         (uint256 tokenManagerType, address tokenAddress) = ITokenManagerProxy(tokenManager).getImplementationTypeAndTokenAddress();
 49
 50         /// @dev Track the flow amount being received via the message
 51         ITokenManager(tokenManager).addFlowIn(amount);
 52
 53         if (tokenManagerType == uint256(TokenManagerType.NATIVE_INTERCHAIN_TOKEN)) {
 54             _giveInterchainToken(tokenAddress, to, amount);
 55             return (amount, tokenAddress);
 56         }
 57
 58         if (tokenManagerType == uint256(TokenManagerType.MINT_BURN) || tokenManagerType == uint256(TokenManagerType.MINT_BURN_FROM)) {
 59             _mintToken(tokenManager, tokenAddress, to, amount);
 60             return (amount, tokenAddress);
 61         }
 62
 63         if (tokenManagerType == uint256(TokenManagerType.LOCK_UNLOCK)) {
 64             _transferTokenFrom(tokenAddress, tokenManager, to, amount);
 65             return (amount, tokenAddress);
 66         }
 67
 68         if (tokenManagerType == uint256(TokenManagerType.LOCK_UNLOCK_FEE)) {
 69             amount = _transferTokenFromWithFee(tokenAddress, tokenManager, to, amount);
 70             return (amount, tokenAddress);
 71         }
 72
 73         if (tokenManagerType == uint256(TokenManagerType.GATEWAY)) {
 74             _transferToken(tokenAddress, to, amount);
 75             return (amount, tokenAddress);
 76         }
 77
 78         revert UnsupportedTokenManagerType(tokenManagerType);
 79     }
```

## Tools Used
VS code
## Recommended Mitigation Steps


## Assessed type

ERC20
`BaseAmplifierGateway.isCommandExecuted` isn't correct
Audit: 2024-08-axelar-network-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/axelar-gmp-sdk-solidity/contracts/gateway/BaseAmplifierGateway.sol#L115-L117


# Vulnerability details

## Impact
`BaseAmplifierGateway.isCommandExecuted` isn't correct. 
Combining this function and `BaseAmplifierGateway.approveMessages`, a malicious signer can DOS `express execute operations` in some case.

## Proof of Concept
[BaseAmplifierGateway.isCommandExecuted](https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/axelar-gmp-sdk-solidity/contracts/gateway/BaseAmplifierGateway.sol#L115-L117) has two issues.
First it doesn't consistent with [BaseAmplifierGateway.isMessageExecuted](https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/axelar-gmp-sdk-solidity/contracts/gateway/BaseAmplifierGateway.sol#L75-L77)
```solidity
 75     function isMessageExecuted(string calldata sourceChain, string calldata messageId) external view returns (bool) {
 76         return _baseAmplifierGatewayStorage().messages[messageToCommandId(sourceChain, messageId)] == MESSAGE_EXECUTED; <<<--- check if message's state is MESSAGE_EXECUTED
 77     }
 ...
115     function isCommandExecuted(bytes32 commandId) public view override returns (bool) {
116         return _baseAmplifierGatewayStorage().messages[commandId] != MESSAGE_NONEXISTENT; <<<--- check if message's state is not MESSAGE_NONEXISTENT
117     }
```

Second, even though there are two states MESSAGE_EXECUTED and MESSAGE_NONEXISTENT defined, but there is another state `approved` as described in [BaseAmplifierGateway.sol#L15-L20](https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/axelar-gmp-sdk-solidity/contracts/gateway/BaseAmplifierGateway.sol#L15-L20). 
And Because `isCommandExecuted` is used by `express execute operations` like [expressExecute](https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/axelar-gmp-sdk-solidity/contracts/express/AxelarValuedExpressExecutable.sol#L131-L152) and [expressExecuteWithToken](https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/axelar-gmp-sdk-solidity/contracts/express/AxelarValuedExpressExecutable.sol#L154-L204), a malicious signer might abusing this function and [AxelarAmplifierGateway.approveMessages](https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/axelar-gmp-sdk-solidity/contracts/gateway/AxelarAmplifierGateway.sol#L80-L86) to DOS `express execute operations`

Please consider the following case:
1. Alice the malicious signer has enough weights for [BaseWeightedMultisig._validateSignatures](https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/axelar-gmp-sdk-solidity/contracts/governance/BaseWeightedMultisig.sol#L192-L234) to be successf
Insufficient Msg.Value Validation in Cross-Chain Gas Payment Functions
Audit: 2024-08-axelar-network-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/interchain-token-service/contracts/utils/GatewayCaller.sol#L35
https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/interchain-token-service/contracts/utils/GatewayCaller.sol#L81


# Vulnerability details

## Vulnerability Details

The `GatewayCaller` contract, responsible for facilitating cross-chain calls via the Axelar network, contains a critical vulnerability in its gas payment logic. Both `callContract` and `callContractWithToken` functions allow users to specify a `gasValue` for cross-chain transactions but fail to validate that the provided `msg.value` is sufficient to cover this amount. This oversight can lead to failed transactions, potential loss of funds, and disruption of cross-chain communication.

## Code Snippets

https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/interchain-token-service/contracts/utils/GatewayCaller.sol#L35

https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/interchain-token-service/contracts/utils/GatewayCaller.sol#L81

```solidity
// In callContract function
if (gasValue > 0) {
    if (metadataVersion == MetadataVersion.CONTRACT_CALL) {
        gasService.payNativeGasForContractCall{ value: gasValue }(
            address(this),
            destinationChain,
            destinationAddress,
            payload,
            tx.origin
        );
    } else if (metadataVersion == MetadataVersion.EXPRESS_CALL) {
        gasService.payNativeGasForExpressCall{ value: gasValue }(
            address(this),
            destinationChain,
            destinationAddress,
            payload,
            tx.origin
        );
    } else {
        revert InvalidMetadataVersion(uint32(metadataVersion));
    }
}

// Similar structure in callContractWithToken function
```

The absence of a `require(msg.value >= gasValue)` check before the gas payment logic allows users to initiate cross-chain calls with insufficient funds. This can result in:

1. Silent failure of gas payments
2. Execution of `gateway.callContract` or `gateway.callContractWithToken` without proper gas allocation
3. Potential loss or stuck transactions on the destination chain

## Impact

1. **Failed Transactions**: Gas payment transactions will revert if `msg.value` is insufficient, wasting gas and potentially confusing users.
2. **Cross-Chain Message Disruption**: Messages may be sent to the destination chain without adequate gas, leading to stuck or dropped transactions.
3. **Broken Contract Invariants**: The implicit assumption that sufficient funds are provided for gas payments is violated, reducing contract reliability and predictability.
4. **Poor User Experience**: Users may believe their cross-chain calls were successful when they actually failed due to insufficient gas payment.
5. **Potential Fund L
Unbounded Token Decimals Enable Dust Attacks and Network Congestion
Audit: 2024-08-axelar-network-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/interchain-token-service/contracts/interchain-token/InterchainToken.sol#L86


# Vulnerability details

## Vulnerability Details
The `InterchainToken` contract's `init` function allows setting an arbitrary number of decimal places for the token without any validation. This lack of bounds checking on the `tokenDecimals` parameter creates a vulnerability that could be exploited to cause significant issues within the ecosystem.

## Code Snippet

https://github.com/code-423n4/2024-08-axelar-network/blob/4572617124bed39add9025317d2c326acfef29f1/interchain-token-service/contracts/interchain-token/InterchainToken.sol#L86

```solidity
function init(bytes32 tokenId_, address minter, string calldata tokenName, string calldata tokenSymbol, uint8 tokenDecimals) external {
        if (_isInitialized()) revert AlreadyInitialized();

        _initialize();

        if (tokenId_ == bytes32(0)) revert TokenIdZero();
        if (bytes(tokenName).length == 0) revert TokenNameEmpty();
        if (bytes(tokenSymbol).length == 0) revert TokenSymbolEmpty();

        name = tokenName;
        symbol = tokenSymbol;
        decimals = tokenDecimals;
        tokenId = tokenId_;

        /**
         * @dev Set the token service as a minter to allow it to mint and burn tokens.
         * Also add the provided address as a minter. If `address(0)` was provided,
         * add it as a minter to allow anyone to easily check that no custom minter was set.
         */
        _addMinter(interchainTokenService_);
        _addMinter(minter);

        _setNameHash(tokenName);
    }
```

## Impact
1. Network Congestion: Tokens with extremely high decimal places can be used to execute dust attacks, flooding the network with tiny transactions and causing congestion.
2. Increased Gas Costs: Network congestion leads to higher gas prices, making transactions more expensive for all users.
3. Delayed Transactions: Legitimate transactions may be significantly delayed due to network congestion.
4. Denial of Service: In extreme cases, the network could become nearly unusable for regular transactions.
5. Precision Issues: Extremely high decimal values can lead to precision problems and potential overflows in calculations.
6. Interoperability Problems: Unusual decimal counts may cause issues when integrating with other DeFi protocols or exchanges.
7. User Confusion: Excessive precision can make token amounts difficult for users to understand and work with.

## Attack Scenario
1. An attacker creates a token with an extremely high number of decimals (e.g., 255).
2. The attacker then initiates a large number of transactions, sending tiny amounts of this token to numerous addresses.
3. These transactions, while involving negligible value, still consume network resources and require processing.
4. The network becomes congested, causing increased gas prices and transaction delays.
5. Regu
Loss of fund as Unused Msg.value and gasValue is not Returned to Caller
Audit: 2024-08-axelar-network-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-08-axelar-network/blob/main/interchain-token-service/contracts/InterchainTokenService.sol#L335


# Vulnerability details

## Impact
The lack of implementation to return unused msg.value in the deployInterchainToken function can lead to unintentional retention of funds within the contract. This could result to:

- Locked Funds: Users may inadvertently send excess Ether when invoking the function, leading to locked funds within the contract that are inaccessible to the user.
- User Frustration: Users may lose trust in the contract due to the unreturned Ether, causing a potential loss of reputation and credibility for the platform.
- Malicious actors might exploit the contract by calling the function with excessive msg.value, leading to unnecessary accumulation of funds within the contract creating balance imbalance.
## Proof of Concept
```solidity
    function deployInterchainToken(
        bytes32 salt,
        string calldata destinationChain,
        string memory name,
        string memory symbol,
        uint8 decimals,
        bytes memory minter,
        uint256 gasValue
>>>    ) external payable whenNotPaused returns (bytes32 tokenId) {
        address deployer = msg.sender;

        if (deployer == interchainTokenFactory) deployer = TOKEN_FACTORY_DEPLOYER;

        tokenId = interchainTokenId(deployer, salt);

        if (bytes(destinationChain).length == 0) {
            address tokenAddress = _deployInterchainToken(tokenId, minter, name, symbol, decimals);

            _deployTokenManager(tokenId, TokenManagerType.NATIVE_INTERCHAIN_TOKEN, abi.encode(minter, tokenAddress));
        } else {
            _deployRemoteInterchainToken(tokenId, name, symbol, decimals, minter, destinationChain, gasValue);
        }
    }
```
As provided in the code above the deployInterchainToken function from the InterchainTokenService contract is declared as payable, allowing it to accept Ether when called. However, there is no logic within the function to return any unused portion of the msg.value to the sender.
The problem in this implementation is that, when a user sends more Ether than required for the gasValue, the excess amount is not returned to the sender, resulting in a loss of funds for the user.
## Tools Used
Manual Review
## Recommended Mitigation Steps
As adjusted below protocol should ensure excess message value sent with the function call is validated and returned back to the caller to prevent complete fund loss to contract.
```solidity
    function deployInterchainToken(
        bytes32 salt,
        string calldata destinationChain,
        string memory name,
        string memory symbol,
        uint8 decimals,
        bytes memory minter,
        uint256 gasValue
    ) external payable whenNotPaused returns (bytes32 tokenId) {
        address deployer = msg.sender;

        if (deployer == interchainTokenFactory) deployer = TOKEN_FACTORY_DEPLOYER;

        tokenId = interchainTokenId(dep
Events can result in incorrect action being taken 
Audit: 2024-08-axelar-network-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-08-axelar-network/blob/c383cc0e51805357bca8741ec5d1568cacbff6cc/axelar-amplifier/contracts/axelarnet-gateway/src/contract/execute.rs#L61-L75


# Vulnerability details

### Description
Inside the `axelar-amplifier/axelarnet-gateway/execute` flow, outgoing messages are processed by calling `route_outgoing_messages`
```javascript
pub fn execute(
    deps: DepsMut,
    _: Env,
    info: MessageInfo,
    msg: ExecuteMsg,
) -> Result<Response, axelar_wasm_std::error::ContractError> {
//..Ommitted code 
        ExecuteMsg::RouteMessages(msgs) => {
            if info.sender == router.address {
->                execute::route_outgoing_messages(deps.storage, msgs)
                    .change_context(Error::RouteOutgoingMessages)
            } 
//..Ommitted code
}
```

Within this function, a batch of messages is processed and saved. If a message has already been processed, the function will not revert, Instead, it will skip saving the message again, as doing so would be redundant.

```javascript
pub(crate) fn save_outgoing_msg(
    storage: &mut dyn Storage,
    cc_id: CrossChainId,
    msg: Message,
) -> Result<(), Error> {
    let existing = OUTGOING_MESSAGES
        .may_load(storage, cc_id.clone())
        .map_err(Error::from)?;

    match existing {
        Some(MessageWithStatus {
            msg: existing_msg, ..
        }) if msg != existing_msg => Err(Error::MessageMismatch(msg.cc_id.clone())),
=>        Some(_) => Ok(()), // new message is identical, no need to store it
        None => OUTGOING_MESSAGES
            .save(
                storage,
                cc_id,
                &MessageWithStatus {
                    msg,
                    status: MessageStatus::Approved,
                },
            )
            .map_err(Error::from)?
            .then(Ok),
    }
}


```

After the batch of messages is saved and processed, an event will be triggered.

```javascript
pub(crate) fn route_outgoing_messages(
    store: &mut dyn Storage,
    msgs: Vec<Message>,
) -> Result<Response, Error> {
//..Ommitted code
->    Ok(Response::new().add_events(
        msgs.into_iter()
            .map(|msg| AxelarnetGatewayEvent::Routing { msg }.into()),
    ))
}
```
As we can see, when the `execute` function is called, `add_events` is invoked with the provided `msgs`. This means that previously processed messages will be included in a new event again. This also means that already processed messages that are not stored again will be included in this event. 

Since events are monitored and acted upon, a malicious user could repeatedly trigger events for already processed messages, resulting in redundant event generation and forcing relayers to repeatedly verify the status of each message before deciding whether to act on it.

This becomes unmanageable for the relayers, especially when dealing with large batches of messages where just one message has already been processed, forcing the relayers to fin
No check to ensure correct decimals are used
Audit: 2024-08-axelar-network-findings
Severity: MEDIUM

# Lines of code

https://github.com/code-423n4/2024-08-axelar-network/blob/c383cc0e51805357bca8741ec5d1568cacbff6cc/interchain-token-service/contracts/InterchainTokenService.sol#L1091-L1115


# Vulnerability details

### Description
According to the [README](https://code4rena.com/audits/2024-08-axelar-network#top), tokens with fewer than 6 decimals or more than 18 decimals are not supported. However, this restriction is not enforced in the codebase. Users can initialize tokens with any decimal value they choose. For example, in the `DeployInterchainToken` function:

```javascript
  function _deployInterchainToken(
        bytes32 tokenId,
        bytes memory minterBytes,
        string memory name,
        string memory symbol,
->        uint8 decimals
    ) internal returns (address tokenAddress) {
        bytes32 salt = _getInterchainTokenSalt(tokenId);

        address minter;
        if (bytes(minterBytes).length != 0) minter = minterBytes.toAddress();

        (bool success, bytes memory returnData) = interchainTokenDeployer.delegatecall(
            abi.encodeWithSelector(IInterchainTokenDeployer.deployInterchainToken.selector, salt, tokenId, minter, name, symbol, decimals)
        );
        if (!success) {
            revert InterchainTokenDeploymentFailed(returnData);
        }

        assembly {
            tokenAddress := mload(add(returnData, 0x20))
        }

        // slither-disable-next-line reentrancy-events
        emit InterchainTokenDeployed(tokenId, tokenAddress, minter, name, symbol, decimals);
    }
```

The `decimals` parameter is specified, but there is no validation to ensure that the token decimals are between 6 and 18.

### Recommendation
Implement a validation check to ensure that the `decimals` value is within the range of 6 to 18, as outlined in the README.


## Assessed type

Other