# Shelter claimed mapping is set with _to address and not msg.sender

Shelter.withdraw updates the claimed mapping with the _to address instead of msg.sender, letting any small-share user repeatedly withdraw and drain all funds.

- Payout: Audit contest
- Severity: high
- Program: Concur Finance
- Found by: 0xliumin
- Disclosed: 2022-05-24
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-02-concur-findings/issues/103
- Library page: https://bugbountylibrary.com/r/c4%3A2022-02-concur%3AH-07
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** Shelter.sol withdraw function (Solidity contract)
**Root cause:** The claimed mapping is keyed by the _to recipient address rather than msg.sender, so a caller can vary _to to bypass the claimed check and withdraw repeatedly.
**Steps:**
1. Obtain a small share of the shelter.
2. Call `withdraw(_to, ...)` repeatedly, changing `_to` each time so the `claimed[_to]` check never blocks.
3. Each call transfers funds to the chosen `_to`, draining the shelter balance.
**How found:** Code review of Shelter.withdraw noticed the claimed mapping was written with _to instead of msg.sender, meaning the guard could be bypassed by varying the recipient.
**Exploitation:** Attacker with a minimal share calls withdraw in a loop with distinct _to addresses; since claimed is recorded per _to, the guard never triggers and all shelter funds are transferred out.
**Insight:** When an anti-double-spend/claim guard is keyed on a user-supplied parameter (recipient) rather than the authenticated caller, the guard is trivially bypassed by varying that parameter; check which identity the mapping is keyed on.