How polyfill.io slipped past hospital tag reviews that checked each script only once
Hospital script reviews were built after 2022 to stop patient data leaving through tracking tags. Polyfill.io showed the opposite risk: approved code that changed after approval and sent patients elsewhere. Managing it takes checks on the source, the content and the response.
Looking Back revisits one week at a time, from January 2020 to today, and asks what it meant for the banks, health systems and public agencies we serve. The series was written in 2026, with the benefit of hindsight, and each article says which week it looks back on.
The week
On June 25, 2024, the security firm Sansec reported that polyfill.io, a long-used service that delivered JavaScript compatibility code to websites, was serving malicious code. The code redirected some mobile visitors to scam and gambling sites, and was written to avoid detection by site administrators. The domain and its GitHub repository had been sold to a new owner in early 2024. The project’s original author had warned sites to stop using it, and Cloudflare and Fastly had set up safe mirrors. Sansec reported more than 100,000 sites embedding the script. Google began warning advertisers, and the domain was suspended by its registrar on June 27. Five days before Sansec’s report, a federal court in Texas had vacated part of HHS’s guidance on tracking technologies, in a case brought by the American Hospital Association.
Earlier in this series we described how HHS’s December 2022 bulletin exposed a governance gap. The tags on hospital websites belonged to marketing teams and agencies, outside the controls applied to other systems that touch patient data. Many health systems closed that gap in 2023 and early 2024. They built script inventories, named owners and set up review boards. Those reviews asked one question at one moment: what data does this tag send out, and is that allowed? The Texas ruling on June 20 narrowed the answer for unauthenticated pages, and some organizations considered relaxing their reviews. Polyfill.io, days later, showed a risk the reviews were not designed for. The danger was code coming in, not data going out. The script had been approved years earlier as harmless plumbing. Then it changed, with no action by the hospital at all. Three checks address that gap, each at a different point: the source a script loads from, the content it delivers on each visit, and the response when a patient-facing page misbehaves.
The source
A script loaded from a third-party domain runs whatever that domain serves today. The approval granted to it was an approval of whoever operated the domain at the time. Polyfill.io changed owners in early 2024 and nothing on a hospital’s page changed. The trust relationship moved anyway.
The control is to treat external script sources as suppliers. Each domain that serves code to a patient-facing page should be on a short list, with a named owner and a reason it cannot be self-hosted. For commodity libraries such as compatibility shims, fonts and common frameworks, self-hosting removes the dependency entirely. The hospital then decides when the code changes. Some services must load externally, such as a scheduling widget or a payment form. For those, the contract should require notice of any change in ownership or hosting. The vendor also belongs in third-party risk review like any other supplier. Ownership changes in open source projects and small services are often public. Someone needs to be watching for them.
Many compatibility libraries are also unnecessary now. Polyfills were added to support browsers that most patients no longer use. Removing them shrinks the attack surface and improves page speed. Removal still needs testing on older phones and assistive technologies, since a broken appointment page is its own patient harm.
The content
Even a trusted source can be compromised. The second check confirms that what the browser receives is what was approved. Subresource integrity lets a page specify a cryptographic hash for a script, and the browser refuses the script if its contents differ. It suits fixed library versions and does not suit scripts that vendors update often. A content security policy limits which domains may serve scripts at all, so an injected reference to an unknown domain fails.
Neither control covers everything. Some tags legitimately change daily, and tag managers can load new code without a page change. That gap calls for monitoring of what is actually delivered. A service or in-house job loads key pages as a patient would, on mobile and desktop. It records every script and its behavior, and alerts on new domains, changed code or unexpected redirects. Polyfill’s code targeted mobile users and avoided administrators. Monitoring therefore has to behave like a patient on a phone, outside the corporate network.
Payment pages already have a deadline for this. PCI DSS version 4.0 requires an inventory and authorization of scripts on payment pages, integrity assurance, and a mechanism to detect unauthorized changes. Those requirements became mandatory on March 31, 2025. A health system can extend the same tooling to scheduling, portal login and price transparency pages at modest extra cost.
The response
The third check is what happens when a patient-facing page misbehaves. Most hospital incident plans assume an internal compromise: a server, an account, a database. A malicious third-party script compromises the patient’s experience without touching hospital systems. Unless the plan names it, nobody may treat it as an incident.
A workable plan names the triggers: a monitoring alert, a patient complaint about an odd redirect, or a public advisory about a library. It gives the digital team authority to pull a tag or block a domain within hours, without waiting for a release cycle. It also asks the privacy and compliance questions. Did the script read form fields or session data? Could that create a reportable event under HIPAA or state law? Organizations should check with counsel on those determinations.
Patients need a clear message too. A patient sent from a hospital link to a scam page may distrust the next legitimate request to log in or pay. A short notice on the website and in the portal, with what happened and what the hospital will never ask for, protects the digital front door. Contact center staff should get a script the same day, because that is where confused patients will call first.
With hindsight
Polyfill.io was contained within days once infrastructure providers and the registrar acted. It became a standard example of a dependency turning hostile through a change of ownership, with no breach of the website owner. In May 2025 the Treasury sanctioned Funnull Technology, a Philippines-based company, and said it had bought the code repository and altered it to redirect visitors to scam and gambling sites.
On tracking, HHS withdrew its appeal of the Texas ruling in August 2024, so the narrower position on unauthenticated pages stood. Class actions and state privacy laws kept tracking risk alive regardless. The PCI DSS script requirements took effect on March 31, 2025, and pushed many organizations that take card payments online to build script inventories and change detection. Similar package hijacks followed in other parts of the software supply chain. The organizations best placed were those that treated each external script source as a supplier and monitored pages the way a patient experiences them.