Inheritable Smart Contract Wallet

Summary

The InheritanceManager::nonReentrant modifier in the InheritanceManager contract incorrectly uses transient storage (tload(1) instead of the correct slot tload(0)), effectively rendering the reentrancy protection ineffective. This implementation mistake breaks the core security assumption of functions protected by this modifier, potentially making them vulnerable to future reentrancy attacks if the functions become publicly callable or ownership is compromised.

Vulnerability Details

The above code mistakenly checks tload(1) while setting and clearing the transient storage in slot 0. Because transient storage slot 1 is never written to, it always returns 0, causing the condition to never revert and thus never protecting the contract from reentrancy attacks as intended.

Impact

Currently, the functions protected by nonReentrant (sendETH, sendERC20, contractInteractions) have the onlyOwner access control modifier, significantly reducing immediate exploitability. Thus, the direct risk of reentrancy attacks by external attackers is currently minimal.

However, this incorrect modifier implementation significantly weakens the contract's security posture. If, in the future, developers introduce additional functionalities without strict access controls (for example, allowing beneficiaries or external parties to trigger token transfers or interactions), these functions would immediately become susceptible to severe reentrancy vulnerabilities, potentially leading to loss of user funds.

In short:

• Indirect risk to user funds: Funds could become at risk in the future.

• Reduced security assurance: The intended protection mechanism is entirely bypassed, providing no actual protection against reentrancy.

• Potential future high-risk vulnerability: Any later addition or changes could unknowingly introduce serious vulnerabilities due to the false sense of security provided by the incorrect modifier implementation.

Tools Used

• Manual Code Review

Recommendation

Immediately fix the implementation of nonReentrant by correctly referencing the transient storage slot 0:

Corrected Modifier Implementation

This correctly locks and unlocks the function execution within the same transaction, effectively preventing any form of reentrancy attack.