# wrapETH2LD permissioning is over-extended

NameWrapper.wrapETH2LD lets wrapper-approved operators wrap and seize unwrapped ENS domains, extending approval beyond wrapped tokens.

- Payout: Contest reward
- Severity: medium
- Program: ENS
- Credited: 0x52
- Disclosed: 2022-12-13
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2022-07-ens-findings/issues/51
- Library page: https://bugbountylibrary.com/r/c4%3A2022-07-ens%3AM-01
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:medium tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** NameWrapper.sol wrapETH2LD (ENS wrapper contract)
**Root cause:** wrapETH2LD authorizes msg.sender if approved for all on the ERC721 registrar OR approved on the wrapper contract; wrapper-level approval should only cover wrapped tokens but also permits wrapping unwrapped domains.
**Steps:**
1. User grants wrapper contract approval (intending only wrapped-domain control).
2. Attacker (approved on wrapper) calls `wrapETH2LD` on a victim's unwrapped domain.
3. Because L221 accepts wrapper approval, the call succeeds and attacker gains control of the newly wrapped token.
**How found:** Code review of wrapETH2LD permission checks; noticed the OR condition accepting wrapper-level approval and reasoned that approval scope should be limited to tokens the wrapper manages.
**Exploitation:** An address approved on the wrapper contract can wrap any unwrapped ENS 2LD and take ownership, since approval intended for wrapped tokens is honored for unwrapped ones.
**Insight:** When a contract checks approval against multiple sources (registrar vs wrapper), verify each approval's intended scope; wrapper-level approval should not authorize actions on tokens not yet wrapped.