How polyfill.io slipped past hospital tag reviews that checked each script only once

The week

In late June 2024, a patient opening a hospital’s website on a phone to book an appointment could land instead on a gambling site. Nothing on the hospital’s servers had been hacked. The problem was a small piece of borrowed code the website had trusted for years.

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. JavaScript is the programming language that makes web pages interactive: menus that open, forms that check your entries, buttons that respond. A “polyfill” is a bit of JavaScript that fills gaps in older web browsers, teaching them to do things newer browsers do on their own. Rather than store that code themselves, many websites simply pointed to polyfill.io and let it supply the code fresh on every visit.

That convenience was the weakness. The code polyfill.io was now serving redirected some mobile visitors to scam and gambling sites, and was written to avoid detection by site administrators. The people most likely to check the site, its own staff, would see nothing wrong.

The trusted service had changed hands. The domain, the web address itself, and its GitHub repository, the online home where the project’s code was kept, 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, two large internet infrastructure companies, had set up safe mirrors, clean copies sites could switch to. Many sites never made the switch.

Sansec reported more than 100,000 sites embedding the script. Google began warning advertisers, and on June 27 the domain was suspended by its registrar, the company that manages the domain name’s registration. That cut off the malicious code at its source.

The timing carried an irony for hospitals. 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. That guidance had pushed hospitals to scrutinize the code on their websites, and the ruling led some to wonder whether they could ease off. Polyfill.io arrived as a reminder that website code carries risks in more than one direction.

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. A tag is a small piece of third-party code added to a web page, usually to measure visits, run advertising or add a feature such as a chat window.

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, the public pages anyone can see without logging in, 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. First, though, how a modern web page is actually put together.

How a hospital web page is really built

Most executives think of their website as something the organization owns and publishes, like a brochure. In reality, a typical page is assembled on the fly in the visitor’s browser from many sources. The hospital’s own server sends the basic page. That page then contains instructions telling the browser to fetch other pieces from elsewhere: fonts from one company, an analytics tag from another, a scheduling widget from a third, a compatibility library from a fourth.

A hospital website works like a restaurant that has several dishes delivered, cooked, from approved outside kitchens each evening. If one kitchen changes hands and starts sending something different, the restaurant may not notice until a diner gets sick, and the diner blames the restaurant.

Every piece of JavaScript fetched this way runs with the same power as the hospital’s own code. It can change what the patient sees, read what they type into forms, or send them to another site. The browser does not distinguish between “the hospital’s code” and “code the hospital pointed to.” Both act on the hospital’s behalf.

Many of these external pieces are delivered through content delivery networks, or CDNs, services that keep copies of files on servers around the world so pages load quickly. Polyfill.io worked like this. Its appeal was that a single line on a page brought in exactly the right code for each visitor’s browser, with no maintenance by the website owner. The cost of that convenience was that the website owner no longer controlled what was delivered.

Take a mid-sized health system whose main website, patient portal login, online bill pay and appointment booking pages together reference a dozen or more external sources. Some were added by the marketing agency, some by the web developers who built the site years ago, some by vendors whose widgets were embedded. Nobody there has a single list of them, and nobody is responsible for noticing if one changes owner.

Why trusted code goes bad

Security teams describe this kind of event as a software supply chain attack. Instead of breaking into the target directly, the attacker compromises something the target already trusts and lets the target’s own systems deliver the harm.

There are several ways it happens. A supplier can be hacked. A maintainer’s account can be taken over. Or, as with polyfill.io, the asset can simply be bought. That last route is the hardest for customers to see, because nothing looks like an attack. The web address is the same. The code may stay the same for months. Then, one day, it changes.

Attackers favor these routes for the same reason shared suppliers are attractive in other industries: reach. One popular script embedded on a very large number of sites gives an attacker access to all of their visitors at once. Hospitals are not necessarily the target. They are simply among the many sites caught in the net, and their patients are among the people redirected.

This is why the question “is this script safe?” has no permanent answer. The better question is “who controls this script today, and would we know if that changed?”

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. Self-hosting means keeping a copy of the code on the hospital’s own servers rather than fetching it from someone else’s each time.

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. Open source software is code published freely for anyone to use; much of the internet runs on it, and much of it is maintained by small teams or single individuals who may move on, hand over or sell their projects. 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, the total set of places an attacker could get in, and improves page speed. Removal still needs testing on older phones and assistive technologies, such as screen readers used by people with visual impairments, 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. A hash is a short digital fingerprint calculated from a file’s contents; change even one character of the file and the fingerprint changes completely. Subresource integrity suits fixed library versions and does not suit scripts that vendors update often, because every legitimate update would change the fingerprint.

