Earlier this year, a domain once owned by a now-defunct content delivery network (CDN) was re-registered. Despite the original CDN having shut down years ago and its domain having expired, thousands of active websites, documentation sites, and code repositories are still using hard-coded references to that domain. These references continue to point to hostnames under the newly registered domain — a domain now under new control.
Although the domain’s root (apex) page now hosts an ad-heavy media downloader, the danger lies in the fact that any subdomain (hostname) under it still resolves to infrastructure the new owner controls. Because references on thousands of websites weren’t changed, visitors may unknowingly load third-party assets from a host that’s been taken over by someone else.
Real-World Incidents and the Long Tail of Code Debt
This kind of issue isn’t just theoretical. A similar event occurred in June 2024, when the popular polyfill.io domain changed hands. That JavaScript correction library is embedded by over 110,000 websites. After ownership changed, visitors from certain locations were redirected under certain conditions. None of the affected sites had been hacked or altered — the risk stemmed from outdated script tags that were never updated.
The problem extends beyond static code. Security tooling like dependency scanners or Software Composition Analysis tools focus on what your organization builds and ships. But third-party scripts fetched by browsers can behave differently depending on geography, browser type, referer, and other factors. Even when nothing on your server has changed, what users see and execute may be entirely out of your control, exposing sites to sophisticated client-side attacks.
Mitigations: Visibility & Compliance
One of the most effective defenses against these threats is the Content Security Policy (CSP). While its reputation often centers on preventing cross-site scripting, CSP also plays a crucial role in telling you what scripts are actually executing on your site. In particular, deploying a policy in “report only” mode lets you see what *would* have been blocked — with zero disruption. Over time, this enables you to audit hosted scripts and detect unauthorized behavior.
Regulatory frameworks have begun catching up. As of March 31, 2025, PCI DSS version 4.0.1 includes requirements that mandate organizations ensure every script loaded on a payment page is authorized, has verified integrity, and is properly inventoried — among other stipulations. The rules also require mechanisms for detecting unauthorized changes to page content or headers, with evidence and audits to back them up.
An example of best practice involves a simple staged approach: deploy a CSP in report-only mode for a week, build a full inventory of scripts and resources called by your pages, monitor drift over time, and approve or deny any changes. Recent data shows that such visibility tools are helping organizations realize just how much unknown third-party code they carry.
A platform called Report URI has become one go-to resource. It allows security teams to see which third parties are executing code on their websites, track changes over time, observe behavior from real users in real geographies, and bring unknown hosts under scrutiny. It doesn’t require agents or SDKs, making it lightweight yet powerful.
The takeaway is that expired domain names are more than just administrative hassles. When they belonged to critical infrastructure — like CDNs or popular script hosts — their expiration can lead to real, exploitable vulnerabilities in any site that still references them.
Why this matters: once you point to someone else’s domain — especially without control — you’re handing over part of your site’s integrity. What to watch for now: audit all third-party references, enforce CSPs (reporting mode first), and ensure compliance frameworks cover real-world execution, not just your development environment. Every website with legacy scripts still risks having its user-facing behavior hijacked.
