Subdomain Hijacking Of Any Qwilr’s Customer

First Happy new year to fellow Hackers,

I was planning to write on my blog regularly for the last few months, but I could not do that due to my lack of time and laziness. So here’s a new year gift for you guys ?

Back in October 2022, I was testing a really old private program on HackerOne and they were running a bug bounty program when I started my journey on this platform. So I thought let’s take a look at this target.

Their scope was * and you know what to do next! After doing Subdomain Enumeration I always check all subdomains based on the below points –

  • Print all DNS records. I mostly use – for sub in $(cat subdomains.txt);do dig $sub +noquestion +noauthority +noadditional +nostats | grep -wE "CNAME|A"
  • Print live subdomain titles and status codes. I mostly use – cat subdomains.txt |httpx -status-code -content-length -title -tech-detect -follow-redirects

Nothing special caught my attention. But few of the subdomains were pointing to <subdomain> and this time I passively enumerated subdomains for this .info TLD from project sonar FDNS datasets as this .info TLD is not listed in the target’s scope and I don’t want to create any unwanted incident. Also, I was only interested to take a look at this .info TLD as the program scope was a wildcard and I know most of the wildcard programs accept DNS Hijacking issues for any of their assets. Then I noticed two of the subdomains are pointing to the CNAME record


This caught my attention as visiting these domains was responding like the below screenshot – 

Qwilr error

This error looks suspicious. So I quickly googled available docs on Qwilr’s custom domain setup and I found this page where they mentioned only enterprise plan users can set up a custom domain. I registered a trial account and tried to use the custom-domain feature from and it always gives a popup like the below –

Custom domain requirements

So no way to check if our target’s subdomains were actually claimed or not. While I was quitting on this I noticed they have the option at to get a subdomain of your choice like <your_subdomain> and serve your pages on that subdomain. 

As you can get a subdomain of and the custom domain setup required CNAME record is which is also a subdomain of that domain, so what will happen if I can claim this custom-domains prefix from my trial account? Most of the time if vendors offer such subdomains as services they blacklist or reserve a few keywords like admin, support, app, login, etc for their usage or security purposes. But in the case of Qwilr’s they didn’t take any such steps that allowed me to use the custom-domains prefix from my trial account.

Available to claim

We all know CNAME records can be used to alias one name to another and our target subdomain’s CNAME is which is claimed by me and I can serve contents on it. So technically my Qwilr pages should be accessible from all domains which are pointing to the CNAME unless there is any additional configuration in place in the backend.

So I created a PoC page from and copied the shareable URL what looks like The next thing I did was replaced the subdomain with <subdomain> and visited the URL and boom – Takeover PoC

Again I replaced the subdomain with the other subdomain and it’s also reflecting my PoC.

Takeover PoC 2

So I again used the project sonar FDNS datasets to look for all DNS records that are pointed to CNAME 

FDNS Records

300+ subdomains using that record and I confirmed all of them are vulnerable and I can access my PoC from all of those subdomains. A few of the PoC are listed below –

Yale University PoC
Yale University PoC
Stanford University PoC
Stanford University PoC
PoC TravelBank
PoC TravelBank

I created two submissions on HackerOne and they Triaged both reports and forwarded the issue to the Qwilr support team immediately. I also forwarded this to a few other bug bounty programs and one of them confirmed they have an active working service. So this proves I can hijack and serve my PoC content on both claimed and non-claimed subdomains.

burnrate CEO reply

Another program replied with additional info that confirms my theory –



  • Discovered the vulnerability – 25 October, 2022 
  • Created HackerOne Submissions – 25 October, 2022
  • HackerOne Triaged both reports – 26 October, 2022
  • Created other Bug Bounty Submissions – 27 October, 2022
  • The vulnerability was Fixed By Vendor – Nov 01, 2022
  • Both HackerOne report was rewarded – Nov 09, 2022
  • Got a few rewards & cool swags from other programs.


  • Never test OOS assets actively. If you want to do it ask for proper permission and try to reduce the noise.
  • Never test a 3rd party vendor unless they have a responsible disclosure policy.
  • Always read 3rd party vendor docs and look into all options of their services.
  • Think out of the box.


One Response

Leave a Reply

Your email address will not be published. Required fields are marked *