A content security policy limits which domains may serve scripts at all, so an injected reference to an unknown domain fails. The hospital is telling every visitor’s browser: code from these addresses may run, and nothing else.

Neither control covers everything. Some tags legitimately change daily, and tag managers, tools that let marketing teams add or change tags without involving developers, 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. A check run from an office desktop on the hospital’s own network might have seen a perfectly normal page.

Payment pages already have a deadline for this. PCI DSS, the security standard set by the payment card industry for anyone who takes card payments, requires in version 4.0 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, the normal scheduled process for changing a website. It also puts the privacy and compliance questions: whether the script read form fields or session data, the information that keeps a patient logged in, and whether that could 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 such a plan, a good day at the same health system might look like this. A monitoring alert fires overnight: a mobile visitor to the appointment page was sent to an unknown domain. By morning, the digital lead has traced it to an external library, replaced it with a self-hosted copy and confirmed the redirects have stopped. Privacy and legal staff review what the code could have read. By lunchtime, a short notice is on the website and the contact center has its talking points. On a bad day, without the plan, the same incident surfaces weeks later through patient complaints, and nobody is sure whose job it is.

A scam page behind the hospital’s front door

A compromised script on the appointment page puts patient trust, privacy obligations and card payments at risk at the same time.

Patient trust. The website and portal are now the front door for many patients. A front door that sometimes leads to a scam undermines confidence in every digital service the hospital offers, including those it relies on to reduce costs, such as online scheduling and bill pay.

Privacy and legal exposure. A script that can redirect a patient can also, in principle, read what they type. Whether an incident becomes a reportable privacy event depends on what the code did, which is why the response plan needs privacy and legal input from the start.

Payments. Card payment pages already face specific requirements. Failing them is a compliance problem with the hospital’s payment providers, as well as a technical gap.

Reputation. Patients do not distinguish between the hospital’s code and code from a supplier. When something goes wrong on the hospital’s page, the hospital owns it.

Governance. Above all, polyfill.io shows that a one-time approval is not the same as ongoing control. That principle applies to every supplier relationship, websites included.

Control that outlasts the approval

A year later, the same health system keeps a short list of every external domain allowed to serve code to its patient-facing pages, each with a named owner and a reason. Commodity libraries are self-hosted, and outdated compatibility code has been removed after testing on older phones and screen readers. Fixed libraries carry integrity fingerprints, and a content security policy blocks anything not on the list. An external monitoring service loads key pages every day as a patient on a phone would, and alerts the digital team to new domains, changed code or unexpected redirects. The incident plan names a malicious third-party script as a scenario, gives the digital lead authority to pull a tag the same day, and includes a ready-to-use message for patients and contact center staff.

The habits that leave the gap open:

• Approving once, forever. A script approved years ago is trusted today without anyone checking who now controls it.
• Looking only outward. Reviews focus on what data leaves, and miss what code arrives.
• Testing from the office. Checks run on the corporate network, on a desktop, miss attacks aimed at patients on phones.
• Leaving tags to the agency. Marketing partners add code that nobody else knows about.
• No authority to act fast. The team that spots a problem must wait for a release cycle to fix it.
• Forgetting the patient message. The technical fix happens, but patients and contact center staff are left guessing.

Who controls the code on the front door

• How many outside sources supply code to our patient-facing pages, and do we have a single list of them with an owner for each?
• Would we know if one of those sources changed owner tomorrow? Who is watching?
• Do we check what our pages actually deliver to a patient on a phone, from outside our network, and how often?
• If a patient reported being redirected to a scam site from our website, who would act, and how quickly could they remove the cause?
• Does our incident plan include a malicious third-party script, with privacy and legal questions built in?

The answers do not require deep technical knowledge to judge. They require someone to own the question of what runs on the hospital’s front door, and to keep owning it after the first approval. A good first step is modest: ask for the list of outside code sources on the five most-used patient pages, and see how long it takes to produce. The time it takes is itself an answer about how much control the organization really has.

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. That last point is the one that makes it so instructive. Many affected organizations had done nothing wrong in the conventional sense. Their systems were not breached. They had simply trusted a supplier whose identity changed underneath them.

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. By the government’s account, the new owner and the attacker were one and the same.

On tracking, HHS filed a notice of appeal of the Texas ruling in August 2024, but the ruling was not reversed, and the narrower position on unauthenticated pages stood. Class actions and state privacy laws kept tracking risk alive regardless. Hospitals that relaxed their reviews because of one court decision found that the legal pressure on what data leaves their websites had not gone away.

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. In effect, the payment industry turned the controls described here into an obligation for at least some pages.

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.

Approval is a moment; control is continuous. Any supplier whose code or service runs inside your customer experience deserves to be watched over time as well as vetted at the start.