News

Polyfill.io: the supply-chain breach that hijacked your Magento behind your back — 2026 front-end security audit

In June 2024 the polyfill.io domain was hijacked into an attack vector. Two years later, roughly one Magento store in five at Wimakeit still carries this dependency. Audit + 6 other common front-end vulnerabilities.

12 May 2026 7 min read
#B2B #Mage-OS #Magento #Magento 2.4 #Sécurité
Polyfill.io: the supply-chain breach that hijacked your Magento behind your back — 2026 front-end security audit

TL;DR

  • In June 2024, the polyfill.io domain was bought out and turned into an attack vector, exposing more than 100,000 sites including thousands of Magento stores.
  • Two years later, our audits at Wimakeit show that ~1 in 5 Magento stores we take over still carry a dependency on this domain or a similar unaudited third-party script.
  • In 2026, no Magento 2.4.4+ store needs external polyfills. Here is how to check in 5 minutes, what must disappear, and 6 other common front-end vulnerabilities.

1. The polyfill.io incident in 30 seconds

Polyfill.io was originally a legitimate open-source service created by the Financial Times to serve JavaScript polyfills (code that adds modern features to legacy browsers — primarily IE11).

In February 2024, the domain was acquired by the Chinese company Funnull. A few months later, in June 2024, security researchers (notably Sansec and Cloudflare) discovered that the service had begun injecting malicious JavaScript: redirects to online gambling sites, crypto scams, malware targeting mobile devices based on user-agent and geolocation.

Reactions came quickly:

  • Google de-indexed sites actively loading polyfill.io.
  • Cloudflare set up automatic redirection to their own clean mirror cdnjs.cloudflare.com/polyfill/.
  • Mozilla published a recommendation for immediate removal.
  • Namecheap, which hosted the DNS, temporarily suspended the domain.

The catch: affected websites were never notified. If you had <script src="https://polyfill.io/v3/polyfill.min.js"> in your <head>, you were loading malware without knowing it.

2. Why Magento was particularly exposed

Three structural reasons:

Magento 1 heritage. Many third-party modules built in the Magento 1 era (2015-2018) bundled polyfill.io "for safety" to support IE9-IE11. Those modules got ported to M2 without re-auditing the dependency.

Legacy themes. Old Luma themes, and several popular commercial themes from 2017-2020, include a polyfill.io call in default_head_blocks.xml or in a custom layout/default.xml.

Third-party admin stack. A few back-office extensions (notably custom WYSIWYG editors) load polyfill.io only on the admin side — invisible to customers, but exploitable against the admins themselves.

Net result: a Magento 2.4 store cleanly modernised on the front-end can still serve polyfill.io in its admin, and one of your team members can be targeted during a catalog management session.

Think you might be affected?

Free polyfill.io diagnostic in 15 minutes — we tell you whether your store still loads the poisoned script. No strings attached.

Request a diagnostic →

3. How to check whether your store is still affected

Server-side grep audit

# Source code
cd /var/www/vhosts/your-store.com/src
grep -ri "polyfill.io" pub/ app/ vendor/ | grep -v ".git"

# Deployed static assets
grep -ri "polyfill.io" pub/static/ 2>/dev/null

Client-side DOM audit

Open any page of your store, open DevTools → Network → JS, hard-reload (Ctrl+Shift+R), and filter for polyfill.

Cross-check with a console one-liner:

Array.from(document.scripts)
  .map(s => s.src)
  .filter(src => /polyfill|cdn\.|unpkg|jsdelivr/i.test(src))
  .forEach(src => console.log(src));

Anything that shows up needs auditing: those are scripts served from a third-party CDN you don't control.

4. Why polyfills are no longer needed in 2026

Magento Open Source 2.4.4+ and Mage-OS 2.0+ officially dropped IE11 support in 2022. Targeted browsers are Chrome 90+, Firefox 88+, Safari 14+, Edge 90+ (Chromium). All modern features (fetch, Promise, Object.entries, Array.from, optional chaining…) have been native in those browsers since at least 2020. No polyfill has any business being loaded on a properly maintained Magento 2.4.7 / Mage-OS 2.x.

