# ERC5095 redeem/withdraw does not update allowances

ERC5095 redeem/withdraw checks allowance but never decrements it, letting an approved spender repeatedly burn the holder's tokens and redirect underlying to themselves.

- Payout: Contest reward
- Severity: high
- Program: Illuminate
- Credited: kenzo
- Disclosed: 2022-08-23
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-06-illuminate-findings/issues/245
- Library page: https://bugbountylibrary.com/r/c4%3A2022-06-illuminate%3AH-08
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** ERC5095 token redeem/withdraw functions
**Root cause:** redeem and withdraw verify _allowance[holder][msg.sender] >= underlyingAmount but never subtract the spent amount, and authRedeem also does not update allowances.
**Steps:**
1. Alice approves Mal via ERC5095 allowance for some amount.
2. Mal calls `redeem(underlyingAmount, holder=Alice, receiver=Mal)` (or withdraw) with underlyingAmount within the allowance.
3. Contract checks `_allowance[Alice][Mal] >= underlyingAmount` and passes.
4. Tokens are burned and underlying sent to Mal; allowance is unchanged.
5. Mal repeats the call until Alice's balance is drained.
**How found:** Code review of the ERC5095 allowance check: noticed the require compares allowance but no subtraction follows, and authRedeem likewise omits allowance updates.
**Exploitation:** An approved spender repeatedly calls redeem/withdraw setting receiver to themselves; since allowance is never decremented, each call passes the check and drains the holder's full balance to the attacker.
**Insight:** When auditing ERC20-style approval flows, verify every spend path decrements allowance; wrapper tokens implementing ERC5095/ERC4626 often copy the check but forget the bookkeeping, and internal auth* helpers may also skip it.