Polyfill.io was a CDN service that delivered, on demand, JavaScript snippets to support modern features in older browsers. In February 2024 the domain was sold, and by June the scripts it served were redirecting visitors to fraudulent pages across more than a hundred thousand sites, which had simply kept the same
<script>tag they always had.
None of those sites were broken into. The <script> tag kept pointing at the same address it always had. The address changed owners. That is what makes this case uncomfortable: a security team could have done everything right on its own side and still shipped malicious code to its own customers.
The Case of Banco Horizonte Digital: A Story of Broken Trust
Banco Horizonte Digital is a composite example, not a customer. Its behavior, though, is what repeated itself across much of the affected list.
The bank had been loading Polyfill.io in its online banking portal for years, to keep older browsers working. In February, when cdn.polyfill.io changed hands, nothing happened. The service kept answering, the scripts kept loading, the portal kept working. Months later, a fraction of customers started landing on phishing pages that copied the login screen, and the credentials typed there went to the attacker's server.
Detection took weeks. Nobody at the bank had a list of what the portal loaded from outside, so there was nowhere to look. By the time the source turned up, thousands of customers had already passed through the fake page, and what was left was notifying them, answering regulators, and explaining publicly what had happened. None of those steps followed from a flaw in the bank's own code.
The Rise of Digital Supply Chain Attacks
The Polyfill.io case fits a larger pattern. Digital supply chain attacks have been climbing for years, and the curve has yet to bend.
Growth in Numbers
Supply chain attacks increased by more than 600% in 2021 compared to the previous year, as reported by PaloAlto Networks. In 2024, 75% of all software supply chains reported having suffered attacks (Resilience Forward). Gartner projected that by 2025, 45% of organizations worldwide would have experienced attacks on their software supply chains, three times the 2021 figure.
Detection Times
40% of supply chain attacks remain undetected for more than 6 months. Six months is enough for malicious code to reach internal systems, for the attacker to plant a second way in, and for data to leave slowly, with no traffic spike to draw attention. By the time the bill arrives, it covers half a year of attacker operations.
Digital supply chain attacks exploit the trust between suppliers and consumers, injecting malicious code into widely used libraries. Late detection allows the compromise to spread across millions of websites.
Anatomy of the Polyfill.io Attack
How Polyfill.io Worked
Polyfill.io was a legitimate CDN. It detected the visitor's browser and returned only the polyfills that browser needed, which saved bytes and solved compatibility with no work from the developer. Millions of sites pointed at it. That installed base is exactly what made the domain a target: buying one address bought access to all of them at once.
The Malicious Acquisition
In February 2024, the domain cdn.polyfill.io was acquired by an entity with malicious intent. The new owners changed nothing at first. The service kept serving the same scripts at the same speed, and anyone watching uptime saw no difference. The malicious code came later, mixed into the legitimate code.
Delivery was selective. Only some visitors got the redirect, picked by geolocation, device type, and time of day. A scanner running from a datacenter during business hours got the clean version. That is how the compromise ran for months before anyone published.
The Global Impact
More than 100,000 websites loaded the script, among them banks, e-commerce platforms, government portals, and healthcare systems. Millions of visitors passed through those pages in that period, and each one received whatever cdn.polyfill.io decided to send at that moment. Looking at the page, none of them could tell the script's origin had changed hands months earlier.
Attack Techniques Employed
The malicious scripts arrived obfuscated and blended into the legitimate code, which defeated static analysis and most automated tooling. The redirect fired only for a fraction of visitors, filtered by geolocation, device, and time of day.
The phishing pages copied the legitimate site field by field. Harvested credentials went to attacker-controlled servers, and cookies and local storage were manipulated to reinfect the visitor on a later visit, which is why partial cleanup did not hold.
The Polyfill.io case exposes several critical failures in the way organizations manage their attack surface and external dependencies.
Lack of a Dependency Inventory
The most common failure is also the simplest: the organization does not know what it loads. A third-party library goes into the project with no record, an external CDN gets added straight into the template, the version is never pinned, and the service provider never becomes a line on any list. Control can be argued about later. Before that, nobody protects what they do not know exists.
Absence of Continuous Monitoring
Even where a dependency was documented once, nobody goes back to look. A critical domain changes owners and no alert fires. The served script changes content and nobody compares the hash. An application starts talking to a domain it never talked to before and the traffic goes through. The polyfill.io window stayed open for months, and the window was not technical. It was procedural.
Implicit Trust
A popular service becomes a synonym for a safe service. A CDN that has existed for ten years goes in without review, a library with millions of downloads goes in without review, and past reputation is treated as a future guarantee. Polyfill.io had exactly that reputation in January 2024. In February, it had a new owner.
Slow Response Time
When the story broke, some organizations pulled the script the same day. Others took weeks, because they first had to find out which applications carried the tag. Without a written plan, response time becomes the time it takes to find whoever knows how to respond, and customer communication slips along with it.
How Attack Surface Management Prevents Supply Chain Attacks
Attack Surface Management (ASM) works on those four failures in the order they appear: find what exists, watch what changes, decide what matters, respond.
An ASM platform maps on its own what the organization loads from outside: CDNs, third-party libraries, versions in use, and the integrations some team shipped without going through security. In the Polyfill.io case, that inventory would have answered in seconds the question that stalled everyone for weeks: which of our sites load cdn.polyfill.io?
Change Monitoring
An inventory on its own goes stale. ASM watches what moves inside it. A WHOIS and DNS ownership change on a domain your application loads. A served script whose hash no longer matches last week's. New behavior in a JavaScript file that used to only read the DOM and now opens a connection outward. Any of those three signals would have surfaced in the Polyfill.io case, and the first of them appeared four months before the attack made the news.
Script Behavior Analysis
Some tools go past hash comparison and run the script in a sandbox to see what it does: a redirect nobody asked for, a read of a form field, a call to a domain outside the known list. That layer catches the compromised Polyfill.io even if the ownership change had slipped by.
Risk-Based Prioritization
Dependencies are not interchangeable. A script on the online banking login page and the same script on the corporate about page carry identical technical risk and impacts that do not compare. The work order falls out of four questions: how many users pass through there, what data moves on that screen, how easy the thing is to exploit, and what breaks if the dependency goes away. That is what lets a small team fix what hurts first.
Rapid and Coordinated Response
With the inventory in hand, response changes character. The list of affected assets comes out immediately, blocking the compromised dependency can be pushed by policy instead of ticket by ticket, and communication with customers and regulators goes out with a number instead of an estimate. The gap between remediating in a day and remediating in three weeks is almost never the fix. It is knowing where to apply it.
Continuous Supplier Validation
Supplier assessment tends to be a questionnaire answered once, at contract time. ASM replaces that with verification that runs on its own: third-party domain reputation against threat intelligence feeds, incident history, a certification that expired and nobody renewed. Trust re-checked every week is a different thing from trust signed in 2019.
Lessons Learned from the Polyfill.io Case
For Organizations
Two things change the outcome, and neither of them is buying a tool. The first is having the list of what your applications load from outside, kept current by automatic discovery rather than by spreadsheet. The second is treating that list as a living thing: somebody has to be told when an item on it changes owner, hash, or behavior.
The rest is defense in depth, and here the specifics matter more than the principle. A restrictive Content Security Policy limits where the browser will accept a script from. Subresource Integrity pins the hash of the loaded file, which solves the problem for fixed-content scripts and does not solve it for a CDN that assembles its response per browser. Run the response plan as a tabletop once a year, because incident day is a bad day to find out who has DNS access.
For the Industry
On the industry side, the hole is notification. When a domain that millions of sites load changes owners, no channel tells those sites. The transfer is a private commercial transaction and the buyer owes nothing to whoever depends on the service. Until that changes, every organization finds out on its own.
What is available today is more modest and already helps: publish indicators of compromise early, even with the analysis half done, and document the attacker's TTPs instead of only announcing that an attack happened.
Implementing Protection Against Supply Chain Attacks
Step 1: Complete Inventory
List what enters the page from outside: third-party JavaScript libraries in production, CDNs, external APIs, connected SaaS, installed plugins. Done by hand, that list is out of date the day it is finished. It has to come from continuous discovery.
Step 2: Technical Controls
CSP tells the browser where a script may come from. Configured properly, it drops the domain that showed up out of nowhere:
Content-Security-Policy:
default-src 'self';
script-src 'self' https://trusted-cdn.com;
connect-src 'self' https://api.trusted.com;
SRI pins the file's hash. If the content changes by a byte, the browser refuses to load it:
<script src="https://cdn.example.com/lib.js"
integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux..."
crossorigin="anonymous"></script>
Step 3: Continuous Monitoring
Compare the hash of external scripts on every run. Alert on new domains an application starts contacting. Block and log attempts to send form data outside the known list. It is a short list, and it covers most of what happened in the Polyfill.io case.
Step 4: Validation Processes
New dependencies come in with approval and a security review. Old dependencies get reviewed on a calendar, not when something breaks. Version bumps ship with tests. Dependencies nobody uses anymore get removed, and that last one is usually the easiest and the most forgotten.
Step 5: Response Plan
Write the procedure first: how to confirm the compromise, who isolates the dependency, who talks to customers, who talks to regulators. Test it in a simulation. A plan that has never been rehearsed takes about as long as no plan at all.
The Role of ASM in Prevention
The Polyfill.io case did not expose a new technique. It exposed that most organizations could not answer which third-party code was running on their own pages. Without that answer, the rest of the security program works in the dark.
ASM produces that answer and keeps it current. Asset discovery is the part that shows up in demos. The part that changes a team's week is the second one: knowing what changed, in the week it changed.
Conclusion
With 40% of supply chain attacks going more than 6 months undetected and 75% of organizations having already suffered an attack on their software supply chain, planning for the case where you get hit has stopped being pessimism. It is calendar math.
What is still under your control is the time between compromise and discovery. That time depends on something most companies do not have: a current list of what their applications load from outside, and someone who gets told when the list changes. If you cannot build that list today, start there.
References
- PaloAlto Networks - Supply Chain Attacks Frequency and Severity Stats
- Resilience Forward - 75% of Software Supply Chains Exposed to Cyber Attacks
- MITRE ATT&CK Framework - Supply Chain Compromise (T1195)
- NIST Cybersecurity Framework - Supply Chain Risk Management
- OWASP Top 10 - Using Components with Known Vulnerabilities