Submitted by hyh, also found by danb, kirk-baird, and pmerkleplant
Any native funds mistakenly sent along with plain ERC20 bridging calls will be lost. AnyswapFacet, CBridgeFacet, HopFacet and NXTPFacet have this issue.
For instance, swapping function might use native tokens, but the functions whose purpose is bridging solely have no use of native funds, so any mistakenly sent native funds to be frozen on the contract balance.
Placing the severity to be medium as in combination with other issues there is a possibility for user funds to be frozen for an extended period of time (if WithdrawFacets issue plays out) or even lost (if LibSwaps swap native tokens one also be triggered).
In other words, the vulnerability is also a wider attack surface enabler as it can bring in the user funds to the contract balance.
Medium despite the fund loss possibility as the native funds in question here are mistakenly sent only, so the probability is lower compared to direct leakage issues.
startBridgeTokensViaAnyswap doesnt check that msg.value is zero:
AnyswapFacet.sol#L38-L48
startBridgeTokensViaCBridge also have no such check:
CBridgeFacet.sol#L59-L66
startBridgeTokensViaHop the same:
HopFacet.sol#L66-L71
In NXTPFacet completion function does the check, but startBridgeTokensViaNXTP doesnt:
NXTPFacet.sol#L54-L59
Consider reverting when bridging functions with non-native target are called with non-zero native amount added.
H3xept (Li.Fi) commented:
gzeon (judge) commented:
