# The owners of a rental safe can continue to use the old guard policy contract for as long as they want, regardless of a new guard policy upgrade

Rental safes keep pointing at a deactivated Guard policy, so owners can bypass restrictions added in the upgraded guard indefinitely.

- Payout: Contest reward
- Severity: medium
- Program: reNFT
- Credited: oakcobalt
- Disclosed: 2024-03-20
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2024-01-renft-findings/issues/267
- Library page: https://bugbountylibrary.com/r/c4%3A2024-01-renft%3AM-10
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:incomplete-fix technique:source-review vuln:access-control vuln:business-logic

**Target:** Solidity Guard policy contract / rental safe
**Root cause:** Guard.checkTransaction and its helpers never verify that address(this) is still an active policy in Kernel; they only call access-control-free Storage view functions, so a stale guard keeps validating transactions.
**Steps:**
1. Protocol upgrades guard via Kernel.executeAction -> _activatePolicy(newGuard) -> _deactivePolicy(oldGuard).
2. Admin whitelists a migration contract; safe owners must voluntarily delegatecall it to update their stored guard pointer.
3. A safe owner who skips migration keeps the old Guard address in storage.
4. Safe executes a transaction; Safe calls old Guard.checkTransaction, which passes because STORE.whitelistedDelegates/contractToHook/isRentedOut/whitelistedExtensions are unrestricted view calls.
5. Selectors or delegatecalls newly forbidden by the upgraded guard are still permitted for that safe.
**How found:** Code reading of Guard.sol's checkTransaction/_checkTransaction helpers, noticing every check routes through Storage.sol view functions with no access control and no isActive check against Kernel; contrasted with Stop.sol which reverts for stale policies, forcing migration.
**Insight:** When a protocol supports policy/plugin upgrades, check whether the old implementation self-validates its active status; any guard whose checks only read unrestricted storage views will keep authorizing after deactivation.