# Missing Authorization Check Allows Unauthorized Fund Withdrawal

WERC7575Vault.withdraw/redeem omit any msg.sender==owner or allowance check, letting anyone burn an owner's shares and redirect underlying assets to themselves.

- Payout: Contest reward
- Severity: high
- Program: SukukFi
- Credited: 0xSeer
- Disclosed: 2026-04-14
- Write-up quality: 7/10
- Original: https://code4rena.com/reports/2025-11-sukukfi#h-01
- Library page: https://bugbountylibrary.com/r/c4%3A2025-11-sukukfi%3AH-01
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** WERC7575Vault.sol withdraw/redeem (ERC4626-style vault with separate share token)
**Root cause:** The vault's withdraw/redeem never verify msg.sender is the owner or an approved spender; _withdraw only calls _shareToken.spendSelfAllowance(owner, shares), consuming the owner's allowance to the vault rather than any allowance to msg.sender.
**Steps:**
1. Owner approves the Vault on the share token (prerequisite for legitimate burns).
2. Attacker calls `withdraw(assets, attacker, victim)` or `redeem(shares, attacker, victim)` on WERC7575Vault.
3. Vault burns victim's shares via `_shareToken.spendSelfAllowance(victim, shares)` with no check on msg.sender.
4. Underlying assets are sent to attacker's receiver address.
**How found:** Code review comparing the implementation against standard ERC4626: noticed _spendAllowance(owner, msg.sender, shares) is replaced by _shareToken.spendSelfAllowance(owner, shares), which checks allowance to the vault, not to msg.sender, and that no msg.sender==owner check exists.
**Exploitation:** Attacker needs only a victim who has approved the vault to spend their shares; calling withdraw/redeem with owner=victim and receiver=attacker burns the victim's shares and transfers the underlying assets to the attacker. If the vault holds privileged burn rights without user approval, all share owners are drainable.
**Insight:** When a vault delegates share accounting to a separate token contract, the ERC4626 allowance semantics break: spendSelfAllowance checks allowance to the vault, not to the caller, so always verify msg.sender==owner or an explicit spender allowance on the share token.