One exception: if your store specifically targets a B2B market with a fleet of Windows 7 + IE11 machines (rare, mostly public sector and certain countries). In that case: self-host the polyfills via npm + local bundle, never via a third-party CDN.

5. Six other common front-end vulnerabilities

While you clean up polyfill.io, here is what we systematically find in our takeover audits:

  • Zombie jQuery from Magento 1. Third-party modules loading jquery-1.x.min.js (vulnerable to several known XSS). Magento 2.4 ships jQuery 3.6+ via requirejs.
  • Unaudited third-party trackers. Google Tag Manager, Hotjar, Clarity, etc.: a minimum GDPR/security audit requires knowing what those tags load.
  • Custom fonts hosted on non-EU CDN. Google Fonts loaded directly from fonts.googleapis.com = user IP transfer to the US (see LG München 2022 ruling). Host them locally.
  • Missing SRI. Subresource Integrity validates that a CDN-loaded script has not been modified. SRI would have blocked polyfill.io as soon as it changed.
  • eval() in minified bundles. Some third-party modules produce eval() calls that make static analysis impossible.
  • Missing security headers. Content-Security-Policy, X-Frame-Options, Referrer-Policy, Permissions-Policy: 2 out of 3 Magento stores in Belgium have none configured.

6. One-command audit

Here is the script we use as a pre-audit at Wimakeit. You can run it on your own Magento repo:

#!/bin/bash
# wmkt-audit-frontend.sh — quick front-end security pass for Magento 2.4+ / Mage-OS 2.x
ROOT="${1:-.}"
echo "=== polyfill.io references ==="
grep -rIn "polyfill\.io" "$ROOT/app" "$ROOT/vendor" "$ROOT/pub" 2>/dev/null \
  | grep -v ".git/" | head -20
echo "=== Other suspicious CDN includes ==="
grep -rIEn "src=[\"'][^\"']*(unpkg\.com|jsdelivr\.net|cdn\.jsdelivr|cdnjs\.cloudflare|google-analytics\.com/ga\.js)" "$ROOT/app" "$ROOT/vendor" 2>/dev/null \
  | head -20
echo "=== jQuery versions ==="
find "$ROOT" -name "jquery*.js" -type f 2>/dev/null | while read f; do
  ver=$(grep -o "jQuery v[0-9.]\+" "$f" | head -1)
  echo "$ver — $f"
done
echo "=== HTTP security headers (live check) ==="
read -p "Store URL (https://...): " URL
curl -sI "$URL" | grep -iE "content-security-policy|x-frame-options|strict-transport|referrer-policy|permissions-policy"

7. How Wimakeit handles these topics

Every module in our marketplace is audited against this checklist before release: zero third-party CDN dependency, no polyfill, SRI enabled on the few external scripts that remain, CSP-compatible, six-monthly audit of the composer.json + package.json dependency tree. Our Hyvä-ready modules go further: no jQuery at all (Tailwind + Alpine.js only), JS bundle divided by ten compared to an equivalent Luma module.

8. Conclusion

The polyfill.io episode is not an isolated case. It demonstrates that the front-end stack of a Magento store is as critical as its backend — and is too often neglected because it is less visible. A complete audit takes two to six hours depending on store size; the ROI on user trust, SEO (Google de-indexing) and GDPR compliance is immediate.

Want to be sure your Magento is clean?

Our team in Presles (Wallonia) runs Magento front-end security audits remotely or on-site, in English, French or Dutch.

Schedule an audit →

Further reading: Mozilla Web Security Advisory (June 2024), Cloudflare blog post, Sansec original disclosure, OWASP Top 10 A06:2021.

Share

Published 12 May 2026

Une question sur cet article ?

30 min, sans engagement, avec un interlocuteur technique senior.

Planifier un échange
Planifier un appel