Front-Running Vulnerability in NameWrapper

Earlier this year, Unruggable and ENS Labs jointly discovered a vulnerability in both the ENSv2 registry design and the NameWrapper.

This vulnerability went undetected during multiple code reviews and audits of the NameWrapper, only coming to light during development work on the ENSv2 registry design.

Vulnerability Details

The vulnerability enables a malicious seller of an ENS name to burn fuses on the name through a front-running attack during a sale.

In a worst-case scenario, an attacker begins by purchasing a high-value ENS name and listing it for sale on a marketplace. They then monitor the mempool for purchase transactions. Upon detecting a purchase, they front-run the sale with a transaction that changes the resolver to an OwnedResolver they control and burn the CANNOT_SET_RESOLVER fuse.

The result is devastating for the buyer: they receive an ENS name with an attacker-controlled resolver that cannot be changed due to the burned fuse. This gives the attacker significant leverage to extort payment from the buyer in exchange for transferring control of the OwnedResolver.

The attack is particularly dangerous due to its low cost and ease of execution. Attackers can target liquid assets like number domains such as 363.eth, which can be quickly bought and sold with minimal financial investment. The technical barriers to executing the attack are also quite low, making it accessible to a wide range of potential attackers.

Mitigation Options

For immediate protection, buyers should avoid purchasing high-value names wrapped in the NameWrapper. Name owners who haven’t burned the CANNOT_UNWRAP fuse still have the option to unwrap their names.

Looking at long-term solutions, ENS is developing ENSv2, which includes a fundamental fix where burning fuses changes the ENS Name NFT’s ID. As part of this solution, name owners will be able to bridge their names to either the V2 L1 Ethereum registry or the planned Namechain L2. Importantly, this migration path will work even for names with burned CANNOT_UNWRAP fuses.

An alternative solution would be to deploy an upgraded NameWrapper contract with front-running protection. This could be implemented using the existing upgrade feature in the NameWrapper. However, this approach has several drawbacks: not all users would choose to upgrade, resulting in multiple active NameWrapper contracts that would increase complexity for both developers and marketplaces.

The ENSv2 migration represents the preferred solution, as it provides a cleaner path forward and additional benefits beyond addressing this vulnerability. However, its deployment timeline is not yet fixed. The NameWrapper upgrade could serve as a faster interim solution if needed.

Note: This bug is classified as high/critical according to the Immunefi Vulnerability Severity Classification System - v2.3 due to “Unintended alteration of what the NFT represents.” While ENS Labs has confirmed this as a newly discovered bug, it has not been independently reviewed by Immunefi or other external auditors that I am aware of.

2 Likes

It doesn’t; this is an example of the sunk cost fallacy. Economically for the buyer, they’re equally well off finding a different domain as they are throwing good money after bad after being subject to a griefing attack. There’s no route to profitability for an attacker here other than relying on cognitive biases in the victim of this griefing attack.

2 Likes

By your own definition, the attacker needs to buy the name, and then convince someone else to pay the same price or higher or risk losing money if the party decides not to play ball. I would define that as a high cost, not a low cost.

1 Like

For liquid names like numbers, the cost of even a failed attack is very low. The name can be purchased at the market price and then flipped for the same price. The attacker only incurs the cost of gas for one additional transaction.

we deemed it unlikely / “low” severity and did not report it. it would be discovered after the first malicious sale and the reputation of the seller would be “burned” + as nick said, there is no financial motivation for it aside from “being an asshole”.

edited to be more PC.

Also disclosing it here on the forum publicly makes it more likely to happen now and probably should have only been disclosed after a fix if you feel it is “critical”…

Typically this bars one from bounty payouts when disclosing publicly / early.

2 Likes