xanoutas/solidity-security-findings huggingface dataset:
``  *_init  `` functions can be executed by anyone
Audit: 2024-08-chakra-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/handler/contracts/BaseSettlementHandler.sol#L1


# Vulnerability details


##  Description  +  Impact

``  TokenRoles :: __TokenRoles_init() `` is a `` public `` function without any authorization meaning that any address can execute it setting the `` owner  `` & `` operator `` of the `` ChakraToken `` contract that inherits `` TokenRoles ``

`` __TokenRoles_init() `` function has to be used as an `` internal `` function with ``onlyInitializing `` modifier because it is executed from `` initialize() `` 


This exact issue is seen in more instances like  `` BaseSettlementHandler :: _Settlement_handler_init() `` 



##  PoC


This issue is very simple to understand so a coded PoC will not make a difference. After the deployer executes `` ChakraToken :: initialize() `` that will execute ``  TokenRoles :: __TokenRoles_init() `` , any address can execute the function again with arbitrary values that will compromise the contract






## Assessed type

Other
Manipulation of cross-chain transaction status via unverified `from_chain` parameter
Audit: 2024-08-chakra-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/settlement/contracts/ChakraSettlement.sol#L265-L272
https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/handler/contracts/ChakraSettlementHandler.sol#L374-L376


# Vulnerability details

## Impact
The `ChakraSettlement::receive_cross_chain_callback()` function allows malicious actors to alter the `from_chain` parameter. This can result in the incorrect setting of cross-chain transaction statuses to `Failed`, causes:

1. `_erc20_burn()` is not called to burn tokens if the mode is `MintBurn`.
2. Violating the core invariant that cross-chain transaction statuses are properly tracked and updated:

> In Settlement Handler Contract: Cross-chain transaction statuses are properly tracked and updated (Pending, Settled, or Failed).

## Proof of Concept
The `from_chain` parameter is not verified by the validators:

```solidity
File: ChakraSettlement.sol
256:     function receive_cross_chain_callback(
257:         uint256 txid,
258:>>       string memory from_chain,
259:         uint256 from_handler,
260:         address to_handler,
261:         CrossChainMsgStatus status,
262:         uint8 sign_type,
263:         bytes calldata signatures
264:     ) external {
265:>>       verifySignature(
266:             txid,
267:             from_handler,
268:             to_handler,
269:             status,
270:             sign_type,
271:             signatures
272:         );
```

