Insufficient Recipient Validation:
The submitTransaction
function does not validate if the recipient address has a valid receive
or fallback
function, allowing transactions to be submitted that are guaranteed to fail.
Permanent Transaction Termination on Failure:
If _to
is a contract without a receive
or fallback
function, the .call
in executeTransaction
will revert, but the transaction is still marked as executed (though the state change is rolled back due to the require(success)
statement). However, users may incorrectly assume the transaction failed without understanding the funds remain trapped.
Funds Lock-Up: Users may inadvertently submit transactions to non-reolvable addresses, causing funds to be stuck in the multisig wallet.
User Confusion: Failed transactions are not clearly communicated, leading to frustration and loss of trust.
Slither for static analysis (identified unchecked external calls).
Validate Recipient Capabilities:
Implement a check in submitTransaction
to ensure the _to
address has a valid receive
or fallback
function.
Revert Invalid Transactions Early:
Modify submitTransaction
to revert if the recipient is invalid.
Include Error Handling:
Update the executeTransaction
error message to specify the transaction failed due to an invalid recipient.
Fixed Code Snippet:
By validating recipients and reverting invalid transactions, the multisig contract ensures safer fund management and clearer user feedback.
Please read the CodeHawks documentation to know which submissions are valid. If you disagree, provide a coded PoC and explain the real likelihood and the detailed impact on the mainnet without any supposition (if, it could, etc) to prove your point.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.