# FULL_RESTRICTED Stakers can bypass restriction through approvals

FULL_RESTRICTED stakers bypass blacklist by approving a third address that redeems their shares, since _withdraw never checks the owner role.

- Payout: Audit contest
- Severity: medium
- Program: Ethena Labs
- Found by: josephdara
- Disclosed: 2023-12-21
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2023-10-ethena#m-01
- Library page: https://bugbountylibrary.com/r/c4%3A2023-10-ethena%3AM-01
- Tags: area:web3 domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** StakedUSDe ERC4626 vault contract
**Root cause:** The overridden _withdraw only checks FULL_RESTRICTED_STAKER_ROLE on caller and receiver, not on _owner, so an approved spender can redeem on behalf of a restricted owner.
**Steps:**
1. Alice deposits USDe into StakedUSDe and receives shares.
2. Admin grants FULL_RESTRICTED_STAKER_ROLE to Alice.
3. Alice calls `stakedUSDe.approve(address(56), amount)`.
4. address(56) calls `stakedUSDe.redeem(amount, address(56), alice)`.
5. Withdraw succeeds because _owner role is unchecked; USDe is transferred to address(56).
**How found:** Manual review of the overridden _withdraw and _beforeTokenTransfer functions, noticing the owner parameter was omitted from the restriction check while ERC4626 redeem allows third-party spenders.
**Exploitation:** A restricted staker pre-approves a colluding address, which then calls redeem(shares, receiver, restrictedOwner) to pull all underlying USDe out, defeating the blacklist.
**Insight:** When overriding ERC4626 hooks to enforce access control, remember that redeem/withdraw have three actors (caller, receiver, owner); a blacklist must check all three or approved spenders become a laundering path.