Cheesy Brick Nightingale
Medium
Malicious users can steal more shares than approved by front-running allowance changes. Missing atomic allowance updates in _withdraw
functions across both LendingAssetVault.sol
and Autocompoundingpodlp.sol
allow malicious users to steal additional vault shares by front-running allowance changes, potentially draining users' approved shares.
In both LendingAssetVault.sol:178
([LendingAssetVault.sol#L176-L187](https://github.com/sherlock-audit/2025-01-peapods-finance/blob/main/contracts/contracts/LendingAssetVault.sol?plain=1#L176-L187)) and AutoCompoundingPodLp.sol:194
([AutoCompoundingPodLp.sol#L190-L201](https://github.com/sherlock-audit/2025-01-peapods-finance/blob/main/contracts/contracts/AutoCompoundingPodLp.sol?plain=1#L190-L201)), the _withdraw
function utilizes _spendAllowance
, which checks allowances after interest updates. However, this does not mitigate the classic ERC20 approval race condition.
- Owner must approve spender for X shares.
- Owner must attempt to change approval to Y shares.
- Functions
withdraw()
orredeem()
must be callable by spender.
No response
- Owner approves Spender for 100 shares.
- Owner attempts to reduce approval to 50 shares.
- Spender front-runs with
withdraw()
using original 100 share allowance. - Owner's transaction reduces "remaining" allowance to 50.
- Spender can now withdraw additional 50 shares.
- Total withdrawn: 150 shares vs intended 100.
Victims can lose additional vault shares beyond intended approvals. Given that shares represent underlying assets plus accrued interest across multiple vaults, losses could be substantial.
No response
- Implement
increaseAllowance
/decreaseAllowance
functions for atomic updates. - Replace direct approval changes with these safer functions.
Here is a sampe of ERC20 approval race conditions: 0xProject/0x-monorepo#850 to read through for more info.