Submitted by pep7siup, also found by 0xNirix (1, 2), TECHFUND-inc, Tigerfrake, 13u9, DigiSafe, federodes, Decap, waydou, EaglesSecurity, smaul, rscodes, willycode20, Gosho, 20centclub, Kaysoft, MrPotatoMagic, rbserver, 0xCiphky, and biakia
If the mintFee was lowered by the Art creator via updateArtSettings before the claim was executed, the msg.value from user would become larger than the updated value of mintFee. As the function does not validate msg.value and consumes the mintFee directly, the excess ETH sent by the user will not be refunded, causing a loss of funds for user.
If PhiFactory still holds positive ETH balance, a malicious user can exploit this by sending less msg.value than expected (or no ETH at all). This results in PhiFactorys ETH being used for the mintFee payment instead, causing a loss for the protocol.
This external call to this.merkleClaim forwards the mintFee value of ETH without validating it against msg.value.
Similarly, this external call to this.signatureClaim forwards the mintFee value of ETH without validating it against msg.value.
Although the merkleClaim and signatureClaim functions can process refunds, the claim function calls of these two functions externally (defined as external instead of public), results in the msg.value being overridden by the mintFee. As a result, the original msg.value sent to claim() remains unvalidated and become vulnerable to exploits.
Apply patch & run forge test -vvv --mt test_claim_exploit:
Result:
This confirms both cases where msg.value > mintFee and msg.value = 0 could be exploited, causing loss of funds for both users and the protocol.
Foundry test
Validate msg.value against mintFee to ensure the caller sent in the correct amount of ETH. Or, forward msg.value directly to subsequent claim process since the _processClaim will eventually handle the refund.
Payable
0xDjango (judge) decreased severity to Medium
ZaK3939 (Phi) confirmed
