Closed code423n4 closed 1 year ago
This will not prevent user from getting the bridged funds, but will only prevent users from getting additional funds.
This feels like more of a value leak than a fund compromise
This is actually a false positive, swapExactIn()
will actually transfer the asset directly to msg.sender
. This was highlighted in the subsequent Spearbit audit as an incorrect fix.
Lines of code
https://github.com/code-423n4/2022-06-connext/blob/b4532655071566b33c41eac46e75be29b4a381ed/contracts/contracts/core/connext/helpers/SponsorVault.sol#L187-L220
Vulnerability details
Impact
The logic of
reimburseLiquidityFees()
is wrong and for some cases it doesn't transfersponsoredFee
tomsg.sender
. (whenaddress(tokenExchanges[_token]) != address(0)
) so any logic inConnext
callingreimburseLiquidityFees()
would be wrong too._handleExecuteTransaction()
inBridgeFacet
calls it.Proof of Concept
This is
reimburseLiquidityFees()
code inSponserVault
:As you can see when the
IF
condition isTrue
contract swaps amounts but id doesn't transfer tokens tomsg.sender
. the real bug is that transfer logic is written inside theelse
but it should be afterif/else
. so for tokens thataddress(tokenExchanges[_token]) != address(0
is true contract won't transfersponsoredFee
and any logic that uses this function would have this bug which is_handleExecuteTransaction()
andexecute()
inBridgeFacet
. users won't receive some of their funds.Tools Used
VIM
Recommended Mitigation Steps
fix the logic and transfer funds after
if/else