Third-party scripts still load from an abandoned CDN domain

Thousands of websites still load third-party scripts from a content delivery network domain that someone re-registered in July 2025, years after the service behind it was wound down. The domain had been allowed to expire, but its callers did not go away: a contributed article from Report URI, published by The Hacker News, reports that thousands of websites, code repositories and documentation pages still contain hard-coded references to hostnames beneath it. The new owner holds wildcard DNS across the entire domain, which means any hostname under it now resolves to infrastructure that person controls. The apex, the domain's main address, currently serves an ad-heavy media downloader page, which in itself is unremarkable. What matters is that the decision about what those thousands of pages load next now belongs to a stranger, and nobody involved has been notified, because from the outside nothing broke.

This pattern is not hypothetical. In June 2024, the polyfill.io domain, a JavaScript shim embedded in more than 110,000 sites, changed ownership and began serving conditional redirects to visitors on mobile. The sites running it had not been hacked; they had outsourced a script tag years earlier and never revisited the decision. A script tag is one line of code that tells a browser to fetch and run a file hosted somewhere else, and a shim is a small piece of code that patches gaps in older browsers. Both cases share a problem that most security teams have no control over: the malicious code was never on their server, and it arrived long after the last deployment happened.

Server-side tooling is looking in the wrong place, the article argues. Static analysis, dependency scanning and software composition analysis all examine what an organisation builds and ships, but 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 and cannot control, 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 address range can be shown a clean version, while a shopper on a mobile network in another country gets something more sinister. The third-party script itself holds the same privileges as first-party code: it can read the DOM (the page structure a browser builds), read form fields character by character as they are typed, read cookies and local storage, and make outbound requests to anywhere it likes. Client-side attacks of the Magecart type do not require a server breach at all; they require one approved script tag to start behaving differently.

There is one observer reliably present for every one of those page views: the browser that executed the code. Content Security Policy (CSP), a set of instructions a site sends to browsers listing which sources of code may run, is usually discussed as a defence against cross-site scripting, and it is a good one. Its second function is more useful to a security team that does not yet know what code it is running: a policy can control what code is allowed to run, block code that is not authorised to run, and report when that happens. Those reports come from real sessions, in real places, from real users on their real devices, so 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. The piece cites a concrete example: in September 2026, alerts collected by Report URI surfaced a cluster of compromised e-commerce sites running a social-engineering campaign of the 'ClickFix' family. Base64-encoded loaders, meaning code disguised as ordinary text, had been 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. The attacker-controlled hostnames turned up in alerts from victims' browsers while several of those domains were still rated clean by mainstream reputation services. No scanner had flagged the pages, because on the server they were fine.

The common objection is that a Content Security Policy will break the site, but in report-only mode it cannot. Content-Security-Policy-Report-Only enforces nothing, blocks nothing and changes no behaviour; it only reports what a policy would have blocked. That turns the first deployment into a safe measurement exercise and gathers all the data needed about what code is running on a site. For most organisations, that list is a lot longer than they expected, the article says.

For anyone handling card payments, the argument is already settled. PCI DSS version 4.0.1 requirements 6.4.3 and 11.6.1 stopped being best practice and became mandatory on 31 March 2025. Together, 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 (the behind-the-scenes information a web server sends alongside each page). A QSA, a qualified security assessor who checks card-payment compliance, can and will ask for the inventory, the alerting mechanism and the evidence trail it produced. Report URI states that its product can supply all three.

The piece sets out a three-step deployment: gather initial data for a week, build an inventory from what was reported, then monitor changes over time and approve or deny them. It also cites a ten-year daily crawl of the top one million sites showing CSP adoption growing by more than 12,000% across the decade; the article does not name who ran that crawl. That growth, it argues, reflects a broader shift in where organisations need visibility: not only into what they deploy, but into what code their users' browsers actually execute.

Report URI describes itself in the piece as a client-side security platform that answers questions a security team cannot otherwise answer about its own site: which third parties are executing code on its pages, which changed since yesterday, and which are taking data or communicating with infrastructure known to be hostile. The scripts served to real users are hashed and archived so that changes can be identified and investigated after the fact, hostnames are checked against threat intelligence, and policies are monitored for drift, closing the gap between what was approved and what is actually running. Deployment adds no JavaScript to the page and no agent, module or SDK to the stack; the first step is to add an HTTP response header and read what comes back over the following 48 hours. Readers should weigh the recommendations knowing that the article is a contributed piece from Report URI, the vendor of the platform it describes, and that it