# Insufficient Length Check When Verifying Allowed Data Keys

Zero-length entry in LSP6 allowed ERC725Y data keys compacts to a zero mask, letting a key with SETDATA write nearly any data key on a shared Universal Profile.

- Payout: Audit contest
- Severity: medium
- Program: LUKSO
- Found by: codegpt
- Disclosed: 2023-09-18
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2023-06-lukso#m-07
- Library page: https://bugbountylibrary.com/r/c4%3A2023-06-lukso%3AM-07
- Tags: area:web3 domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** LSP6KeyManager / LSP6SetDataModule allowed ERC725Y data key validation
**Root cause:** The compact bytes array length check only rejects length > 32, not length == 0; a zero length produces mask = bytes32(0), making the AND comparison always equal.
**Steps:**
1. Set an address's AllowedERC725YDataKeys to `bytes.concat(bytes2(0))` (a 0x0000 entry) before transferring profile ownership to the LSP6KeyManager.
2. Grant that address `_PERMISSION_SETDATA` via the AddressPermissions permissions key.
3. Transfer ownership of the UniversalProfile to the LSP6KeyManager and accept ownership through `keyManager.execute(abi.encodeWithSelector(ILSP14Ownable2Step.acceptOwnership.selector, ""))`.
4. Call `setData` for any dataKey not under LSP1/LSP6/LSP17 prefixes; `keyManager.lsp20VerifyCall(malicious, 0, data)` passes because allowedKey & 0 == inputDataKey & 0.
**How found:** Code review of the compact-bytes length validation and mask construction in LSP6SetDataModule: noticed length==0 yields a zero mask and that the pre-ownership-transfer state is not validated, then confirmed with a Foundry fuzz test.
**Exploitation:** A malicious profile co-owner sets up the shared Universal Profile, inserts a 0x0000 into their own allowed data keys list, then hands ownership to the key manager. The extra zero bytes look benign to the other party, but grant the attacker SETDATA over LSP3 profile metadata, LSP5 received assets and LSP10 vault ownership keys, allowing them to corrupt/obstruct those values.
**Insight:** When a bitmask is derived from an attacker-influenced length, test the length==0 boundary: a zero mask makes every AND comparison trivially equal. Also check state set before ownership handover to a permission contract, since post-handover setters may assume it was valid.