Inheritable Smart Contract Wallet

Summary

The nonReentrant modifier uses incorrect transient storage slots, disabling reentrancy protection.

Finding Description

The modifier checks tload(1) but stores in slot 0, creating an unlocked state. this is the format from the transint-storage blog post referenced in the documentation

but the contract makes use of this

Malicious contracts can re-enter sendETH/sendERC20 before completion. This breaks the core security invariant of "secure distribution".

Impact Explanation

The impact of this vulnerability is high because it allows attackers to exploit reentrancy to drain funds from the contract. Functions like sendETH and sendERC20 are critical for transferring assets, and if they can be reentered, the contract's funds are at risk.

Likelihood Explanation

The likelihood of this vulnerability being exploited is high because it affects multiple critical functions. Any malicious contract that interacts with these functions could potentially exploit the reentrancy guard's ineffectiveness.

Recommendation

To fix this issue, the nonReentrant modifier should use consistent transient storage slots for both checking and setting the flag. Here is the corrected modifier: