# quitPeriod is effectively always just 1 day

Vault owner can shorten quitPeriod to 1 day after proposing fee/adapter changes, bypassing users' expected 3-day rage-quit window.

- Payout: Contest reward
- Severity: medium
- Program: Popcorn
- Credited: immeas
- Disclosed: 2023-09-07
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-01-popcorn-findings/issues/785
- Library page: https://bugbountylibrary.com/r/c4%3A2023-01-popcorn%3AM-02
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:business-logic vuln:governance

**Target:** Vault.sol fee/adapter change timelock
**Root cause:** quitPeriod is read at execution time (changeFees/changeAdapter) rather than snapshotted at proposal time, so owner can lower it after proposing changes.
**Steps:**
1. Owner calls `proposeFees(newFees)`; users expect to wait current quitPeriod (e.g. 3 days).
2. Wait 1 day: `vm.warp(block.timestamp + 1 days)`.
3. Owner calls `setQuitPeriod(1 days)` (allowed since >=1 day).
4. Owner calls `changeFees()`; check `block.timestamp < proposedFeeTime + quitPeriod` now passes.
**How found:** Code review of setQuitPeriod bounds and changeFees timing check; noticed quitPeriod is evaluated at execution, not proposal, enabling retroactive shortening.
**Exploitation:** Malicious/compromised owner proposes unfavorable fee or adapter change, waits one day, reduces quitPeriod to 1 day, then executes changeFees/changeAdapter before users can rage-quit.
**Insight:** When a timelock/delay parameter is mutable and read at execution time, check whether it can be lowered after the action is queued to shrink the effective delay; snapshot the delay at proposal time.