Inheritable Smart Contract Wallet

Summary

In the contractInteractions function, state updates (such as storing the interaction details) are performed after executing an external call. This ordering violates the checks‑effects‑interactions pattern and increases the risk of reentrancy—especially given the flawed custom nonReentrant guard. As a result, an attacker could exploit the function to trigger reentrant calls before the state is updated, potentially leading to unexpected behavior or fund loss.

Vulnerability Details

The contractInteractions function allows the owner to make arbitrary external calls and, optionally, store the interaction details for transparency. However, if the external call reenters the function, the state (e.g., the mapping of stored interactions) is updated only after the external call returns. This delay creates a window during which the function’s state is inconsistent, allowing an attacker to reenter the function and manipulate behavior or extract funds multiple times. This risk is amplified by the fact that the custom nonReentrant guard in the contract is flawed due to mismatched storage slots.

Impact

Direct Impact: An attacker could exploit the reentrancy window to execute multiple external calls or to cause fund misallocation, leading to potential loss of assets.

Tools Used

Manual code review

Foundry (Forge) unit tests simulating reentrancy attacks

Recommendations

Reorder the Operations: Update the state (e.g., store the interaction data) before making the external call. This follows the checks‑effects‑interactions pattern and minimizes the reentrancy window.

Apply a Robust Reentrancy Guard: Replace the custom nonReentrant modifier with a battle-tested solution such as OpenZeppelin’s ReentrancyGuard.