# Allowance check always true in ERC5095 redeem

Illuminate ERC5095 redeem checks allowance against an uninitialized return variable (always 0), so anyone can redeem another user's principal without approval.

- Payout: Contest reward
- Severity: high
- Program: Illuminate
- Credited: Lambda
- Disclosed: 2022-08-23
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-06-illuminate-findings/issues/173
- Library page: https://bugbountylibrary.com/r/c4%3A2022-06-illuminate%3AH-04
- 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 redeem function
**Root cause:** The allowance check compares against `underlyingAmount`, a return variable that is 0 at that point, instead of `principalAmount`, so the check always passes.
**Steps:**
1. Locate `redeem` in the ERC5095 implementation.
2. Observe the check `allowance >= underlyingAmount` where `underlyingAmount` is an uninitialized return value (0).
3. Call `redeem` with another user's principal amount; no approval needed since check trivially passes.
**How found:** Code reading of the redeem function revealed the allowance comparison used the wrong variable (return param instead of principalAmount).
**Exploitation:** Any caller invokes redeem on behalf of a victim whose principal is held; the broken allowance check permits redemption without approval, letting the attacker redeem the victim's position.
**Insight:** When auditing allowance/approval checks, verify the compared variable is the actual spend amount and not an uninitialized return value or shadowed local that defaults to zero.