078.md

Bitter Honey Lion

Medium

Improper Management of ERC20 Allowance Residue Leading to Token Theft Risk

Summary: In the _tokenToPodLp function, when a DEX transaction fails, the allowance is not fully cleared, leaving a residue that can be maliciously exploited.

Detailed Description:

In the _tokenToPodLp function (code snippet L210-240), when DEX_ADAPTER.swapV3Single fails, only safeDecreaseAllowance is called to reduce the allowance, but it is not fully reset to 0. An attacker can exploit the residual allowance in subsequent transactions to transfer tokens.

Vulnerability: Insufficient Allowance Reset

Impact: An attacker can steal the balance of _rewardsToken in the contract, leading to user fund losses.

PoC:

// Attack steps: // 1. Trigger a DEX transaction failure (e.g., set maxSwap limit) address maliciousToken = pod.lpRewardsToken(); uint256 initialBalance = IERC20(maliciousToken).balanceOf(address(autoCompoundingPodLp));

// 2. Trigger allowance residue (partial allowance not cleared) vm.prank(owner); autoCompoundingPodLp.processAllRewardsTokensToPodLp(0, block.timestamp);

// 3. Exploit the residual allowance to transfer tokens uint256 remainingAllowance = IERC20(maliciousToken).allowance(address(autoCompoundingPodLp), address(DEX_ADAPTER)); if (remainingAllowance > 0) { vm.prank(attacker); DEX_ADAPTER.swapV3Single(maliciousToken, attackerToken, REWARDS_POOL_FEE, remainingAllowance, 0, attacker); }

Recommendation:

Use forceApprove to forcibly reset the allowance (reference 1):

Code snippet:https://github.com/sherlock-audit/2025-01-peapods-finance/blob/main/contracts/contracts/AutoCompoundingPodLp.sol#L210-240 // Fix code (replace safeDecreaseAllowance): IERC20(_rewardsToken).safeApprove(address(DEX_ADAPTER), 0);