Why is a subdomain takeover more than a DNS hygiene ticket when no defect was exploited?

## The classification argument The common reflex — “stale record, low severity, put it on the housekeeping list” — is built on a patch-shaped view of risk: find the defective component, rate it, fix it. That view genuinely cannot see this. There is no defective component. Every system involved behaves exactly as designed: the zone publishes what its owner told it to publish, the resolver returns it, the provider allocates a free name to the account that asked for it, and the certificate authority certifies control of a hostname by the party that demonstrably controls it. Severity therefore has to be argued from **what the name carries**, and the name carries more than most people expect. ## What a held subdomain inherits **Cookies scoped to the parent domain.** A cookie set with `Domain=example.com` is attached by the browser to requests for *any* host under `example.com`. If a session, a preference token or an anti-forgery value is scoped that broadly — and it very often is, for convenience — then a page served at a hijacked `app.example.com` receives it. Same-site protections do not intervene, because the two hosts genuinely are the same site: they share a registrable domain. The one common cookie shape that is safe is a host-only cookie with no `Domain` attribute (the `__Host-` prefix enforces exactly that), which is sent only to the host that set it. **Trust granted by suffix.** Real estates are full of allowlists written as a domain suffix rather than a list of hosts: cross-origin request rules, redirect and callback allowlists, internal service policies, link and mail filters, single-sign-on return targets. All of them read `*.example.com` as “us”. A stranger holding one host under that suffix is inside every one of those lists at once, without touching any of the systems that hold them. **Certificate eligibility for that exact hostname.** Demonstrating control of a name is the whole test for domain-validated issuance, and the claimant now controls it. The result is your hostname served over HTTPS with no warning — which removes the one signal a user might otherwise have noticed. **Reputation.** The name appears in old mail, printed material, partner integrations and search results. Content served there borrows every bit of credibility the organisation spent years building, which is precisely what makes the name resaleable to someone else. ## Why “we are fully patched” is not an answer Patching addresses defects in code you run. Here the exposure is a pointer in a zone plus a namespace policy at a provider. You could be perfectly current on every package in the estate and the takeover would proceed identically. Conversely, the fix requires no patch at all — it is one record change. A finding whose cost to fix is minutes and whose loss on exploitation includes session material and brand trust is, on any honest reading, not a low-severity item. ## Where the severity genuinely varies Severity is not uniform across every dangling name, and a good answer says so rather than declaring everything critical: | Factor | Raises it | Lowers it | |---|---|---| | Cookie scope in use on the parent domain | Broad `Domain=` cookies | Host-only cookies everywhere | | Suffix-based trust anywhere in the estate | Wildcard allowlists, wildcard callbacks | Explicit host lists | | The name's visibility | Customer-facing, in mail, in documentation | Never published, random label | | What the name implies | `login.`, `pay.`, `vpn.` | `old-demo-2019.` | That table is the actual answer to “how bad is it”, and it is a better answer than a single label. ## The reviewer's line If you have to argue this in a room, the compact version is: *nothing was exploited because nothing had to be — we are the ones publishing the pointer, and what we handed over is our own name, everything the browser sends to it, and everything else in the estate that trusts it by suffix.* That sentence reclassifies the ticket without needing a defect to point at.