Expired CDN Domain Highlights Persistent Client-Side Script Risk
Thousands of sites still reference a re-registered CDN domain
A domain once used by a content delivery network was registered by a new owner in July 2025, years after the CDN itself had been wound down. Thousands of websites, code repositories and documentation pages still contain hard-coded references to hostnames beneath that domain.
Because the new registrant controls wildcard DNS for the entire domain, any of those hostnames can now resolve to infrastructure under that person’s control. The domain apex currently presents an advertising-heavy media downloader, but the more important issue is that the content delivered to old callers can be changed without notice.
This is a client-side supply-chain problem rather than a conventional server compromise. A site may have made no deployment and suffered no breach, yet a visitor’s browser can still retrieve code or other content from an external location that has changed hands.
Why server-side checks can miss the change
Static analysis, dependency scanning and software composition analysis focus on components an organisation builds and ships. A third-party script loaded by the browser sits outside that boundary: it is requested live on each page view from a server the site operator does not control.
Such responses can be tailored by geography, user agent, referrer, time or session. A crawler may receive benign content while a visitor using a particular mobile network receives a malicious response. Once executed, a third-party script has the same browser privileges as first-party code, including access to the DOM, form fields, cookies and local storage.
The 2024 change of ownership at polyfill.io illustrated the exposure. The JavaScript shim was embedded on more than 110,000 sites before it began serving conditional redirects to mobile visitors. The affected sites had not necessarily been hacked; they had retained an old external script reference.
CSP reporting provides browser-level visibility
Content Security Policy can restrict which resources may execute on a website and report policy violations from real user sessions. That reporting matters when suspicious code only appears for particular users or locations, because the browser that receives and runs the response can send the alert.
In September 2026, Report URI said its CSP alerts identified compromised e-commerce sites involved in a ClickFix social-engineering campaign. Base64-encoded loaders placed in CMS content after an administrative compromise led visitors through a redirector to a fake verification overlay. The campaign copied a PowerShell command to the clipboard and created persistence through a scheduled task. Some attacker-controlled hostnames appeared in browser alerts while mainstream reputation services still rated them clean.
Organisations can begin with Content-Security-Policy-Report-Only. This mode does not block resources or alter site behaviour; it records what a proposed policy would have blocked. A practical initial process is to collect reports for a week, build an inventory of scripts and hosts, then review and approve or deny later changes.
Payment-page obligations raise the stakes
For organisations handling card payments, PCI DSS v4.0.1 requirements 6.4.3 and 11.6.1 became mandatory on 31 March 2025. They require payment-page scripts to be authorised and integrity-assured, supported by a written inventory and business justification, with detection and alerting for unauthorised changes to payment-page content and HTTP headers.
The operational implication is clear: teams need visibility into what customers’ browsers actually execute, not only into deployed server-side assets. An initial report-only CSP deployment can establish that inventory and create evidence for investigating unexpected external code, domain ownership changes and policy drift.