Every now and then I go digging through Report URI's Threat Intelligence data feeds, looking for domains that show up in CSP reports where they really shouldn't. Last week one jumped out at me: netdna-ssl.com. If you've been around the WordPress world for a while, that name might ring a bell — and that's exactly the problem.

What netdna-ssl.com used to be

netdna-ssl.com was the asset domain behind MaxCDN, the CDN that started life as NetDNA back in 2010. If you were a WP Engine customer on their "Legacy Network", your static assets — JS, CSS, fonts, images, PDFs — were served from a host that looked like this:

<site-hash>.wpengine.netdna-ssl.com

MaxCDN got swallowed by StackPath in 2016, the brand was retired at the end of 2022, and StackPath's CDN ceased operations in late 2023. WP Engine had been steering people onto their Advanced Network for years. Job done, right?

Except the domain itself was allowed to expire. And on 24th July 2025, somebody re-registered it.

Who owns it now

A quick RDAP lookup tells the story:

$ 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.

It's now sitting on Cloudflare nameservers, registered through Gname, and the apex serves this:

$ curl -s https://netdna-ssl.com/ | grep -io '<title>[^<]*</title>'
<title>Snapinsta - Download Instagram Videos, Reels, Stories for FREE</title>

A "Snapinsta" Instagram-downloader page, wired up to Google AdSense and Tag Manager. So an unrelated third party with an ad-monetisation motive now owns a domain that thousands of sites still pull assets from. You can probably see where this is going.

The wildcard

Here's the part that really caught my eye. The new owner holds wildcard DNS across the entire *.wpengine.netdna-ssl.com namespace. I can prove it by asking for a hostname that I just invented:

$ dig +short test123random.wpengine.netdna-ssl.com
104.21.72.58
172.67.175.240

That resolves. Every legacy <hash>.wpengine.netdna-ssl.com asset URL still floating around in themes, docs and databases now points at infrastructure the original owner doesn't control.

Why it isn't on fire yet

It's tempting to overstate this, but I want to be honest. The apex and wpengine.netdna-ssl.com are live over HTTPS today. But the deep 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 cert on the edge only covers:

DNS:netdna-ssl.com, DNS:proxy.netdna-ssl.com, DNS:*.proxy.netdna-ssl.com

No *.wpengine.netdna-ssl.com. So right now those legacy script-src and font-src requests break rather than execute attacker code.

But make no mistake — this is a loaded gun, not a safe one. Closing that gap is a single toggle in Cloudflare's Advanced Certificate Manager. The DNS control is already total, 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."

How big is the blast radius?

A GitHub code search for wpengine.netdna-ssl.com returns nearly 4,000 files at the time of writing. Not hypothetical, either — these are real references in real projects:

  • mozilla/webxr-polyfill loads its web fonts (@font-face, Zilla Slab) from a …-wpengine.netdna-ssl.com host
  • Kong, Nextcloud, the Yale Daily News, NCSS, Server Density… the list goes on

To be precise: that's the scale of residual references, not 4,000 confirmed-vulnerable live sites. But every rendered page that still emits one of these URLs is sending its visitors' browsers to a domain owned by an ad operator.

This isn't a forgotten backwater — it's a top 20,000 domain

You might reasonably assume a dead CDN domain gets no real traffic, and that those GitHub hits are just fossils sitting in repos nobody runs. They're not. Cloudflare Radar ranks netdna-ssl.com inside the top 20,000 domains globally. That's a popularity bucket measured from live DNS resolver data — real browsers are still resolving this name today, in volume. Cloudflare's own URL scan of the domain confirms what's being served at the other end of those requests. So this isn't a theoretical risk built on a code-search number; it's a domain with genuine, current reach that an unrelated ad operator now controls.

We've seen this exact movie before

If this feels familiar, it's because it's the polyfill.io attack from June 2024 wearing different clothes. There, a domain everyone trusted changed hands, and ~100,000+ sites inherited the new owner's intent overnight. Same root cause every time: we pin our trust to a domain, not to the code. When the domain changes hands, every site that referenced it gets dragged along.

The difference here is timing. polyfill.io fired immediately. netdna-ssl.com is pre-positioned but currently dormant — which means, for once, there's a window to fix it before it goes off.

What to actually do

If you want to take some immediate steps to make sure this potential issue doesn't impact you:

  1. Grep your sites. Search your HTML, themes, and database for netdna-ssl.com, netdna-cdn.com and *.wpengine.netdna-ssl.com. Remove or rehost anything you find. WP Engine customers: get off the Legacy Network and onto the Advanced Network / GES.
  2. Use SRI. Subresource Integrity on third-party <script> and <link> tags means a swapped file fails closed instead of executing. (It won't save your fonts or images, mind you — there's no SRI for those.)
  3. Lock down CSP — and report on it. A tight script-src / font-src / connect-src stops the loaded gun firing in your pages, and report-uri / report-to lets you detect these references in the wild. That's not a sales pitch, it's literally how I found this one — it turned up in CSP reports.

Audit your dependencies. Not just the npm ones — the DNS ones too. The domains you stopped thinking about years ago are exactly the ones somebody else is hoping you forgot.