# Unlinked address can link immediately again

unlinkAddress deletes the link but leaves pendingLinkAddresses set, letting a just-unlinked address re-link to its master without permission.

- Payout: Audit contest
- Severity: medium
- Program: Sublime
- Found by: gpersoon
- Disclosed: 2022-02-14
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-12-sublime-findings/issues/54
- Library page: https://bugbountylibrary.com/r/c4%3A2021-12-sublime%3AM-04
- Tags: area:web3 domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** Verification.sol smart contract (address linking)
**Root cause:** unlinkAddress() deletes linkedAddresses[_linkedAddress] but does not clear pendingLinkAddresses[_linkedAddress][master], so the stale pending flag still satisfies linkAddress's require.
**Steps:**
1. Master calls `unlinkAddress(addr)`; linkedAddresses[addr] is deleted but pendingLinkAddresses[addr][master] remains true.
2. Unlinked addr calls `linkAddress(master)`; require linkedAddresses[msg.sender].masterAddress == 0 passes, and require pendingLinkAddresses[msg.sender][master] passes due to stale flag.
3. _linkAddress re-links addr to master without master's consent.
**How found:** Code reading of unlinkAddress/linkAddress/cancelAddressLinkingRequest: noticed pendingLinkAddresses is only reset in cancelAddressLinkingRequest, not in unlinkAddress, so the pending flag survives unlinking.
**Exploitation:** A previously unlinked address re-invokes linkAddress(masterAddress) immediately after being unlinked; the stale pendingLinkAddresses entry lets the link succeed without any new approval from the master.
**Insight:** When a state machine has paired 'pending' and 'active' mappings, check every transition that removes the active entry to confirm the pending entry is also cleared; stale pending flags re-enable actions the owner thought revoked.