Flow

Summary

The absence of reentrancy protection within functions that handle token withdrawals and deposits could allow an attacker to recursively reenter the contract during specific operations, enabling them to manipulate balances and potentially drain funds.

Vulnerability Details

Root Cause

The vulnerability arises from the lack of a reentrancy guard on critical functions that:

1. Handle token transfers.

2. Modify internal contract balances.

3. Adjust rates and metadata for streaming token flows.

Without a reentrancy guard, an attacker could recursively call these functions, allowing them to manipulate balances or token transfers before internal state updates are finalized.

Exploit Scenario

Scenario 1: Reentrant Withdrawals

An attacker could repeatedly call the withdraw function, withdrawing funds multiple times before the function completes. This would allow them to drain the contract’s token balance, as internal balances are updated only after the withdrawal transfer is completed.

Scenario 2: Recursive Deposits

Using a malicious contract as the token sender, an attacker could exploit the lack of reentrancy guard in deposit or depositViaBroker functions. They could reenter these functions to artificially inflate their balance in the contract or misrepresent their refundableAmount, allowing for future illicit withdrawals.

Impact

The reentrancy vulnerability in these functions exposes the contract to several high-severity risks:

• Total Loss of User Funds: Attackers could drain all funds held within the contract, impacting user balances and potentially leaving the contract insolvent.

• Inconsistent Balances: Manipulating balances within deposit and withdrawal functions could result in misrepresented internal states, causing users to receive incorrect balances or preventing legitimate withdrawals.

Tools Used

manual analysis

Recommendations

To mitigate this vulnerability, we recommend adding the nonReentrant modifier from OpenZeppelin’s ReentrancyGuard library to all external or public functions that interact with tokens or alter contract state. Specifically, the nonReentrant modifier should be applied to the following functions:

• withdraw, withdrawMax, deposit, depositAndPause, depositViaBroker, adjustRatePerSecond, refund, pause, and void.

Implementing reentrancy protection will prevent recursive calls, thereby preserving the contract’s internal state integrity and protecting user funds from unauthorized withdrawals or deposits.