> Unfortunately bug bounty programs often blanket exclude any form of "subdomain takeover" as a valid security threat, despite the fact that they're easily exploitable once discovered.
This sounds as if it should be more differentiated by how easy the domain would be able to obtain.
Like, it's obvious that "If I somehow took over google.com, I could compromise Google users" is no valid security vulnerability. But if taking over unregistered (or lapsed) domains results in a compromise, as demonstrated here, this should be seen as a valid vulnerability.
Would "provide a working proof-of-concept that doesn't require DNS configuration on the client" not cover the difference? Maybe it'd be nice to still care about moderate-risk theoretical stuff without needing a fully functional PoC, but this would at least stop cases where bug reporters show a working exploit and still get ignored and not paid (I was reading just yesterday about the [Zendesk Slack takeover bug](https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b...) where that happened; in that case, there was a real Zendesk vulnerability which Zendesk first ignored, then later withheld payment for because the reporter shared a working PoC for Slack takeovers with companies affected by the Zendesk vulnerability after Zendesk had stated it was out of scope for them.)
loading story #42799604
I'd like to offer that it also depends on the utility of the domain. If I got a bug bounty submission that demonstrated takeover of b2938978-us-east-2-testing-box.mycompany.com I would classify it as less severe than if you were able to take over say, signin.mycompany.com (even if signin.mycompany.com hasn't ever been in use) since that's highly valuable for phishing. And of course, a subdomain like api.mycompany.com that is in active use, that would probably be the most severe of all since you might be able to say, tell all garage door openers that phone home to immediately open.