# Modifier VaultController._verifyCreatorOrOwner does not work as intented

VaultController._verifyCreatorOrOwner used OR instead of AND, so only a caller who is both creator and owner passes, blocking vault deployment and pause/unpause for legitimate creators.

- Payout: Contest reward
- Severity: high
- Program: Popcorn
- Credited: ustas
- Disclosed: 2023-09-07
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-01-popcorn-findings/issues/45
- Library page: https://bugbountylibrary.com/r/c4%3A2023-01-popcorn%3AH-12
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** VaultController.sol access-control modifier
**Root cause:** Modifier reverts when `msg.sender != metadata.creator || msg.sender != owner`, which is true for everyone except a caller who is simultaneously creator and owner; should be `&&`.
**Steps:**
1. Read modifier at VaultController.sol#L666-L670: `if (msg.sender != metadata.creator || msg.sender != owner) revert NotSubmitterNorOwner(msg.sender);`
2. Build truth table showing OR condition only false when sender is both creator and owner
3. Add test to test/vault/VaultController.t.sol calling `controller.deployVault(...)` with rewardsData non-empty as bob (creator, not owner)
4. Run `forge test --match-test testFail__deployVault_creator_is_not_owner -vvvv`; observe revert `NotSubmitterNorOwner(0x...DCbA)`
**How found:** Code review of the access-control modifier; constructed a truth table for the boolean condition and confirmed with a Foundry test that a creator who is not owner is rejected.
**Insight:** When auditing access modifiers, write out the truth table of the boolean expression — De Morgan errors turning AND into OR (or vice versa) silently invert the allowed set and are easy to miss by eye.