# ConvexStakingWrapper, StakingRewards Wrong implementation will send concur rewards to the wrong receiver

ConvexStakingWrapper and StakingRewards call MasterChef.deposit/withdraw without a user param, so MasterChef credits the wrapper address and sends all pending CONCUR rewards to whoever triggers the call.

- Payout: Audit contest
- Severity: high
- Program: Concur Finance
- Found by: WatchPug
- Disclosed: 2022-05-24
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-02-concur-findings/issues/205
- Library page: https://bugbountylibrary.com/r/c4%3A2022-02-concur%3AH-04
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:accounting-error vuln:reward-distribution

**Target:** MasterChef / ConvexStakingWrapper / StakingRewards staking contracts
**Root cause:** MasterChef.deposit/withdraw use _msgSender() as the accounting user, but the caller is the wrapper contract, not the end user; all users share one userInfo entry and rewardDebt.
**Steps:**
1. Alice deposits 1,000,000 tokens via ConvexStakingWrapper.deposit(); MasterChef records userInfo[1][address(ConvexStakingWrapper)]=1,000,000
2. 1 day later Bob deposits 1 token via the same wrapper; MasterChef records userInfo[1][wrapper]=1,000,001
3. MasterChef computes pending = amount*accConcurPerShare/multiplier - rewardDebt and transfers all pending CONCUR to _recipient (Bob)
4. Alice's share of rewards is lost; Bob receives them
**How found:** Code reading: noticed MasterChef.deposit/withdraw derive the user from _msgSender(), while ConvexStakingWrapper/StakingRewards are the actual callers, so per-user accounting collapses into a single wrapper-owned entry.
**Exploitation:** Any user calling deposit/withdraw through the wrapper triggers MasterChef's reward payout to themselves, capturing accumulated rewards belonging to all other stakers in the shared wrapper position.
**Insight:** When a contract acts as an intermediary for many users, check whether the downstream contract keys accounting on msg.sender; if so, all users share one position and reward debt, letting any caller harvest others' accrued rewards.