Full Report
Cross chain bridging platforms require on-chain and off-chain components. For Ethereum, the common practice is emitting an event in the EVM, which will be processed off-chain. After the processing of the event is done, it can be sent to the destination chain. Of course, the event emission must be 100% correct for this to work. In Thorchain, if a transaction fails a refund is triggered. This is done by handling the failed contract call then emitting an event to acknowledge that the transfer happened. When the failure happens, it gets placed into a vault contract. The bug is that the TransferOut event is emitted for a successful transfer. When in reality, the rollback to the user should have occurred. This leads to funds being lost for the user. To fix the bug, the event should only be emitted when the transfer to the target is successful. Cross chain stuff is hard! Solidity error handling is also hard. Put this together and we have a lot of bugs I'm sure.
Analysis Summary
# Vulnerability: Incorrect Event Emission During Failed ETH Transfers in THORChain Router
## CVE Details
- **CVE ID:** Not Assigned (Identified via Code423n4 Security Audit)
- **CVSS Score:** 8.1 (Estimated based on High Risk label)
- **Severity:** High
- **CWE:** CWE-691: Insufficient Control Flow Management (Logic Error in Error Handling)
## Affected Systems
- **Products:** THORChain Cross-Chain Bridge
- **Versions:** Relevant to commit `e3fd3c75ff994dce50d6eb66eb290d467bd494f5`
- **Configurations:** Ethereum-based `THORChain_Router.sol` contract handling `transferOut` and `transferOutAndCall` functions involving ETH.
## Vulnerability Description
The vulnerability exists in the logic handling unsuccessful ETH transfers within the THORChain Router. When a `transferOut` or `transferOutAndCall` function is executed, it attempts to send funds to a destination. If the ETH transfer fails (for instance, if the recipient is a contract that rejects the transfer or exceeds gas limits), the protocol is designed to handle this failure.
However, the contract incorrectly emits a `TransferOut` event even when the underlying ETH transfer fails. THORChain’s off-chain observers rely on these EVM events to verify successful cross-chain operations. Because the event is emitted regardless of the transfer's success, the off-chain components are "falsely informed" that the transfer succeeded. The funds actually remain stuck in the vault/router, but the protocol records the transaction as completed, leading to a loss of funds for the user and a discrepancy in the protocol’s accounting.
## Exploitation
- **Status:** PoC available (detailed in audit findings); No reported exploitation in the wild.
- **Complexity:** Medium
- **Attack Vector:** Network (External interaction with the Smart Contract)
## Impact
- **Confidentiality:** None
- **Integrity:** High (Off-chain state becomes desynchronized from on-chain reality)
- **Availability:** High (User funds are essentially locked/lost as the system believes they were successfully delivered)
## Remediation
### Patches
- The issue was identified in the **2024-06-thorchain** audit contest. A fix involves wrapping the `TransferOut` event emission within a conditional check that confirms the success of the low-level call (e.g., `require(success)` or `if(success) { emit ... }`).
- **Official Repo Fix:** Users should refer to the latest version of `THORChain_Router.sol` where the `transferOut` logic has been refactored to ensure event atomicity with the transfer success.
### Workarounds
- There are no direct user-side workarounds. The protocol must update the smart contract logic to ensure off-chain observers receive accurate state updates.
## Detection
- **Indicators of Compromise:** Discrepancies between `TransferOut` events emitted by the Router contract and the actual balance changes of the recipient addresses.
- **Detection Methods:** Monitoring for failed transactions on-chain that still resulted in a `TransferOut` log emission. Tools like Tenderly or Etherscan can be used to audit historical failed calls to the Router.
## References
- **Audit Findings:** hxxps://github[.]com/code-423n4/2024-06-thorchain-findings/issues/17
- **Vulnerable Code Location:** hxxps://github[.]com/code-423n4/2024-06-thorchain/blob/e3fd3c75ff994dce50d6eb66eb290d467bd494f5/ethereum/contracts/THORChain_Router.sol#L196