ENS
The Ethereum Name Service (ENS) is a distributed, open, and extensible naming system based on the Ethereum blockchain.
PoC Required
Vault program
Select the category you'd like to explore
Assets in Scope
Impacts in Scope
Program Structure
This program contains two independent reward tracks. Each track has its own severity classifications and reward ranges. A vulnerability shall be classified under one track only.
- Track A: Smart Contract Vulnerabilities
- Track B: Websites and Applications Vulnerabilities
Cross-Track Classification: Where a vulnerability involves both smart contract and web/application components, it shall be classified under the track corresponding to the root cause of the vulnerability. For example, a signature verification flaw in a smart contract is a Track A vulnerability even if its effects are visible through a web interface.
Definitions & Calculations
Impact Assessment
For many ENS vulnerabilities, the primary impact is to name ownership or resolution integrity rather than direct theft of funds. ENS therefore uses a two-part framework to assess impact: (1) the scope of names affected, and (2) a financial calculation where applicable.
Part 1: Impact Scope
The scope of a vulnerability is assessed according to the following tiers:
-
Tier 1 — Systemic: The vulnerability affects all ENS names, or all names of a major type (e.g., all .eth 2LDs, all names using a particular resolver). Tier 1 vulnerabilities will generally be assessed at the upper end of the applicable severity range.
-
Tier 2 — Class-wide: The vulnerability affects a significant class of names (e.g., all DNS-imported names, all names registered through a specific registrar). Tier 2 vulnerabilities will generally be assessed at the mid-to-upper range.
-
Tier 3 — Conditional: The vulnerability affects a subset of names defined by external conditions (e.g., names under TLDs with weak DNSSEC keys, names using a deprecated resolver version). Tier 3 vulnerabilities will generally be assessed at the mid range, subject to the External Dependency Discount where applicable.
-
Tier 4 — Narrow: The vulnerability affects fewer than 50 individual names or accounts. Tier 4 vulnerabilities will generally be assessed at the lower end of the applicable severity range.
Within each tier, ENS will consider the categories of names affected. Not all names carry equal value or risk:
- .eth 2LDs — highest value (primary ENS namespace, active secondary market, significant transaction volume)
- DNS-imported names — moderate value (tied to external DNS ownership)
- Subdomains — variable (depends on parent name usage and configuration)
- Testnet names — lowest value (no real funds at risk)
Part 2: Financial Calculation
Where a vulnerability involves direct theft or misdirection of funds (e.g., draining ETH from a contract, redirecting payments), "funds directly affected" means the aggregate on-chain value that could be misappropriated, misdirected, locked, or destroyed through exploitation of the vulnerability at the time of report submission.
For Tier 4 (narrow) vulnerabilities affecting name ownership or resolution, the following supplementary methodology may be used:
-
The value of affected names may be calculated based on the most recent secondary market sale price or, if no sale has occurred, the annualized registration/renewal cost.
-
Potential misdirection of funds (e.g., payments sent to a wrong address due to hijacked resolution) may be calculated based on the trailing 90-day transaction volume to addresses resolved through the affected names.
-
Speculative or theoretical future losses are excluded from all calculations.
General Provisions
The following sections apply to all vulnerabilities reported.
Primacy of Impact vs. Primacy of Rules
Primacy of Impact means that the impact is prioritized rather than a specific asset. This encourages security researchers to report on all bugs with an in-scope impact, even if the affected assets are not in scope. For more information, please see Best Practices: Primacy of Impact.
Primacy of Impact submissions remain subject to the program’s reward calculation methodology, including impact-based scaling, the External Dependency Discount, and discretionary adjustment.
Feasibility Limitations
The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug’s severity.
Therefore, Immunefi has developed a set of feasibility limitation standards which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.
Severity Assessment for XSS Reports
- Injection of malicious content into app.ens.domains to initiate a malicious transaction without requiring unusual user interaction will be considered Critical.
- Injection of malicious scripts into other ENS subdomains (besides app.ens.domains) that offer web3 wallet connections will be considered High for stored XSS and Medium for reflected XSS.
- XSS on staging/dev or static ENS websites like metadata.ens.domains, which do not offer web3 functionality, will be considered Low unless a direct impact on app.ens.domains is demonstrated.
Manipulation of governance voting result deviating from voted outcome and resulting in a direct change from intended effect of original results
Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield
Direct theft of any user NFTs, whether at-rest or in-motion, other than unclaimed royalties
Permanent freezing of funds
Permanent freezing of NFTs
Unauthorized minting of NFTs
Predictable or manipulable RNG that results in abuse of the principal or NFT
Unintended alteration of what the NFT represents (e.g. token URI, payload, artistic content)
Protocol insolvency
Execute arbitrary system commands
Subdomain takeover with already-connected wallet interaction
Direct theft of user funds
Out of scope
-
Taking over broken links from sources that are no longer considered active, such as links related to meeting minutes, past events etc., as this content is left up for archival purposes and should not be changed.
-
Products funded or maintained by the DAO unless otherwise stated
Web & App specific
- Theoretical impacts without any proof or demonstration
- Impacts involving attacks requiring physical access to the victim device
- Impacts involving attacks requiring access to the local network of the victim
- Reflected plain text injection (e.g. url parameters, path, etc.)
- This does not exclude reflected HTML injection with or without JavaScript
- This does not exclude persistent plain text injection
- Any impacts involving self-XSS
- Captcha bypass using OCR without impact demonstration
- CSRF with no state modifying security impact (e.g. logout CSRF)
- Impacts related to missing HTTP Security Headers (such as X-FRAME-OPTIONS) or cookie security flags (such as “httponly”) without demonstration of impact
- Server-side non-confidential information disclosure, such as IPs, server names, and most stack traces
- Impacts causing only the enumeration or confirmation of the existence of users or tenants
- Impacts caused by vulnerabilities requiring un-prompted, in-app user actions that are not part of the normal app workflows
- Lack of SSL/TLS best practices
- Impacts that only require DDoS
- UX and UI impacts that do not materially disrupt use of the platform
- Impacts primarily caused by browser/plugin defects
- Leakage of non sensitive API keys (e.g. Etherscan, Infura, Alchemy, etc.)
- Any vulnerability exploit requiring browser bugs for exploitation (e.g. CSP bypass)
- SPF/DMARC misconfigured records)
- Missing HTTP Headers without demonstrated impact
- Automated scanner reports without demonstrated impact
- UI/UX best practice recommendations
- Non-future-proof NFT rendering
All categories
- Impacts requiring attacks that the reporter has already exploited themselves, leading to damage
- Impacts caused by attacks requiring access to leaked keys/credentials
- Impacts caused by attacks requiring access to privileged addresses (including, but not limited to: governance and strategist contracts) without additional modifications to the privileges attributed
- Impacts relying on attacks involving the depegging of an external stablecoin where the attacker does not directly cause the depegging due to a bug in code
- Mentions of secrets, access tokens, API keys, private keys, etc. in Github will be considered out of scope without proof that they are in-use in production
- Best practice recommendations
- Feature requests
- Impacts on test files and configuration files unless stated otherwise in the bug bounty program
- Impacts requiring phishing or other social engineering attacks against project's employees and/or customers