The implementation of collectCreationFee actually receives the funds on the FeeManager contract but doesn't give anything back in the event of an amount sent while fee is 0:
Nowhere in the call flow is there an automatic refund mechanism for the user here.
While it could be argued that the admin can call withdraw() for each user, this is still not a viable solution, whereas the solution is simple to implement
Impact
Funds are stuck, very often.
Case by case withdraw can be made by the admin, but the mistake can easily be avoided with a code fix.
threadmodeling
medium
The full
msg.value
Ether amount is sent to thefeeManager
without refund even when fee amount is zeroSummary
When calling
TitlesCore.createEdition
, there's acollectCreationFee()
function being called onfeeManager
.Whether the
feeAmount
there is zero or a certain amount: anymsg.value
from the user will always be fully sent to thefeeManager
without any refunds.Vulnerability Detail
On
TitlesCore.createEdition
, we reach the following line: TitlesCore.sol#L138The implementation of
collectCreationFee
actually receives the funds on theFeeManager
contract but doesn't give anything back in the event of an amount sent while fee is 0:Also, in the event of an excess sent, the exact
fee.amount
is forwarded but the excess stays stuck in theFeeManager
contract:Nowhere in the call flow is there an automatic refund mechanism for the user here.
While it could be argued that the admin can call
withdraw()
for each user, this is still not a viable solution, whereas the solution is simple to implementImpact
Funds are stuck, very often.
Case by case withdraw can be made by the admin, but the mistake can easily be avoided with a code fix.
Code Snippet
Tool used
Manual Review
Recommendation
Implement a function refunding the excess