A malicious actor can front-run the callback transaction and change the `from_chain` parameter to an invalid value, leading to [the `ChakraSettlementHandler::is_valid_handler()` check to return false](https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/handler/contracts/ChakraSettlementHandler.sol#L374-L376). As a result, the call to [`to_handler.receive_cross_chain_callback()`](https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/settlement/contracts/ChakraSettlement.sol#L318) returns false unexpectedly.

## Tools Used
vscode

## Recommended Mitigation Steps
Include the `from_chain` parameter in the signature verification process.











## Assessed type

Invalid Validation
Mint / Burn mode is incorrectly handled
Audit: 2024-08-chakra-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/ChakraSettlementHandler.sol#L124


# Vulnerability details

## Impact

In the current implementation of `ChakraSettlementHandler`, there is a function `cross_chain_erc20_settlement()` that serves as entry point for user cross-chain transactions. There are also different settlement modes for token operations. The problem is that `MintBurn` mode is incorrectly handled as the tokens are first minted on the destination chain and not burnt on the source chain.

## Proof of Concept

Take a look at `cross_chain_erc20_settlement()` functionality:

https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/ChakraSettlementHandler.sol#L123-131
```
 if (mode == SettlementMode.MintBurn) {
            _erc20_lock(msg.sender, address(this), amount);
        } else if (mode == SettlementMode.LockUnlock) {
            _erc20_lock(msg.sender, address(this), amount);
        } else if (mode == SettlementMode.LockMint) {
            _erc20_lock(msg.sender, address(this), amount);
        } else if (mode == SettlementMode.BurnUnlock) {
            _erc20_burn(msg.sender, amount);
        }
```

As you can see, when the mode is `MintBurn`, the following function is called:

https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/ChakraSettlementHandler.sol#L244-246
```
function _erc20_lock(address from, address to, uint256 amount) internal {
        _safe_transfer_from(from, to, amount);
    }
```

So the tokens are just transferred to the contract imitating `LockUnlock` operation instead of burning tokens on the source chain and minting them on the destination chain:

https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/ChakraSettlementHandler.sol#L229-236
```
  function _erc20_burn(address account, uint256 amount) internal {
        require(
            IERC20(token).balanceOf(account) >= amount,
            "Insufficient balance"
        );

        IERC20Burn(token).burn_from(account, amount);
    }

```

https://github.com/code-423n4/2024-08-chakra/blob/main/solidity/handler/contracts/ChakraSettlementHandler.sol#L225-227
```
  function _erc20_mint(address account, uint256 amount) internal {
        IERC20Mint(token).mint_to(account, amount);
    }

```

This leads to a potential DoS or malicious minting as the message can be delivered on the destination chain and not burnt on the source chain if the `receive_cross_chain_callback()` fails, for instance. This would put the protocol in an undesired state when there are tokens minted on the destination chain but not minted on the source chain.

## Tools Used

Manual review.

## Recommended Mitigation Steps

Burn tokens first on the source chain and mint on the destination chain.


## Assessed type

Other
Users' assets remain permanently locked if cross-Chain message fails
Audit: 2024-08-chakra-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/handler/contracts/ChakraSettlementHandler.sol#L391-L393


# Vulnerability details

## Impact
When initiating a cross-chain ERC20 transfer, users' assets are transferred to the `ChakraSettlementHandler` contract and locked on the source chain:
```solidity
function cross_chain_erc20_settlement(
    string memory to_chain,
    uint256 to_handler,
    uint256 to_token,
    uint256 to,
    uint256 amount
) external {

    if (mode == SettlementMode.MintBurn) {
        _erc20_lock(msg.sender, address(this), amount);
    } else if (mode == SettlementMode.LockUnlock) {
        _erc20_lock(msg.sender, address(this), amount);
    } else if (mode == SettlementMode.LockMint) {
        _erc20_lock(msg.sender, address(this), amount);
    } else if (mode == SettlementMode.BurnUnlock) {
        _erc20_burn(msg.sender, amount);
    }
    // --SNIP

    emit CrossChainLocked(
        txid,
        msg.sender,
        to,
        chain,
        to_chain,
        address(this),
        to_token,
        amount,
        mode
    );
}
```
The cross-chain message is then transferred to the `ChakraSettlement` contract on the destination chain for processing. There is a chance for the cross-chain message to fail on the destination chain if the source handler is unwhitelisted:
```solidity
function receive_cross_chain_msg(
    uint256 txid,
    string memory from_chain,
     uint256 from_address,
    uint256 from_handler,
    address to_handler,
    PayloadType payload_type,
    bytes calldata payload,
    uint8 sign_type, // validators signature type /  multisig or bls sr25519
    bytes calldata signatures // signature array
) external {
    // --SNIP
    bool result = ISettlementHandler(to_handler).receive_cross_chain_msg(txid, from_chain, from_address, from_handler, payload_type, payload, sign_type, signatures);
    CrossChainMsgStatus status = CrossChainMsgStatus.Failed;
    if (result == true) {
        status = CrossChainMsgStatus.Success;
        receive_cross_txs[txid].status = CrossChainMsgStatus.Success;
    } else {
>>>        receive_cross_txs[txid].status = CrossChainMsgStatus.Failed;
    }

    emit CrossChainHandleResult(txid, status, contract_chain_name, from_chain, address(to_handler), from_handler, payload_type);
} 
```
```solidity
// ISettlementHandler(to_handler).receive_cross_chain_msg

function receive_cross_chain_msg(
    uint256 /**txid */,
    string memory from_chain,
    uint256 /**from_address */,
    uint256 from_handler,
    PayloadType payload_type,
    bytes calldata payload,
    uint8 /**sign type */,
    bytes calldata /**signaturs */
) external onlySettlement returns (bool) {
    //  from_handler need in whitelist
    if (is_valid_handler(from_chain, from_handler) == false) {
>>>        return false;
    }
    // --SNIP
}
```
If the cross-chain message fails, the `ChakraSettlement::receive_cross_chain_callback` function on
Missing `_disableInitializers()` call leaves implementation contract vulnerable to unauthorized initialization
Audit: 2024-08-chakra-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/handler/contracts/BaseSettlementHandler.sol#L18


# Vulnerability details


## Summary

The `BaseSettlementHandler` contract does not invoke the `_disableInitializers` function in its constructor. This omission exposes the implementation contract to unauthorized initialization, allowing potential attackers to gain control over the contract and disrupt its intended functionality.

## Impact

Without `_disableInitializers`, an attacker could initialize the implementation contract and take control over it. This vulnerability could be exploited to delegatecall a malicious contract containing a self-destruct opcode, which could destroy the implementation contract. Consequently, this action would permanently lock any assets within the proxy, rendering them inaccessible and causing significant financial loss and disruption of services.

## Recommendation

To mitigate this risk, it is recommended to include the `_disableInitializers()` call in the constructor of the `BaseSettlementHandler` contract. This measure will prevent unauthorized initialization by locking the implementation contract immediately upon deployment. By doing so, even if someone attempts to initialize the contract directly, they will be unable to gain ownership or execute critical functions, safeguarding the contract against potential attacks. 




## Assessed type

Upgradable
Potential deadlock in cross-chain messages Using `LockUnlock` or `BurnUnlock` settlement modes
Audit: 2024-08-chakra-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/handler/contracts/ChakraSettlementHandler.sol#L332-L335
https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/handler/contracts/ChakraSettlementHandler.sol#L345-L348


# Vulnerability details

## Impact
The protocol supports bridging both ERC20 tokens and Chakra tokens across chains using `ChakraHandlerSettlement::cross_chain_erc20_settlement`. When the `LockUnlock` or `BurnUnlock` settlement mode is employed, an equivalent amount of tokens is expected to be unlocked on the destination chain:

```solidity
function receive_cross_chain_msg(
    uint256 /**txid */,
    string memory from_chain,
    uint256 /**from_address */,
    uint256 from_handler,
    PayloadType payload_type,
    bytes calldata payload,
    uint8 /**sign type */,
    bytes calldata /**signaturs */
) external onlySettlement returns (bool) {
    // --SNIP
    if (mode == SettlementMode.MintBurn) {
        // --SNIP
    }else if (mode == SettlementMode.LockUnlock) {
        _erc20_unlock(
            AddressCast.to_address(transfer_payload.to),
            transfer_payload.amount
        );

        return true;
    } else if (mode == SettlementMode.LockMint) {
        // --SNIP
    } else if (mode == SettlementMode.BurnUnlock) {
        _erc20_unlock(
            AddressCast.to_address(transfer_payload.to),
            transfer_payload.amount
        );
        return true;
    }

    // --SNIP
        
}
```
On the destination chain, unlocking involves transferring the tokens from the handler contract to the recipient:
```solidity
function _erc20_unlock(address to, uint256 amount) internal {
    _safe_transfer(to, amount);
}

function _safe_transfer(address to, uint256 amount) internal {
    require(
        IERC20(token).balanceOf(address(this)) >= amount,
        "Insufficient balance"
    );

    // transfer tokens
>>>    IERC20(token).transfer(to, amount);
}
```

The problem is that there is no mechanism in place to ensure that the handler contract on the destination chain has a sufficient balance of the ERC20 tokens being transferred. If users initiate a cross-chain ERC20 transfer with a large amount on the source chain, and the handler contract on the destination chain lacks the necessary balance, the settlement process will **revert**, causing the cross-chain message to remain unresolved.

This scenario creates a **deadlock**: the cross-chain message is successfully sent from the source chain and the amounts are locked/burned on the source chain but can never be settled on the destination chain. Additionally, the source chain remains unaware of this failure because the `CrossChainHandleResult` event is not emitted on the destination chain's Settlement contract, preventing Chakra nodes from triggering the necessary callback on the source chain.

## Tools Used
Manual Review

## Recommended Mitigation Steps
Introdu
Reentrancy vulnerability in `receive_cross_chain_msg` during ERC-777 cross-chain transfers allows malicious users to drain the protocol
Audit: 2024-08-chakra-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/settlement/contracts/ChakraSettlement.sol#L170-L244


# Vulnerability details

## Impact
The protocol supports cross-chain transfers of ERC-777 tokens through `ChakraSettlementHandler::cross_chain_erc20_settlement`, ERC-777 tokens are ERC-20 tokens also and the process will go smoothly when calling `cross_chain_erc20_settlement`. When a cross-chain message is received on the destination chain, `ChakraSettlement::receive_cross_chain_msg` is invoked to handle the transfer. The function first verifies the signatures and ensures the transaction has not been previously processed before interacting with the handler contract to execute the transfer. Finally, it updates the transaction status:
```solidity
function receive_cross_chain_msg(
    uint256 txid,
    string memory from_chain,
     uint256 from_address,
    uint256 from_handler,
    address to_handler,
    PayloadType payload_type,
    bytes calldata payload,
    uint8 sign_type, // validators signature type /  multisig or bls sr25519
    bytes calldata signatures // signature array
) external {
    
    // --SNIP
    require(signature_verifier.verify(message_hash, signatures, sign_type),"Invalid signature");
    require(eceive_cross_txs[txid].status == CrossChainMsgStatus.Unknow,"Invalid transaction status");
>>>    bool result = ISettlementHandler(to_handler).receive_cross_chain_msg(
        txid,
        from_chain,
        from_address,
        from_handler,
        payload_type,
        payload,
        sign_type,
        signatures
    );

    CrossChainMsgStatus status = CrossChainMsgStatus.Failed;
>>>    if (result == true) {
        status = CrossChainMsgStatus.Success;
        receive_cross_txs[txid].status = CrossChainMsgStatus.Success;
    } else {
        receive_cross_txs[txid].status = CrossChainMsgStatus.Failed;
    }
}     
```
The function `ISettlementHandler(to_handler).receive_cross_chain_msg` is responsible for processing the token transfer and unlocking the tokens to the recipient:
```solidity
function receive_cross_chain_msg(
    uint256 /**txid */,
    string memory from_chain,
    uint256 /**from_address */,
    uint256 from_handler,
    PayloadType payload_type,
    bytes calldata payload,
    uint8 /**sign type */,
    bytes calldata /**signaturs */
) external onlySettlement returns (bool) {
    // --SNIP
    if (mode == SettlementMode.MintBurn) {
        // --SNIP
    }else if (mode == SettlementMode.LockUnlock) {
        _erc20_unlock(
            AddressCast.to_address(transfer_payload.to),
            transfer_payload.amount
        );

        return true;
    }

    // --SNIP
}
```
The vulnerability lies in the fact that this process is susceptible to reentrancy attacks when handling ERC-777 tokens. Specifically, a recipient implementing the `tokensReceived` hook can repeatedly re-enter `ChakraSettlement::receive_cross_chain_msg` as long as the han
Missing Refund Functionality for Failed Cross-Chain Transactions
Audit: 2024-08-chakra-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/handler/contracts/ChakraSettlementHandler.sol#L365


# Vulnerability details

## Impact

The settlement handler contract lacks a refund mechanism for users whose cross-chain transactions have failed. When a cross-chain transaction encounters an unexpected error and the status is marked as `Failed`, users are unable to withdraw their locked tokens, leading to loss of funds.

## Proof of Concept

If an error occurs during the cross-chain settlement process, for example, the handler of target chain does not have sufficient tokens to be unlocked, the `create_cross_txs[txid].status` is [set to `Failed`](https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/handler/contracts/ChakraSettlementHandler.sol#L391-L393).

However, the settlement handler does not provide a way for users to retrieve their tokens once a transaction is marked as `Failed`.

## Tools Used
vscode

## Recommended Mitigation Steps

Implement a refund function within the settlement handler contract that allows users to withdraw their locked tokens if their cross-chain transaction is marked as `Failed`.











## Assessed type

Other
Incorrect Event Parameter in `ChakraSettlementHandler::cross_chain_erc20_settlement()` Function
Audit: 2024-08-chakra-findings
Severity: HIGH

# Lines of code

https://github.com/code-423n4/2024-08-chakra/blob/abef77d95866f2fec93270491fc5abc9ab14f86d/solidity/handler/contracts/ChakraSettlementHandler.sol#L111-L223


# Vulnerability details

The `ChakraSettlementHandler::cross_chain_erc20_settlement()` function is responsible for sending cross-chain messages. However, there is a critical problem with the way the function emits the `CrossChainLocked` event. Specifically, the parameters passed to the event are incorrect, which can cause serious problems in tracking and processing cross-chain transactions.
In cross-chain projects, the accuracy of emitted events is as important as the correctness of the underlying logic. These events are often used to verify the integrity of cross-chain transactions, trigger actions in other contracts, or notify off-chain systems. Therefore, any discrepancy in the event data can lead to a chain reaction of errors that can jeopardize the entire cross-chain operation.
The relevant code snippet of the `ChakraSettlementHandler::cross_chain_erc20_settlement()` function is as follows:
```js
    // BaseSettlementHandler::CrossChainLocked()
    event CrossChainLocked(
        uint256 indexed txid,
        address indexed from,
        uint256 indexed to,
        string from_chain,
        string to_chain,
        address from_token,
        uint256 to_token,
        uint256 amount,
        SettlementMode mode
    );
    // ChakraSettlementHandler::cross_chain_erc20_settlement()
    function cross_chain_erc20_settlement(
        string memory to_chain,
        uint256 to_handler,
        uint256 to_token,
        uint256 to,
        uint256 amount
    ) external {
        require(amount > 0, "Amount must be greater than 0");
        require(to != 0, "Invalid to address");
        require(to_handler != 0, "Invalid to handler address");
        require(to_token != 0, "Invalid to token address");

        if (mode == SettlementMode.MintBurn) {
            _erc20_lock(msg.sender, address(this), amount);
        } else if (mode == SettlementMode.LockUnlock) {
            _erc20_lock(msg.sender, address(this), amount);
        } else if (mode == SettlementMode.LockMint) {
            _erc20_lock(msg.sender, address(this), amount);
        } else if (mode == SettlementMode.BurnUnlock) {
            _erc20_burn(msg.sender, amount);
        }
        // SNIP...

        emit CrossChainLocked(
            txid,
            msg.sender,
            to,
            chain,
            to_chain,
@>            address(this), // from_token
            to_token,
            amount,
            mode
        );
    }
```
Issues Identified:
Misplaced Parameters: The current contract address (address(this)) is incorrectly used as the from_token parameter. This should instead represent the actual ERC20 token address involved in the cross-chain transaction.

## Impact
The impact of this issue is significant because it undermines the reliability and accuracy of event logs, which are crucial