Most Content Security Policy audits focus on what a script does. A quieter risk is who still owns the domain it's coming from, and a story that surfaced this month is a reminder that the answer can change without anyone touching your code.
What happened
In July 2025, a CDN domain used by a meaningful number of sites was allowed to lapse by its original operator and was quietly re-registered by an unrelated party. According to reporting from The Hacker News on September 18, 2026, that new owner now controls wildcard DNS for the domain, meaning they can stand up any subdomain and serve whatever content they choose from it. The problem is that thousands of sites, repositories, and pieces of documentation never stopped referencing hostnames under that domain. In many cases, those references live inside CSP script-src allowlists, which means the new owner inherited something valuable without ever breaching a single victim: first-party-level trust, granted by policies written years earlier and never revisited.
That mechanism is worth sitting with. No credentials were stolen. No server was compromised. The vulnerability was simply that a policy pointed at a name, the name changed hands, and the policy didn't know.
Why this isn't a new story, but is still an urgent one
If this pattern sounds familiar, it should. It's structurally the same failure mode behind the 2024 polyfill.io incident, in which a popular open-source CDN domain was sold to a new owner who began serving malware to an estimated 110,000+ sites that had never removed the script tag. The lesson from that incident was supposed to be that third-party script trust needs an expiration date. This month's story suggests that lesson didn't fully land, because the underlying habit it targets, treating a CSP allowlist as something you configure once and leave alone, is still extremely common.
CSP was designed to answer the question "what is allowed to run on this page." It was not designed to ask a follow-up question that turns out to matter just as much: "is this still who I meant to trust?" A script-src directive doesn't expire when the domain's registration does, and it doesn't get an alert when ownership changes. It just keeps trusting the string.
What this means for the sites still carrying the risk
Any site with an allowlisted domain that traces back to an abandoned project, a vendor that shut down, a CDN that migrated infrastructure, or simply a script tag nobody has looked at in a couple of years is carrying the same exposure, whether or not that specific domain has been re-registered yet. The uncomfortable part is that a standard CSP audit (checking that the policy is present, checking that directives are reasonably strict, checking for unsafe-inline) will not catch this. The policy can be syntactically excellent and still be trusting an origin that no longer belongs to anyone the site owner would recognise.
This is also a category of risk that CSP violation reporting alone won't surface in advance. Reports tell you when something outside your policy tried to run. They don't tell you that something inside your policy has quietly become someone else's.
The practical takeaway
Treat every entry in a CSP allowlist as a relationship, not a static string, and revisit it on a schedule rather than only when something breaks. A few concrete habits follow directly from this incident:
Audit allowlisted origins for currency, not just presence. Confirm that each third-party domain is still operated by the vendor you originally added it for, and flag anything tied to a project, product, or company that's been sunset, acquired, or gone quiet. Pair allowlisting with Subresource Integrity hashes wherever the script's content is expected to stay stable, since SRI fails closed if a domain starts serving something different than what you approved, even if the domain itself still resolves. And where SRI isn't practical, favour CSP configurations that make an ownership change loud rather than silent. Monitoring and reporting infrastructure that flags when a long-trusted origin starts behaving differently is worth more here than a one-time scan ever will be.
The domain in this story didn't announce that it had changed hands. Nothing about it did, from the outside. That is exactly why this class of risk needs tooling built to notice it, rather than a policy review that happens once and is trusted indefinitely. That was the same mistake, at a larger scale, that put the domain in an allowlist in the first place.