Dead CDN Domain Re-Registered: Thousands of Sites at Risk

Dead CDN Domain Re-Registered: Thousands of Sites at Risk

In July 2025, someone re-registered a domain that used to belong to a content delivery network. The CDN had been wound down years earlier and the domain was allowed to expire. What it had not lost were its callers: thousands of websites, code repositories and documentation pages still carry hard-coded references to hostnames beneath it.

That domain is netdna-ssl.com, the asset host behind MaxCDN — before that, NetDNA, a CDN that started life in 2010. If you were a WP Engine customer on their "Legacy Network", your static assets — JS, CSS, fonts, images — were served from a host that looked like <site-hash>.wpengine.netdna-ssl.com. MaxCDN was swallowed by StackPath in 2016, the brand was retired at the end of 2022, and StackPath's CDN shut down in late 2023. WP Engine had been steering everyone onto their Advanced Network for years.

Except the domain itself was allowed to expire — and on 24 July 2025, somebody bought it.

The new owner controls the whole namespace

The new registrant holds wildcard DNS across the entire *.wpengine.netdna-ssl.com namespace. That is not speculation; you can prove it in minutes the way researcher Scott Helme did:

# Who owns it now — RDAP lookup
curl -s https://rdap.verisign.com/com/v1/domain/netdna-ssl.com
#   registration   2025-07-24T18:13:09Z
#   expiration     2027-07-24T18:13:09Z
#   nameservers    JACK.NS.CLOUDFLARE.COM, MEILING.NS.CLOUDFLARE.COM
#   registrar      Gname.com Pte. Ltd.

# Does a made-up subdomain resolve? (it does)
dig +short test123random.wpengine.netdna-ssl.com
#   104.21.72.58
#   172.67.175.240

# What does the apex serve today?
curl -s https://netdna-ssl.com/ | grep -io '<title>[^<]*</title>'
#   <title>Snapinsta - Download Instagram Videos, Reels, Stories for FREE</title>

The apex now serves an ad-heavy Instagram-downloader page wired up to Google AdSense and Tag Manager. So an unrelated third party with an ad-monetisation motive owns a domain that thousands of real sites still pull assets from. The decision about what those pages load next belongs to a stranger — and nobody has been notified, because from the outside nothing appears to have broken.

Why it is a loaded gun, not a fire

Here is the nuance most headlines skip. The deep legacy asset hostnames — the actual <hash>.wpengine.netdna-ssl.com URLs that pages reference — currently fail the TLS handshake:

openssl s_client -connect netdna-ssl.com:443 \
  -servername wrz...gpg.wpengine.netdna-ssl.com
#   ... sslv3 alert handshake failure

The reason is mundane. The Cloudflare Universal SSL certificate on the edge only covers netdna-ssl.com, proxy.netdna-ssl.com and *.proxy.netdna-ssl.com — it does not cover *.wpengine.netdna-ssl.com. So right now those legacy script-src and font-src requests break rather than execute attacker code. Those sites are not currently compromised by this.

But make no mistake — closing that gap is a single toggle in Cloudflare's Advanced Certificate Manager, as Scott Helme points out. The DNS control is total and the monetisation is already running. The day a *.wpengine.netdna-ssl.com certificate gets issued, this flips from "broken asset" to "arbitrary JavaScript executing in thousands of pages."

The blast radius is real, not hypothetical. A GitHub code search for wpengine.netdna-ssl.com returns nearly 4,000 files, including real references in real projects — the mozilla/webxr-polyfill repo loads its web fonts from a .wpengine.netdna-ssl.com host, and the list also includes Kong, Nextcloud, the Yale Daily News and Server Density. Not all of those are confirmed-vulnerable live sites — they are residual references — but Cloudflare Radar ranks netdna-ssl.com inside the top 20,000 domains globally, measured from live DNS resolver data. Real browsers are still resolving this name today, in volume.

We have seen this exact movie before

