Any responsible bug bounty researcher reviewing the DNS zone by hand would spot the CNAME and remove it from the target list. You don't get to wash your hands of that because your chatbot did it.
And I don't know anyone that would really look at the intermediary of a CNAME even during a manual test. Maybe if it was obviously a third party service.
It is your responsibility to do your due diligence as a security researcher versus “spray and pray” to ensure you are not exceeding the scope beyond your intended target.
Dump the subdomains, resolve them, and review where they resolve to in order to understand the footprint and attack surface boundaries before engaging scanning or agentic red team harnesses. Automate as much as possible for building the state graph of the target, but a human must remain in the loop to sanity check. To not do this means you could be attacking hyperscaler object storage, a CDN, a partner SaaS frontend, ticketing systems, mail systems, etc (ie anything someone may CNAME off the root domain but that is outside of their organization’s control).
% dig www.tesla.com +short
www.tesla.com.edgekey.net.
e1792.dscx.akamaiedge.net.
<akamai IP>
I think this line of reasoning doesn't make any sense. The internet is not an inherently safe network regardless of what we wish for; we can't wish away the bad activity, and it's only going to increase. The activity that helps prevent the bad activity from working is a net positive.
I think it's pretty disingenuous to compare viewing a couple of pages once a day with running scripting tools against over 400 websites.
> I think this line of reasoning doesn't make any sense. The internet is not an inherently safe network regardless of what we wish for; we can't wish away the bad activity, and it's only going to increase. The activity that helps prevent the bad activity from working is a net positive.
Oh good, no one has ever claimed "it's for your own good" when doing something selfish without consent.
As the OP said, they don't do anything when the server isn't vulnerable, and serving a 404 page is incredibly cheap.