The Abandoned CDN Domain That Thousands of Sites Still Call: Inside the netdna-ssl.com Takeover

A domain retired since 2023 quietly changed hands last year. It's not attacking anyone yet — but the pieces are already in place.

Domains die quietly. Someone stops paying the renewal, the service behind it winds down, and the name just falls back into the pool. Most of the time nothing happens. Occasionally, someone else picks it up — and if enough old code still points at it, that's a problem for people who never touched the new owner's website at all.

That's the situation security researcher Scott Helme laid out in detail[1] after spotting netdna-ssl.com showing up somewhere it shouldn't have: in Content Security Policy violation reports, flagged as a domain that browsers were still trying to reach.

What netdna-ssl.com used to be

netdna-ssl.com was the asset domain behind MaxCDN, a content delivery network that traces back to NetDNA in 2010[1]. If you ran a WordPress site on WP Engine's older "Legacy Network" setup, your static files — JavaScript, CSS, fonts, images, PDFs — were served from a URL that looked something like <site-hash>.wpengine.netdna-ssl.com. Millions of pages, over the years, baked that hostname into their HTML.

MaxCDN itself didn't survive as a brand. StackPath acquired it in 2016, retired the MaxCDN name at the end of 2022, and then shut the CDN down entirely in late 2023[1]. WP Engine had been pushing customers toward a newer "Advanced Network" for years before that. So the service died, and reasonably enough, the domain that supported it was eventually let go too.

Nobody renewed netdna-ssl.com. And on 24 July 2025, somebody else did.

Who owns it now

A quick RDAP lookup — the modern successor to WHOIS — settles the question. The domain was registered through Gname.com Pte. Ltd. on that date[1], and it now sits on Cloudflare nameservers. The apex page itself serves a "Snapinsta" Instagram video downloader, wired into Google AdSense and Google Tag Manager. In other words: an unrelated ad-monetization operation now owns infrastructure that thousands of pages are still quietly pinging.

That alone wouldn't be much of a story. Domains get repurposed for ad arbitrage constantly — it's a well-worn, mildly annoying business model, not a security incident by itself. What makes this one different is what the new owner also inherited without asking for it.

The wildcard problem

When you re-register a domain, you get to set your own DNS configuration from scratch. The new owner of netdna-ssl.com set up a wildcard record across the entire legacy namespace: *.wpengine.netdna-ssl.com. Helme confirmed this by querying a hostname he'd just invented on the spot — something that had never existed before — and it resolved anyway, because the wildcard answers for literally anything under that path.[1]

That matters because every one of those old <hash>.wpengine.netdna-ssl.com asset URLs, still sitting in themes, plugin code, cached databases and documentation pages, now points at servers the original site owner has zero control over.

Here's the part that keeps this from being an emergency today rather than a slow-burning one: the deep asset hostnames currently fail their TLS handshake. Cloudflare's certificate on the edge only covers the apex and proxy.netdna-ssl.com[1] — not the wildcard subdomain pattern that legacy WP Engine assets actually use. So right now, a browser trying to load a script or font from one of those URLs just gets a broken connection. Not malicious code. Just an error.

Why the risk is real even though nothing has fired yet

It would be easy to read "the certificate doesn't cover it yet" and move on. That undersells it. Closing that gap doesn't require a new attack technique or a vulnerability disclosure — it's a single toggle in Cloudflare's certificate manager, available to anyone controlling the account. The DNS control is already total. The monetization infrastructure is already running. All that's missing is one configuration change, and it's a change entirely within the new owner's power to make whenever they choose.

To be precise about scope, since precision matters here: a GitHub code search for the legacy hostname pattern turns up nearly 4,000 files[1] referencing it — including real, currently maintained repositories like mozilla/webxr-polyfill, plus references tied to Kong, Nextcloud, and various university and media sites. That's a count of residual references in code, not a confirmed tally of 4,000 live, vulnerable production sites. Some of those references are in dead branches or abandoned forks. But it's also not a fossil-only number: Cloudflare Radar independently ranks netdna-ssl.com inside the top 20,000 domains globally[1] by live resolver traffic, meaning real browsers are hitting this domain today, in volume, whether or not the requests succeed.

