# Lack of access control in PublicVault.sol#transferWithdrawReserve let user call transferWithdrawReserve() multiple times to modify withdrawReserve

PublicVault.transferWithdrawReserve lacks access control; anyone can repeatedly call it while withdrawProxy is address(0), zeroing withdrawReserve without transferring funds.

- Payout: Contest reward
- Severity: high
- Program: Astaria
- Credited: Jeiwan
- Disclosed: 2022-11-07
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2022-10-astaria-judging/issues/163
- Library page: https://bugbountylibrary.com/r/sherlock%3A2022-10-astaria%3AH-26
- Tags: domain:web3 kind:contest platform:sherlock sev:high tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** PublicVault.sol transferWithdrawReserve()
**Root cause:** transferWithdrawReserve() has no access control and decrements withdrawReserve even when the withdrawProxy is address(0) and no transfer occurs.
**Steps:**
1. Call `PublicVault.transferWithdrawReserve()` before a WithdrawProxy is deployed (withdrawProxy == address(0)).
2. Transfer is skipped but `withdrawReserve -= withdraw` still executes.
3. Repeat the call until withdrawReserve reaches 0.
**How found:** Code review of transferWithdrawReserve() noting missing access control and that the state update occurs regardless of whether the proxy transfer succeeds.
**Exploitation:** Attacker repeatedly invokes transferWithdrawReserve() while no withdraw proxy exists; each call decrements withdrawReserve without moving assets, driving the reserve to zero and corrupting vault accounting.
**Insight:** In vault accounting, check whether state mutations (reserve decrements) are gated on the actual asset transfer succeeding; a no-op transfer path that still mutates balances is a repeatable drain of accounting state.