# Malicious Users Can Drain The Assets Of Auto Compound Vault

AutoPxGmx/AutoPxGlp vault's previewWithdraw rounds shares down to zero for small withdrawals, letting users withdraw assets without burning any shares.

- Payout: Contest reward
- Severity: high
- Program: Redacted Cartel
- Credited: xiaoming90
- Disclosed: 2023-01-27
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2022-11-redactedcartel-findings/issues/178
- Library page: https://bugbountylibrary.com/r/c4%3A2022-11-redactedcartel%3AH-03
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:accounting-error vuln:precision-loss

**Target:** ERC4626 auto-compound vault (AutoPxGmx/AutoPxGlp) withdraw path
**Root cause:** previewWithdraw uses convertToShares which mulDivDowns, so small asset amounts yield 0 shares; withdraw then burns 0 shares but still transfers assets.
**Steps:**
1. Vault state: totalAssets=1000 WETH, totalSupply=10 shares
2. Call `AutoPxGmx.withdraw(99 WETH, receiver, owner)`
3. previewWithdraw -> convertToShares: `99e18.mulDivDown(10, 1000e18)` = 0.99 -> 0
4. _burn(owner, 0) burns nothing
5. asset.safeTransfer(receiver, 99 WETH) pays out for free
6. Repeat to drain vault
**How found:** Code reading of ERC4626 convertToShares rounding direction; noticed previewWithdraw comment claims 'rounds up' but actually calls mulDivDown, then traced withdraw's burn/transfer to confirm free withdrawal.
**Exploitation:** Attacker with any share balance calls withdraw with an asset amount whose share conversion rounds to zero (assets < totalAssets/totalSupply), receiving assets while burning zero shares; loop to drain vault.
**Insight:** In ERC4626 forks, verify previewWithdraw rounds UP (mulDivUp) not down; a comment claiming rounding-up while code uses mulDivDown is a red flag—test tiny withdrawal amounts against large share price.