No active exploitation has been reported. Nobody has published evidence of malicious JavaScript actually being served from the legacy asset hostnames. This is, as of the research behind this piece, a pre-positioned risk rather than a confirmed compromise — and it's worth being honest about that distinction instead of dressing up a dormant misconfiguration as an active attack.

We've seen this movie before

If the setup sounds familiar, it should. In June 2024, the polyfill.io domain — a JavaScript compatibility library embedded on an enormous number of sites — changed hands to a company later accused of injecting malicious redirect code into the script it served. Sansec's initial forensic report put the scale at more than 110,000 affected sites[2]; a follow-up count by Censys about a week later found over 380,000 hosts[3] still embedding the compromised script, and other researchers have since argued even the higher figures undercounted the true reach. The exact number is genuinely contested across sources — what isn't contested is that it was large, and that it happened because thousands of sites had pinned their trust to a domain rather than to a specific, verifiable piece of code.

Google responded by blocking ads on affected e-commerce sites. Cloudflare began auto-rewriting requests to a safe mirror. Namecheap eventually suspended the domain outright. None of that happened instantly, and in the meantime the malicious code was live, redirecting a subset of mobile visitors to gambling and adult sites through evasive, hard-to-catch logic that avoided triggering on admin accounts or analytics tools.

The netdna-ssl.com situation is the same underlying mechanism — trust pinned to a domain that changed hands — with one meaningful difference in timing. Polyfill.io fired the moment the new owner flipped the switch. This one hasn't fired yet. That gap, however narrow, is the actual news here: a chance to fix the exposure before there's anything to clean up.

Who should actually care

Practically, this affects two overlapping groups. First, anyone still running WordPress on WP Engine's Legacy Network, since that's the specific hosting configuration that generated these asset URLs in the first place. WP Engine's own documentation confirms the Legacy Network is "a basic connection type... no longer recommended"[4], with customers steered toward the Advanced Network for years. Second, and more broadly, anyone whose codebase — regardless of current host — still contains a hardcoded reference to netdna-ssl.com or netdna-cdn.com from an old theme, plugin, or migration that never got fully cleaned up.

There's no CVE attached to this, no CVSS score, and no vendor patch to apply, because it isn't a software vulnerability. It's an infrastructure ownership problem, and the fix lives entirely on the side of whoever still references the old domain.

What to actually do about it

The fix here is unglamorous and entirely within a site owner's control:

• Search your own codebase. Grep HTML, themes, and any exported database dumps for netdna-ssl.com, netdna-cdn.com, and the *.wpengine.netdna-ssl.com pattern specifically. Remove or rehost anything you find. If you're still on WP Engine's Legacy Network, this is also a good prompt to finally move to their Advanced Network or Global Edge Security.
• Use Subresource Integrity (SRI) on any third-party <script> or <link> tag you can't eliminate outright. SRI pins a hash of the expected file; if the served content changes, the browser refuses to run it — it fails closed rather than executing whatever shows up. It won't protect fonts or images referenced outside script/link tags, since there's no SRI mechanism for those.
• Tighten your Content Security Policy, and turn on reporting. A strict script-src, font-src, and connect-src stops a swapped-in payload from executing even if a reference slips through, and report-uri / report-to lets you actually see when your pages are still calling out to domains you forgot about — which, notably, is exactly how this issue was found in the first place.

Security takeaway

Nothing about this story required a zero-day, a leaked credential, or a clever exploit chain. It required an expired domain registration and eighteen months of nobody checking. That's the uncomfortable pattern behind most domain-based supply chain risk: the vulnerability isn't in anyone's code, it's in the assumption that infrastructure you stopped thinking about years ago is still safe to trust. Auditing dependencies usually means checking npm packages or container images. It should also mean occasionally asking whether the domains your site still quietly calls out to are the ones you think they are.

Sources & References

1. [1] Scott Helme — A dead CDN, a wildcard, and an attack waiting to happen: the netdna-ssl.com takeover — 24 Jun 2026 — View source
2. [2] The Hacker News — Over 110,000 Websites Affected by Massive Polyfill.io Supply Chain Attack — 25 Jun 2024 — View source
3. [3] The Hacker News — Polyfill.io Attack Impacts Over 380,000 Websites — 3 Jul 2024 — View source
4. [4] WP Engine — Comparing Network Options — View source