Domain takeovers turn forgotten dependencies into code execution vectors. Nothing needs to be unpatched or misconfigured. An asset that a site trusted years ago just changes hands. Security researcher Scott Helme recently found one in Content Security Policy (CSP) report feeds: the takeover of netdna-ssl.com.
WordPress administrators and web developers with a few years behind them will know this domain. It was the backbone of MaxCDN and WP Engine’s legacy content delivery networks. It was allowed to expire and has since been re-registered by an unrelated third party. The new owner also runs a wildcard DNS configuration that covers thousands of legacy asset URLs. The domain is one TLS certificate away from being an active threat.
How the CDN died
The domain started as the asset host for NetDNA, which launched MaxCDN in 2010 to offer content delivery to small and large businesses. WP Engine customers on the “Legacy Network” had their static assets (JavaScript, CSS, web fonts and images) routed through hostnames formatted as <site-hash>.wpengine.netdna-ssl.com.
StackPath acquired MaxCDN in 2016. The MaxCDN brand was retired at the end of 2022, and the underlying StackPath CDN kept running until the company announced in June 2024 that it was shutting down and liquidating its assets. WP Engine had spent years moving customers off the Legacy Network and onto its Advanced Network and Global Edge Security (GES) configurations. The migration mostly worked, so nobody had a reason to keep the original netdna-ssl.com root domain, and it expired.
The takeover and the wildcard
Expired legacy domains are a known attack vector, but the details of this re-registration make it a serious supply chain risk. RDAP (Registration Data Access Protocol) lookups show the domain was re-registered on July 24, 2025 through Gname.com Pte. Ltd., with nameservers pointed to Cloudflare.
The new owner serves “Snapinsta” on the apex domain, an Instagram video and reel downloader monetized through Google AdSense and Tag Manager. An ad-funded landing page on the root domain is harmless enough. The problem is the DNS zone. The registrant holds a wildcard DNS record across the whole *.wpengine.netdna-ssl.com namespace. Querying made-up hostnames with dig shows that any legacy hash-based URL left in a theme file, plugin database or documentation page resolves to the registrant’s infrastructure, specifically Cloudflare IP addresses like 104.21.72.58. Every rendered page that still emits one of these URLs sends its visitors’ browsers to a domain controlled by someone with an ad-monetization motive.
The TLS handshake failure
Despite the DNS takeover, the web is not seeing mass defacement or malware injection. Connecting to a deep asset hostname with openssl s_client fails with an SSLv3 handshake alert. This comes down to how Cloudflare handles certificates and Server Name Indication (SNI).
The edge servers currently present Cloudflare’s Universal SSL certificate. It covers the apex domain (netdna-ssl.com) and specific subdomains like *.proxy.netdna-ssl.com, but not the deep wildcard *.wpengine.netdna-ssl.com. The browser requests a hostname that doesn’t match the certificate’s Subject Alternative Names (SAN), so the handshake aborts before any payload can run.
That protection is thin. Closing the gap takes one toggle in Cloudflare’s Advanced Certificate Manager (ACM) to issue a custom wildcard certificate. The registrant already has full DNS control and a live monetization setup. Once a valid certificate is issued, the domain can serve arbitrary JavaScript to every site that still references it.
The blast radius and the Polyfill.io parallel
A GitHub code search turns up nearly 4,000 files with hardcoded references to the domain. Some of them belong to active, high-profile projects, including Mozilla’s webxr-polyfill (which loads Zilla Slab web fonts), Kong, Nextcloud and the Yale Daily News. Cloudflare Radar also ranks netdna-ssl.com in the top 20,000 domains globally by live DNS resolver data, so real browsers are still resolving and loading assets from this namespace in volume.
📬 Stay Ahead of Cyber Threats
Get the latest cybersecurity news, critical vulnerabilities, threat intelligence, tutorials, and exclusive giveaways delivered straight to your inbox. No spam. Unsubscribe anytime.
Subscribe to the Newsletter →The closest precedent is the Polyfill.io supply chain attack of June 2024. The popular JavaScript CDN was sold to a new owner who then injected malicious code into more than 100,000 websites. In both cases, developers trusted a domain name instead of verifying the code itself. When the domain changes hands, every site that references it inherits the new owner’s intentions. Polyfill.io’s payload went live immediately. netdna-ssl.com is set up but hasn’t fired, which leaves a short window to fix things first.
Remediation for developers and sysadmins
Audit and migrate legacy infrastructure
Start by auditing your codebase, theme files and database. Grep every web root for netdna-ssl.com, netdna-cdn.com and *.wpengine.netdna-ssl.com. WP Engine customers still on the deprecated Legacy Network need to migrate to the Advanced Network or Global Edge Security (GES). That means updating DNS records so the CNAME or A records point to the new network, which cuts every tie to the NetDNA namespace.
Use Subresource Integrity (SRI)
For third-party scripts and stylesheets that have to stay on external domains, add an integrity attribute with a cryptographic hash to your <script> and <link> tags. If the new domain owner alters the file, the browser refuses to run it. SRI has limits, though. It covers scripts and stylesheets only. It does nothing for web fonts loaded through @font-face, and it doesn’t cover images or other media.
Enforce a strict Content Security Policy
A tight CSP is your last line of defense against a domain takeover. If you explicitly list allowed sources in script-src, font-src and connect-src, the browser blocks unauthorized assets even when a wildcard domain gets a valid TLS certificate. The report-uri and report-to directives let your security team watch for violations in real time. That kind of CSP violation monitoring is how researchers first spotted the odd traffic going to netdna-ssl.com.
Treat DNS as a dependency
Teams audit npm packages and container images closely but tend to ignore the DNS records that resolve their static assets. The domains you stopped thinking about years ago are the ones attackers hope you forgot. Scan live HTTP responses in your CI/CD pipeline for deprecated or unowned domains, and make it a routine check.
Conclusion
A TLS misconfiguration is the only thing currently keeping the netdna-ssl.com takeover from becoming a mass compromise. The wildcard DNS control underneath it is already in place, and thousands of sites still point at it. Until a valid wildcard certificate exists, SRI, a strict CSP and a cleanup of legacy CDN references are the defenses that work.
