Polyfill supply chain attack hits 100K+ sites

Original Article ↗ Hacker News Discussion ↗

A popular JavaScript polyfill service, polyfill.io, was quietly sold to a new owner and later caught injecting mobile-targeted malware via its CDN endpoint, impacting tens of thousands of websites. Commenters use the incident to highlight the risks of loading third‑party scripts, the limits of defenses like Subresource Integrity for dynamically generated code, and the obsolescence of old performance assumptions about shared CDNs and cross-site caching. Many argue for self‑hosting dependencies, stricter Content Security Policies, and better incentives for long‑term open‑source maintenance to reduce similar supply‑chain risks.

Nature of the polyfill.io compromise

  • Polyfill.io domain and repo changed hands, then started conditionally injecting malicious JS into responses from cdn.polyfill.io.
  • Payload targeted first‑time requests from mobile user agents coming via ad referrers, then loaded ga.js from a lookalike analytics domain and redirected to gambling/malicious sites.
  • Code is heavily obfuscated and tries to detect unsuitable environments; in some cases it allocates large memory to freeze devices.
  • Only clients are infected; origin servers using the script remain clean, which some note many devs may not intuitively realize.

Risks of third‑party JS and public CDNs

  • Strong consensus: including JS from arbitrary third‑party domains is “playing with fire,” especially when the provider can dynamically generate content based on user agent.
  • Polyfill’s dynamic nature makes Subresource Integrity (SRI) impractical; returned bytes vary per UA and over time.
  • Several commenters argue this pattern effectively hands full control of the browser to the CDN operator.
  • Shared-CDN caching benefits are largely obsolete due to cache partitioning and modern protocols; external CDNs may now hurt performance compared to first‑party hosting.

Recommended mitigations (developers)

  • Remove polyfill.io entirely; many say modern browsers make most polyfills unnecessary.
  • If legacy support is needed:
    • Self-host static polyfill bundles or vendor them via package managers.
    • Use alternatives hosted by trusted CDNs only if you have a contractual relationship and still prefer self‑hosting when possible.
  • Use SRI wherever content is static, plus Content Security Policy with narrowly justified exceptions.
  • Prefer vendoring and internal artifact repositories; however, some warn vendoring without active updating can lock in old vulnerabilities.

Recommended mitigations (end users)

  • Block polyfill.io (and related malicious domains) via:
    • uBlock Origin filters, NoScript, or similar extensions.
    • DNS-level blocks (Pi-hole, /etc/hosts overrides).
  • Note that uBlock lists were updated quickly; browsers’ built‑in blocklists mainly target phishing, not all such abuse.

Open source incentives & governance

  • Discussion about maintainers’ burnout and eventual “sellout” as almost inevitable given lack of funding and appreciation.
  • Debate over whether this is best framed as a “supply chain attack” versus foreseeable consequence of trusting unpaid third parties.
  • Some argue for paying for vetted, minimal dependency sets; others stress the need to reduce complexity and dependency sprawl overall.