Vulnerability: Funds Refunded From Celer Bridge Might Be Stolen
Severity: high

Description:
```\\nif (!router.withdraws(transferId)) {\\n    router.withdraw(\\_request, \\_sigs, \\_signers, \\_powers);\\n}\\n```\\n\\nFrom the point of view of the Celer bridge, the initial depositor of the tokens is the `SocketGateway`. As a consequence, the Celer contract transfers the tokens to be refunded to the gateway. The gateway is then in charge of forwarding the tokens to the initial depositor. To achieve this, it keeps a mapping of unique transfer IDs to depositor addresses. Once a refund is processed, the corresponding address in the mapping is reset to the zero address.\\nLooking at the `withdraw` function of the Celer pool, we see that for some tokens, it is possible that the reimbursement will not be processed directly, but only after some delay. From the gateway point of view, the reimbursement will be marked as successful, and the address of the original sender corresponding to this transfer ID will be reset to address(0).\\n```\\nif (delayThreshold > 0 && wdmsg.amount > delayThreshold) {\\n     _addDelayedTransfer(wdId, wdmsg.receiver, wdmsg.token, wdmsg. // <--- here\\n} else {\\n      _sendToken(wdmsg.receiver, wdmsg.token, wdmsg.\\n}\\n```\\n\\nIt is then the responsibility of the user, once the locking delay has passed, to call another function to claim the tokens. Unfortunately, in our case, this means that the funds will be sent back to the gateway contract and not to the original sender. Because the gateway implements `rescueEther`, and `rescueFunds` functions, the admin might be able to send the funds back to the user. However, this requires manual intervention and breaks the trustlessness assumptions of the system. Also, in that case, there is no easy way to trace back the original address of the sender, that corresponds to this refund.\\nHowever, there is an additional issue that might allow an attacker to steal some funds from the gateway. Indeed, when claiming the refund, if it is in ETH, the gateway will have some balance when the transaction completes. Any user can then call any function that consumes the gateway balance, such as the `swapAndBridge` from `CelerImpl`, to steal the refunded ETH. That is possible as the function relies on a user-provided amount as an input, and not on `msg.value`. Additionally, if the refund is an ERC-20, an attacker can steal the funds by calling `bridgeAfterSwap` or `swapAndBridge` from the `Stargate` or `Celer` routes with the right parameters.\\n```\\nfunction bridgeAfterSwap(\\n    uint256 amount,\\n    bytes calldata bridgeData\\n) external payable override {\\n    CelerBridgeData memory celerBridgeData = abi.decode(\\n        bridgeData,\\n        (CelerBridgeData)\\n    );\\n```\\n\\n```\\nfunction swapAndBridge(\\n    uint32 swapId,\\n    bytes calldata swapData,\\n    StargateBridgeDataNoToken calldata stargateBridgeData\\n```\\n\\nNote that this violates the security assumption: “The contracts are not supposed to hold any funds post-tx execution.”

Impact:

Recommended mitigation:
Make sure that `CelerImpl` supports also the delayed withdrawals functionality and that withdrawal requests are deleted only if the receiver has received the withdrawal in a single transaction.