Summary

Insecure Reentrancy Protection Using Transient Storage

Vulnerability Details

Insecure codeblock

Explanation

Why It’s Vulnerable

Mismatched Storage Slots:

1. The modifier checks slot 1 for the lock (tload(1)), but sets the lock in slot 0 (tstore(0, 1)).

2. Since slot 1 is never updated, the lock check (if tload(1)) always passes , rendering the guard useless.

Reentrancy Vector:

1. Functions like sendETH or contractInteractions can be re-entered during external calls (e.g., call{value: ...}), allowing attackers to drain funds.

2. Transient Storage can also be overwritten by a separate contract, causing unforeseen issues.

Impact

A successful reentrancy attack can lead to:

Fund Drainage: An attacker can repeatedly withdraw funds from the contract, exceeding the intended limits.

State Corruption: Critical state variables can be manipulated, leading to unpredictable behavior and potential denial-of-service.

Exploitation of Other Vulnerabilities: Reentrancy can be used as a stepping stone to exploit other vulnerabilities in the contract.

Tools Used

Note: This was discovered after researching using a variety of llms, and a search of online articles. As such I personally am not an expert in understanding memory slots

Recommendations

1. Use openzepplin reentrancy guard, instead of a custom modifier