First Flight #9: Soulmate

Summary

Reentrancy attacks occur when external contract calls are followed by state changes, creating a window for the called contract to reenter the calling contract and modify the state before the first call is completed. Three different functions within the contracts Airdrop, Staking, and Vault has reentrancy due to external calls.

Vulnerability Details

Reentrancy in Airdrop::claim() Function:
External Calls: The function makes several external calls to the soulmateContract and loveToken contracts to calculate the number of days in a couple and the amount of tokens to distribute.

State Variables Written After Calls: The _claimedBy mapping is updated after the external calls, which could be manipulated by a reentrant call.

Impact: An attacker could repeatedly call the claim() function before the state update occurs, draining the airdropVault of tokens.

Reentrancy in Staking::claimRewards() Function:
External Calls: The function interacts with the soulmateContract to retrieve the soulmateId and updates the lastClaim mapping.

State Variables Written After Calls: The lastClaim mapping is updated after the external calls, which could be manipulated by a reentrant call.

Impact: An attacker could repeatedly call the claimRewards() function before the state update occurs, potentially altering the rewards distribution.

Reentrancy in Vault::initVault(ILoveToken,address) Function:
External Call: The function calls the initVault method on the loveToken contract.
State Variable Written After Call: The vaultInitialize variable is set to true after the external call, which could be manipulated by a reentrant call.

Impact: An attacker could repeatedly call the initVault function before the state update occurs, potentially causing the initialization process to be interrupted or repeated.

Tools Used

manual review

Recommendations

To mitigate these reentrancy vulnerabilities, you should follow the Checks-Effects-Interactions pattern, which suggests that you should make all external calls at the end of the function after all internal state changes have been made. Additionally, consider using the nonReentrant modifier provided by OpenZeppelin's ReentrancyGuard contract to prevent reentrancy attacks.