What Happened
A Chinese company named Funnull acquired the polyfill.io domain and CDN service in February 2024. Soon after, the new owners injected malicious code into the JavaScript files served from cdn.polyfill.io. Over 100,000 websites using these scripts unknowingly delivered malware to their users. Sansec detected the attack when they observed a change in the domain's DNS records—polyfill.io was redirected to polyfill.io.bsclink.cn through a new CNAME record.
The malicious code executed in visitors' browsers, bypassing standard server-side monitoring. The attack continued until researchers and CDN providers publicized the compromise.
Timeline
February 2024: Funnull acquires the polyfill.io domain and CDN infrastructure. The service operates normally at first.
Date unknown: Attackers modify the JavaScript files served from cdn.polyfill.io to include malicious payloads. The timing of this change relative to the acquisition is unclear.
June 2024: Sansec researchers identify the malicious behavior and trace it to DNS changes. The polyfill.io domain now resolves through a CNAME to polyfill.io.bsclink.cn.
Post-disclosure: Major CDN providers and domain registrars take action. Many websites scramble to remove polyfill.io references from their code.
Which Controls Failed or Were Missing
No Subresource Integrity (SRI) checks: The affected websites loaded third-party scripts without SRI hashes. When the CDN owner swapped the file contents, browsers executed whatever code the CDN served.
Missing Content Security Policy (CSP) restrictions: Sites either ran without CSP headers or configured them to allow inline scripts and unsafe-eval. Many policies trusted the polyfill.io domain explicitly, which became ineffective once the domain changed hands.
No vendor change monitoring: Development teams didn't track ownership changes for their third-party dependencies. A domain acquisition is a public event—registrar records change, WHOIS data updates, and often press releases follow. None of these signals triggered a security review.
Lack of script inventory: Many organizations couldn't quickly answer "which of our properties load from polyfill.io?" They discovered their exposure only after the attack went public and had to audit production sites manually.
Absent fallback strategy: Sites loading polyfills from the compromised CDN had no local copies or alternative sources configured. When they needed to switch, they faced an emergency rewrite instead of flipping a config flag.
What the Relevant Standards Require
PCI DSS v4.0.1 Requirement 6.4.3 states: "All payment page scripts that are loaded and executed in the consumer's browser are managed as follows: (a) A method is implemented to confirm that each script is authorized, (b) A method is implemented to assure the integrity of each script, (c) An inventory of all scripts is maintained with written justification as to why each is necessary."
SRI hashes satisfy part (b). You add an integrity attribute to your script tag:
<script src="https://cdn.example.com/lib.js"
integrity="sha384-ABC123..."
crossorigin="anonymous"></script>
If the file content changes, the hash won't match, and the browser refuses to execute it. This control works whether the CDN is compromised, a network attacker modifies the response, or a caching layer serves stale malicious content.
Part (c) requires you to document every script. For each entry, you need to know: where it loads from, what it does, who owns the source, and why you need it. When polyfill.io changed hands, teams with a proper inventory could search for "polyfill.io" and get a complete list of affected pages.
OWASP ASVS v4.0.3 Section 14.2.3 requires: "Verify that if client-side assets, such as JavaScript libraries, CSS, or web fonts, are hosted externally on a Content Delivery Network (CDN) or external provider, Subresource Integrity (SRI) is used to validate the integrity of the asset."
ISO 27001 Annex A.8.30 covers outsourcing: "Information security requirements for use of cloud services and other forms of outsourced ICT services shall be agreed with the suppliers and monitored." This includes understanding who operates your suppliers and what happens if they get acquired.
Lessons and Action Items for Your Team
Implement SRI for all external scripts today. Start with payment pages if you handle cards, then expand to authentication flows and any page processing user input. Generate hashes using:
curl https://cdn.example.com/lib.js | openssl dgst -sha384 -binary | openssl base64 -A
Add the result to your script tag's integrity attribute. Test in staging first—if the CDN uses dynamic content or version negotiation, SRI will break your site.
Build a third-party script inventory. Create a spreadsheet with columns: script URL, hash, purpose, owner, pages that load it, date added, and reviewer. Update it whenever you add a new external dependency. Your PCI DSS audit will ask for this document. Have it ready.
Set up domain ownership monitoring. Use a WHOIS monitoring service or build a script that checks registrar data monthly for your critical third-party domains. When ownership changes, trigger a security review. The polyfill.io acquisition was public information—teams just weren't watching.
Deploy Content Security Policy headers. Start in report-only mode:
Content-Security-Policy-Report-Only: script-src 'self' https://trusted-cdn.com; report-uri /csp-reports
Review the violation reports for a week. You'll find scripts you forgot about and inline event handlers that need refactoring. Once you've cleaned up, switch to enforcing mode by dropping the -Report-Only suffix.
Host critical polyfills locally. Modern browsers support most JavaScript features that polyfills used to provide. Run a compatibility check against your user analytics. If 95% of your traffic comes from browsers that support the features natively, you don't need the polyfill at all. For the remaining 5%, serve a local copy that you control and hash.
Practice your cutover procedure. Pick one external script dependency and document how you'd switch to a self-hosted version in under an hour. Write the steps: where to download the file, which config files to update, how to deploy the change, how to verify it worked. Run through it in staging. When the next supply chain incident hits—and it will—you'll execute instead of scrambling.
The polyfill.io attack succeeded because it exploited trust that had no technical enforcement. Your script tags trusted the domain. Your browser trusted the response. Nobody verified that the code being executed matched the code you'd reviewed. SRI and CSP exist specifically to break this chain of blind trust. Implement them before your CDN changes hands.
