In February 2024 the polyfill.io domain was acquired by a Chinese CDN company. On 25 June, cdn.polyfill.io began serving malicious JavaScript to the 100,000-plus sites that embedded it.
Nothing on any of those sites changed. No file was edited, no server was breached, and no site owner did anything wrong on the day. A dependency they had trusted for years simply started answering differently, because it had changed hands.
A dependency is not a file you copied once. It is a standing relationship with whoever controls that domain today.
- The point of this page
The payload was built to defeat anyone looking for it
The malicious code was conditional and evasive by design. It was generated per request from the HTTP headers, fired only on specific mobile devices, avoided visitors who looked like administrators, and delayed its own execution. Users who met the conditions were sent through a redirect chain — including a typosquatted domain impersonating Google Analytics — on to sports betting and adult sites.
Read that list again as a list of defences it defeats. A scanner does not present as a specific mobile device. An administrator checking the site is precisely who it hid from. A synthetic monitor does not wait around for a delayed payload. Fetching the file yourself and reading it tells you what it serves you, which was the point.
Every one of those evasions works against something that visits a site to check it. None of them works against telemetry from the real users it was targeting, because those users were the intended audience.
This is where Subresource Integrity genuinely cannot help
The standard advice for a third-party script is to pin it with Subresource Integrity, so the browser refuses to run it if the content does not match a known hash. It is good advice and it does not apply here.
Polyfill.io's entire purpose was to serve different code to different browsers — that is what a polyfill service does. The content was designed to vary per request, so there was no stable hash to pin. Anyone who has been told to "just use SRI" should understand why this class of dependency is exactly the one it cannot protect.
A Content Security Policy does not stop it either, and it is worth saying so plainly. The domain was already in every victim's allowlist. It had been a legitimate dependency for years. A policy that constrains where scripts come from permits it without hesitation, because the source never changed.
A week later, 380,000 hosts were still loading it
Cloudflare began automatically rewriting requests to the domain and serving a safe mirror the day after the story broke. Fastly stood up a mirror too. Google warned advertisers their landing pages might be affected. This was, by the standards of a web security story, extremely loud.
More than a week later, over 380,000 hosts were still embedding the malicious script.
That number is the actual finding. Not that an attack happened, but that hundreds of thousands of organisations could not act on front-page news because nobody could tell them whether they were affected. Answering "do we load this?" requires an inventory of what executes on your pages, and most teams do not have one.
What would have told you
Two things, and neither of them requires knowing about the attack in advance.
The first is simply the inventory. A list of every script executing across your estate, gathered from real browsers, turns the week of June 25th from a research project into a search box. Most of the 380,000 were not ignoring the news; they could not answer the question.
Browsers already tell us the answer. With CSP Integrity, every script a real browser executes is reported to us with a content-addressed fingerprint alongside its URL — so the same address serving different code is a different fingerprint, arriving from the session where it actually ran. A service built to vary its output has no single archivable version, but it cannot vary it without the fingerprints moving, which is why the question “what exactly was on the page at 14:00?” has an answer rather than a shrug.
The second is the destination. The redirect chain and the hosts it passed through were new, and a page that suddenly starts sending users somewhere it has never sent them before is exactly what Data Watch is watching for.
How we can help
You don't need a mature Content Security Policy to start. Script Watch gives you the inventory of what executes on your pages, Data Watch gives you the destinations receiving data from them, and CSP Integrity adds the fingerprint of each script as it ran. One line of code or config to deploy.
Reach out to sales@report-uri.com if you want a demo or a trial with no commitment.
