Reported Subdomain Takeovers

A subdomain takeover is a Web/App vulnerability that is exploited when an attacker registers a non-existent domain name in order to obtain control of an existing target domain. In doing so, the attacker could potentially damage the target by hosting malicious content, distributing exploits, bypassing content security policies, etc.

Let’s use the domain takeover.immunefi.com as an example.

• takeover.immunefi.com has a CNAME that points to another domain (e.g., not-immunefi.eth)
• For some reason, not-immunefi.eth expired and now an attacker is able to register it
• Because the attacker now owns not-immunefi.eth and the CNAME record has not been deleted from the DNS zone, they have full authority over takeover.immunefi.com

As you can see, such an attack has the potential to damage a project. However, not all subdomain takeovers lead to a serious impact on the project’s core application.

What is Immunefi’s policy regarding reported subdomain takeovers?

At Immunefi, we have a policy of always closing these reports as out of scope unless they are supplemented with more information on how the attack could be used to impact the project’s core application. Furthermore, the project must list subdomain takeovers as a valid impact in their bug bounty program. 

Simply identifying that a domain is vulnerable to a subdomain takeover is not enough to warrant a reward. Instead, the whitehat must also connect this attack vector to an in scope impact as outlined in the project’s bug bounty program.

There are two ways that someone could chain this attack to impact the in-scope domain. You can read more about these techniques in the following article here. 

And please keep in mind that we have strict rules for how whitehats should create PoCs for subdomain takeovers. Specifically, whitehats should not affect the state of the website and they should not disclose to the public that the vulnerability exists.

What if a whitehat submits multiple subdomain takeover reports?

If multiple reports identify distinct subdomains that point to the same in scope impact, then you should reward the first submission and close the others as duplicates (see our article on duplicate submissions here). With said, we encourage you to provide a goodwill payment for the duplicate submissions because there is still some informational value provided when a whitehat discovers a vulnerable subdomain.

If multiple reports identify distinct subdomains that point to different in scope impacts, then each submission should be rewarded individually because they represent distinct vulnerabilities