33 S&P 500 Companies Have a Confirmed, Live Subdomain-Takeover Vulnerability — 94% Have No Bounty Program

A dangling CNAME isn't a theoretical risk — it's a subdomain pointing at a cloud service (Azure, WP Engine, GitHub Pages, Unbounce, Heroku, Netlify, Fastly) that nobody has claimed. We confirmed 76 of these live right now across the S&P 500, on 33 companies. 31 of them have no bounty program.

NullBlocks Research — September 2026

Twelve prior reports in this series have each picked one exposure class — GraphQL introspection, Wayback-archived legacy pages, version-matched critical CVEs, database/admin ports, expired TLS certs, reverse-WHOIS sister domains, missing HSTS, missing clickjacking defenses, exposed FTP servers, exposed legacy mail ports, CORS wildcard-plus-credentials — and matched it against real bug-bounty coverage. This thirteenth report goes back to the class the very first report in the series (bug-bounty-coverage-gap) flagged in passing but never quantified on its own: confirmed subdomain takeover, arguably the single most consequential finding class a passive recon scan can produce, because it can be turned into a working exploit with zero authentication and near-total attacker control of the subdomain's content.

Methodology, up front

domrecon resolves the CNAME chain for every subdomain in the index and checks whether the CNAME target belongs to a known cloud/PaaS provider (Azure, AWS S3, GitHub Pages, WP Engine, Shopify, Zendesk, Unbounce, Heroku, Netlify, Fastly, Pantheon, Vercel, Ghost) with a documented "unclaimed resource" fingerprint. A dangling subdomain is flagged confirmed only when we observe the actual claim-page or 404 fingerprint that provider serves for an unclaimed resource on the live HTTP response — e.g. WP Engine's "The site you were looking for couldn't be found" page, not just a NXDOMAIN or a generic 404. That fingerprint match is what separates a confirmed takeover candidate (this report) from the much larger set of dangling CNAMEs that resolve to something but haven't been positively fingerprinted as literally unclaimed (3,584 additional HIGH-severity, unconfirmed candidates sit in the same table — we did not count those here).

We did not register any of these subdomains, claim any resource, or serve any content. This is a passive DNS/HTTP observation only, the same free-tier scan any domrecon user gets by entering a domain.

1. 33 companies, 76 confirmed dangling CNAMEs, seven different providers

Azure spreads the widest — 17 different companies with at least one confirmed dangling Azure CNAME — but the deepest single-company exposure belongs to Veeva Systems: 16 separate subdomains (da., engage., university., re., investor., neighborhood., and ten more) all pointing at the same unclaimed veevprod.wpengine.com WP Engine target. Any one of those sixteen hostnames is claimable today by registering that WP Engine site name — at which point the attacker controls content served under Veeva's own domain, with all the trust (and any stale cookies, CSP allowances, or SSO redirect rules) that implies.

¹ github.com is a data-quality artifact from our onboarding pipeline (a placeholder company row with primary_domain = github.com, not an actual S&P 500 constituent) — excluded from the "no bounty" analysis below since it isn't a real company in the index, though the ten confirmed *.github.io-CNAME findings under it are real DNS records worth noting for anyone auditing GitHub Pages-hosted subdomains generally.

2. 31 of the 32 real companies affected (96.9%) have zero matched HackerOne bounty coverage

Excluding the github.com placeholder row, 32 real S&P 500 constituents have at least one confirmed dangling CNAME. Only Starbucks has matched HackerOne bounty coverage; the other 31 — including Honeywell, PPG Industries, Sherwin-Williams, United Parcel Service, CVS Health, Boeing, McKesson, and Medtronic — have no visible channel for a researcher to report a live, exploitable takeover if they find one.

That's the same structural gap this series has now documented thirteen times, but this is the report where the gap matters most: subdomain takeover is the one class in this whole series where "no bounty program" doesn't just mean "no reward" — it means there's no clear, sanctioned path to disclose a vulnerability that, unpatched, is actively claimable by anyone else who notices it first.

3. What this does and doesn't mean

A confirmed flag in our data means the live HTTP response at that hostname matches the specific fingerprint the target provider serves for an unclaimed resource — it is not, by itself, proof that we (or anyone else) have registered the resource and taken control of the subdomain. We deliberately stopped at observation. What it does establish: the technical precondition for takeover is live, unpatched, and has been for long enough to be picked up by a routine recon scan — on infrastructure belonging to companies with combined market caps in the hundreds of billions.

Why this matters if you do attack-surface work for a living

Subdomain takeover is one of the few bug classes where a five-minute verification (attempt to register the target resource on the relevant platform, confirm you can serve content under the victim's subdomain, then immediately release/report it) produces unambiguous proof of impact — no authentication bypass, no payload crafting, just DNS pointing somewhere nobody owns. If you're a bug-bounty hunter, this is usually the highest signal-to-effort finding in the whole recon phase. If you run a security practice for clients, knowing which CNAMEs are dangling — continuously, not as a one-off audit, since new ones appear every time a marketing team spins up and tears down a landing-page tool — is exactly the kind of finding that's easy to miss between engagements. That's the gap NullBlocks/DomRecon is built to keep closing automatically — this report used data already sitting in the platform, not a one-off scan built for a blog post.