Closed c4-bot-5 closed 4 months ago
GalloDaSballo marked the issue as insufficient quality report
GalloDaSballo marked the issue as remove high or low quality report
did you even read the OUT OF SCOPE section for this? Clearly stated that such scenario is not part of the scope and there for can be disqualified.
mark this as invalid and dismiss this submission.
GalloDaSballo marked the issue as duplicate of #212
GalloDaSballo marked the issue as sufficient quality report
trust1995 marked the issue as unsatisfactory: Insufficient quality
This one did not uncover the issue properly.
Lines of code
https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/TransferHub/TransferHelper.sol#L13-L28 https://github.com/code-423n4/2024-02-wise-lending/blob/79186b243d8553e66358c05497e5ccfd9488b5e2/contracts/TransferHub/TransferHelper.sol#L34-L52
Vulnerability details
The protocol have chosen to implement their own version of safeTransfers. The implementation is not compatible with tokens like USDT that will not revert in case of failed transfers as they are not checking the returned data of _callOptionalReturn in _safeTransfer or _safeTransferFrom.
Impact
USDT transfers could in reality fail but the logic will continue as they have passed.
Proof of Concept
All the use of transfers inside the protocol represents a risk as the logic will continue normally even if the transfer have failed making the impression that tokens have been sent to the protocol/from the protocol in case of deposits or borrowing but in actual no transactions have taking place, crediting wrong/false amounts in balances.
Tools Used
Manual Reivew
Recommended Mitigation Steps
Check the return value of _callOptionalReturn and revert the transaction if it returns false.
Assessed type
Token-Transfer