Your website can be well designed, regularly updated and hosted on reliable infrastructure : yet still be affected by code controlled by someone else.
That is the uncomfortable lesson from the 2024 Polyfill.io attack. A popular JavaScript service was altered after its domain changed ownership, allowing malicious code to be delivered to websites that still loaded scripts from it. The incident affected more than 100,000 websites by some estimates and showed how a small, forgotten dependency can become a serious business risk.
This case study looks at what happened, why third-party code matters in web development, and what growing businesses can do to reduce their exposure.
What was Polyfill.io?
A polyfill is a piece of code that helps older browsers support newer web features. For years, developers could load Polyfill.js from the cdn.polyfill.io domain rather than hosting the file themselves.
A typical website might have included a line like this:
<script src="https://cdn.polyfill.io/v3/polyfill.min.js"></script>
The code often sat quietly in a website’s theme, template or build process. Once installed, it was easy to forget about : particularly if the website continued to work normally.
That convenience was the problem.
In February 2024, the Polyfill.io domain and related GitHub project were acquired by Funnull, a Chinese CDN operator. In June, security researchers reported that the service had been modified to deliver malicious JavaScript to some visitors.
The original website owner did not necessarily need to change anything for the risk to appear. If the site still requested the external script, it could receive a completely different response from the CDN.
What happened in the attack?
According to investigations by Sansec, Qualys and Censys, the modified service used conditional logic to make the malicious behaviour harder to detect.
The injected code reportedly focused mainly on mobile users. It could check characteristics such as the visitor’s device, browser and referrer before deciding whether to activate. Some users were redirected to sports betting or adult-content scam sites.
That selective behaviour mattered. A website owner testing the page on a desktop computer might see nothing unusual. Automated scanners and search engine crawlers could also receive a clean version of the script.
This was more than a nuisance redirect. Any external JavaScript loaded in a visitor’s browser can potentially interact with the page, influence what users see and, depending on its permissions and the surrounding application, access sensitive data or trigger further actions.
The domain was suspended by its registrar on 27 June 2024, which reduced the immediate threat. However, removing or suspending a malicious service does not remove the script reference from every affected website. Censys still identified hundreds of thousands of hosts referencing the domain shortly afterwards.
The key point is simple: the website itself may not have been hacked in the traditional sense. Its trusted supplier had changed.
Why third-party code is a web development risk
Modern websites rarely consist only of code written by the business or its web development team. They commonly rely on:
- JavaScript libraries
- WordPress plugins and themes
- Analytics and advertising tags
- Payment widgets
- Chat tools
- Consent-management platforms
- Fonts and content delivery networks
- Marketing automation scripts
- Open-source packages included in build tools
Each dependency can be useful. Collectively, they create a chain of trust.
When your website loads a script from another organisation, you are trusting that organisation to:
- Keep its systems secure.
- Maintain control of its domain.
- Review changes before publishing them.
- Protect its build and deployment process.
- Respond quickly if something goes wrong.
That trust can be reasonable, but it should not be invisible or permanent.
A website built five years ago may contain scripts that nobody remembers adding. A WordPress plugin may include an external library. A developer may have added a CDN link to solve an old browser compatibility issue that modern visitors no longer need.
“The code you did not write still becomes part of the experience you are responsible for.”
This is why third-party dependencies should be treated as part of your business’s IT infrastructure solutions : not merely as a developer detail.
The practical lessons for growing businesses
The Polyfill.io incident is not a reason to avoid every external service. It is a reason to understand what your website depends on and to manage those dependencies deliberately.
1. Build a dependency inventory
Start by creating a list of every external resource loaded by your website.
Search your templates, source code, WordPress theme, plugins, tag manager and compiled build files for external domains. Include scripts, stylesheets, fonts, APIs and embedded services.
For the Polyfill.io incident, this meant searching for references such as:
polyfill.iocdn.polyfill.iobootcdn.netbootcss.comstaticfile.netstaticfile.org
Do not rely only on a visual check of the website. A script may load only on a checkout page, mobile layout, landing page or logged-in area.
Your inventory should record:
- What the script does
- Which pages load it
- Who owns the service
- Whether it is still needed
- When it was last reviewed
- What would happen if it became unavailable
2. Review vendors and remove what you do not need
For every third-party service, ask whether the business still benefits from it.
If the answer is unclear, remove it in a test environment and check whether anything breaks. Modern browsers no longer require many of the compatibility features that older websites once depended on. In the Polyfill.io case, the original creator, Andrew Betts, advised website owners to stop using the service.
For WordPress Development projects, this review should include plugins and themes as well as manually added code. A plugin may be poorly maintained, have excessive permissions or load resources from a separate domain.
Choose providers with:
- Clear ownership
- Transparent security practices
- A history of regular updates
- Clear incident communication
- Appropriate support arrangements
3. Use Subresource Integrity where appropriate
Subresource Integrity (SRI) allows a browser to check that a fetched file matches a known cryptographic hash.
A simplified example looks like this:
<script
src="https://example.com/library.min.js"
integrity="sha384-examplehash"
crossorigin="anonymous">
</script>
If the file changes unexpectedly, the browser can refuse to load it.
SRI is particularly useful for static, versioned files that should not change without a deliberate release. It is less suitable for resources that are intentionally generated or personalised on every request.
Where possible, self-hosting stable libraries gives you even more control. You can review the file, scan it and update it through your own deployment process instead of allowing a third-party server to change what your customers receive.
4. Add a Content Security Policy
A Content Security Policy (CSP) tells the browser which sources are allowed to provide scripts and other content.
A carefully configured policy can limit scripts to trusted locations and reduce the impact of an unexpected injection. It may also help prevent inline scripts, unsafe evaluations and unauthorised connections.
CSP needs to be introduced carefully. A policy that is too strict can break legitimate website functionality, especially on sites with multiple marketing and payment integrations. Many organisations begin with reporting mode, review violations and then enforce the policy gradually.
This is one area where a web development team and an outsourced IT services provider can work together. The goal is to improve security without accidentally disabling a critical customer journey.
5. Monitor scripts after deployment
Security does not end when a website goes live.
Consider monitoring important external resources by:
- Checking them from different regions
- Testing both mobile and desktop user agents
- Recording file hashes
- Watching for unexpected domain or content changes
- Reviewing browser console errors
- Monitoring redirects and unusual traffic
- Scanning public pages for suspicious scripts
This matters because conditional malware may not appear during a single manual test. A monitoring process that checks different devices and locations gives you a better chance of spotting abnormal behaviour.
For WordPress sites, include plugin and theme changes in the same process. Updates should be tested, logged and deployed consistently rather than applied randomly during a crisis.
6. Patch and redeploy properly
If you find an affected reference, do not only delete it from the page you happened to notice.
Search the complete codebase, CMS database, theme files, plugins, build outputs and CDN configuration. Then:
- Remove the unsafe dependency.
- Update any package that includes it indirectly.
- Deploy the corrected version.
- Clear relevant caches.
- Retest key pages and conversion journeys.
- Review logs for suspicious redirects or errors.
The Polyfill.io issue also demonstrated the importance of indirect dependencies. Some software packages and documentation tools had included references to the service without every downstream user being aware of them.
Have an incident-response plan before you need one
If a third-party script is compromised, decide in advance who can remove it and how quickly.
Your plan should identify:
- The person responsible for website changes
- Your hosting and development contacts
- Who can access DNS, CDN and CMS controls
- The steps for disabling a script or integration
- How to preserve logs and evidence
- How to communicate with customers if required
- When legal, regulatory or cyber-insurance advice is needed
A simple emergency process might be: detect, contain, investigate, restore and communicate.
Do not wait for certainty before taking a safe temporary action. If a script is unnecessary and its provider is under investigation, removing it may be the sensible first step. Your team can then assess whether a trusted, self-hosted alternative is genuinely required.
Key Insights
- Third-party code is part of your attack surface. It should be documented and reviewed like any other business system.
- A working website can still be exposed. The Polyfill.io service changed upstream while many websites continued operating normally.
- Old dependencies create modern risk. Remove libraries and integrations that no longer serve a clear purpose.
- SRI and CSP reduce exposure. They are practical controls, although they need to be configured and maintained correctly.
- Monitoring must reflect real users. Test mobile, desktop and multiple locations where possible.
- Incident response should include web assets. Website code, CMS access, DNS, hosting and CDN controls all matter.
- Security and development work best together. Your website, hosting and wider IT infrastructure should not be managed as disconnected pieces.
What this means for your website
The Polyfill.io attack was a warning for every organisation that uses open-source software, external CDNs or embedded JavaScript. That includes small companies with a brochure website, online retailers and growing businesses running complex WordPress platforms.
You do not need to remove every useful integration. You do need to know what is running, who controls it and what happens if that trust changes.
At Picnic IT, we help growing businesses bring web development, hosting, security and IT support into a clearer long-term strategy. That can include secure WordPress Development, dependency reviews, managed hosting, monitoring and practical IT support for growing businesses.
If you are unsure what third-party code your website loads : or what would happen if one of your suppliers was compromised : contact Picnic IT. We can help you review the risks and build a more reliable foundation for growth.
For more guidance, explore our managed IT services, cybersecurity solutions and managed hosting services.
The most valuable website security improvement may not be a new feature. It may be finding the old dependency nobody remembers : and deciding whether it still deserves your trust.