# Whitelisted profile creators could accidentally break migration for V1 profiles

Whitelisted profile creators could mint a handle matching an unmigrated V1 profile, causing batchMigrateProfiles to revert and permanently blocking that profile's migration.

- Payout: Audit contest
- Severity: medium
- Program: Lens Protocol
- Found by: MiloTruck
- Disclosed: 2023-12-11
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2023-07-lens#m-05
- Library page: https://bugbountylibrary.com/r/c4%3A2023-07-lens%3AM-05
- Tags: area:web3 domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:business-logic

**Target:** LensHandles / LensHub migration (batchMigrateProfiles)
**Root cause:** mintHandle() by whitelisted creators does not check whether the handle already belongs to an unmigrated V1 profile, so migration's migrateHandle reverts on duplicate ERC721 mint.
**Steps:**
1. Create a V1 profile with handle `alice.lens` via toLegacyV1Profile.
2. Whitelisted creator calls `lensHandles.mintHandle(address(this), "alice")`.
3. Call `hubProxy.batchMigrateProfiles([profileId])`.
4. Migration reverts with `ERC721: token already minted`, blocking the V1 profile.
**How found:** Code review of MigrationLib.batchMigrateProfiles and LensHandles.mintHandle, noticing migration mints handles without checking pre-existing handle NFTs minted by whitelisted creators.
**Exploitation:** A whitelisted profile creator mints a handle equal to an existing V1 profile's handle (minus .lens) before migration; the subsequent batchMigrateProfiles call reverts on duplicate mint, permanently blocking that profile's migration.
**Insight:** When a migration mints an NFT derived from legacy state, check whether any other privileged mint path can pre-occupy that same token ID before migration runs.