The lack of authorization control in the fallback function allows anyone to access and execute the fallback handlers. Depending on the fallback handler his can result in unauthorized transactions, data manipulation, or other unintended behaviours, potentially compromising the security and integrity of the smart account.
An attacker sends a transaction to the ModuleManager
contract with arbitrary data.
The fallback function is triggered due to the unrecognized function selector.
The fallback function routes the call to the corresponding fallback handler without verifying the sender's authorization.
The fallback handler executes the call, potentially leading to unauthorized actions.
Implement proper authorization control in the fallback function to ensure that only authorized entities can invoke it. This can be achieved by adding a modifier to check the sender's authorization before routing the call to the fallback handler. The existing onlyEntryPointOrSelf modifier could be used or an new modifier also including executorModuls might be appropriate.
There is indeed no access control within `fallback()` function which violates ERC7579 spec but the impact shown by all issues is insufficient. Need a better impact description/PoC that exceeds violation of ERC7579 to raise the severity of this issue. There will likely be no exploit for staticcall types, given there is not [state change/funds transfer allowed](https://www.rareskills.io/post/solidity-staticcall), so the possible vulnerability would be in the `CALLTYPE_SINGLE`. If no sufficient proof is provided to show a possible exploit, I will likely invalidate these issues.
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.