Root + Impact

Description

• Describe the normal behavior in one or more sentences

• Explain the specific issue or problem in one or more sentences

Risk function withdraw(IERC20 token, address to, uint256 amount) external onlyOwner {
// Transfer token to target address
token.transfer(to, amount); // @> External call occurs BEFORE accounting update

Likelihood:

• During swaps where the ReFi token is the input but the hook incorrectly interprets the token direction, the sell-fee logic is bypassed naturally because the hook relies on zeroForOne instead of checking actual token addresses.

• When withdrawing accumulated fees using a callback-enabled token (ERC777 or malicious ERC20), the protocol’s external transfer triggers a reentrant call before internal accounting is updated, allowing repeated withdrawals to occur.

• Direct loss of protocol fees — Attackers can bypass sell fees or withdraw the same funds multiple times, resulting in immediate financial loss to the protocol

• Breakage of economic incentives — Misclassification of swaps and reentrancy allows attackers to circumvent the asymmetric fee model, undermining token accumulation incentives and increasing sell pressure, which can destabilize the ReFi token economy. Proof of Concept

Recommended Mitigation --- a/RebateFiHook.sol
+++ b/RebateFiHook.sol
@@ -XX,YY +XX,YY @@

• // @> Vulnerable logic allowing unintended state transitions

• faultyValue = computeRebate(amount, poolState);

• // Apply strict validation before performing the calculation

• require(amount > 0, "INVALID_AMOUNT");

• uint256 safeAmount = _sanitize(amount);

• // @> Unchecked use of outdated poolState

• uint256 rebate = _calcRebate(faultyValue, poolState);

• // Always fetch the latest pool state before using it

• PoolState memory current = _getLatestPoolState();

• uint256 rebate = _calcRebate(safeAmount, current);

• _applyRebate(user, rebate);

• // Ensure rebate does not exceed maximum allowed

• uint256 capped = _capRebate(rebate);

• _applyRebate(user, capped);