the unbounded approve function allows a front-running vulnerability due to setting unlimited allowance.

[code423n4]

Lines of code

https://github.com/code-423n4/2023-07-moonwell/blob/fced18035107a345c31c9a9497d0da09105df4df/src/core/MToken.sol#L159-L161

Vulnerability details

Impact

if approve() is called with a very high allowance, the spender can drain the owner's entire balance.

Proof of Concept

approve() allows setting an allowance to any arbitrary uint256 value, including type(uint).max. This effectively gives unlimited approval to the spender address.

A malicious actor could exploit this by:

User A approves Spender contract with approve(spender, uint256.max) Attacker sees this transaction in the mempool and quickly sends their own transaction with transferFrom(userA, attacker, 1000) Attacker's transaction will drain 1000 tokens from user A to the attacker. When user A's original approve transaction is mined, the approval will still be set to uint256.max allowing the attack to continue draining tokens.

Tools Used

Manual

Recommended Mitigation Steps

bound the approval amount

Assessed type

Other

[0xSorryNotSorry]

msg.sender is approving the address (spender) of his/her choice. No force can frontrun this tx as the logic mismatches..

Technically not valid.

[c4-pre-sort]

0xSorryNotSorry marked the issue as low quality report

[c4-judge]

alcueca marked the issue as unsatisfactory: Invalid