If this feels familiar, it is the polyfill.io attack from June 2024 wearing different clothes. There, a JavaScript shim domain embedded in more than 110,000 sites changed ownership and began serving conditional redirects to mobile visitors. The sites running it had not been hacked — they had simply outsourced a <script> tag years earlier and never revisited the decision.

Both cases share a problem most security teams have no control over: the malicious code was never on their server, and it arrived long after the last deployment.

Server-side tooling is looking in the wrong place

Static analysis, dependency scanners and software composition analysis all examine what an organisation builds and ships. A third-party script is none of those things. It is fetched by the visitor's browser, from a server the organisation does not run, live on every page view.

That makes it uniquely hostile to conventional testing, because the response can vary by geography, user agent, referrer, time of day and session. A crawler pulling the file once from a data-centre IP range gets a clean version; the shopper on a mobile network in another country gets something more sinister. Magecart-style client-side attacks do not require a server breach at all — they require one approved script tag to start behaving differently. The script itself holds the same privileges as your first-party code: it can read the DOM, read form fields character by character as they are typed, read cookies and local storage, and make outbound requests to anywhere it likes.

The browser is the observer that never misses a session

There is one observer reliably present for every one of those page views: the browser that executed the code. That is why the conversation keeps coming back to Content Security Policy — not just as an XSS defence, but as a way to learn what code is actually running on your site. A CSP can control what code is allowed to run, block code that is not authorised, and tell you when it happens — from real sessions, real geographies, real users. A malicious payload that only fires for logged-in users in one country still gets reported, because the browser that ran it is the thing sending the alert.

This is not theoretical. In September 2026, CSP alerts surfaced a cluster of compromised e-commerce sites running a ClickFix-family social-engineering campaign: Base64-encoded loaders planted inside CMS content after an administrative compromise, chaining through a redirector to a fake "verify you are human" overlay that placed a PowerShell command on the victim's clipboard and persisted it as a scheduled task. Attacker-controlled hostnames showed up in browser alerts while several of those domains were still rated clean by mainstream reputation services. On the server, the pages were fine — no scanner flagged them.

Compliance has already turned this into an obligation

For anyone handling card payments, the argument is already settled. PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 stopped being best practice and became mandatory on 31 March 2025. They require that every script on a payment page is authorised, that its integrity is assured, that a written inventory with business justification exists, and that a mechanism detects and alerts on unauthorised modification of payment page content and HTTP headers. A QSA can and will ask for the inventory, the alerting mechanism and the evidence trail.

What to actually do

You cannot unpublish a DNS reference you forgot about, but you can find it:

1. Grep your own estate — HTML, themes, databases, configs, docs — for netdna-ssl.com, netdna-cdn.com and *.wpengine.netdna-ssl.com. Remove or rehost anything you find. WP Engine customers should move off the Legacy Network onto the Advanced Network.
2. Use SRI — Subresource Integrity on third-party <script> and <link> tags means a swapped file fails closed instead of executing. It will not save fonts or images (there is no SRI for those), so pair it with the next step.
3. Enforce CSP, and report on it — a tight script-src / font-src / connect-src stops the loaded gun firing in your pages. Deploy it in Content-Security-Policy-Report-Only first: it enforces nothing and changes no behaviour, it only tells you what a policy would have blocked. For most organisations that list is a lot longer than expected — it is exactly how researchers keep finding domains like this one.
4. Audit your dependencies — the DNS ones too. The domains you stopped thinking about years ago are exactly the ones somebody else is hoping you forgot.

This is the same class of trust failure as chain-of-flaws supply-chain backdoors and poisoned-package worms: we pin our trust to a domain rather than to the code, and when the domain changes hands every site that referenced it gets dragged along. Unlike polyfill.io, this one is pre-positioned but currently dormant — which means, for once, there is a window to fix it before it goes off. Grep your estate today.

Sources

• Scott Helme: A dead CDN, a wildcard, and an attack waiting to happen — the netdna-ssl.com takeover
• The Hacker News: An Abandoned CDN Domain Was Re-Registered. Thousands of Sites Still Call It.