# NFT transfer approvals are not removed and cannot be revoked thus leading to loss of NFT tokens

Visor's approveTransferERC721 sets NFT approvals true but never false, and no revoke exists, so a stale or compromised delegate can steal the NFT.

- Payout: Audit contest
- Severity: high
- Program: Visor
- Found by: 0xRajeev
- Disclosed: 2021-08-30
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-05-visorfinance-findings/issues/34
- Library page: https://bugbountylibrary.com/r/c4%3A2021-05-visorfinance%3AH-02
- Tags: area:web3 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:** Visor vault contract ERC721 approval/transfer functions
**Root cause:** approveTransferERC721() only sets nftApprovals to true and there is no code path to set it false; transferERC721() does not clear the approval after transfer.
**Steps:**
1. Alice calls `approveTransferERC721()` granting Eve transfer rights to a specific NFT in her vault
2. Eve calls `transferERC721()` moving the NFT to Bob
3. Alice buys the NFT back and deposits it into her vault
4. Eve still holds the stale approval and calls `transferERC721()` to steal the NFT to any address
**How found:** Code review of approveTransferERC721/transferERC721 noticing approvals are only ever set true and never cleared, and no revoke function exists.
**Exploitation:** A previously approved delegate (or attacker who compromised the delegate's keys) retains permanent transfer rights over a specific NFT; once the NFT returns to the vault or after the delegate turns malicious, they transfer it out without any new approval.
**Insight:** When auditing approval systems, check that every grant has a corresponding revoke path and that approvals are cleared on transfer; stale per-token approvals survive re-deposits and key compromise.