Polyfill.io: het supply-chain-lek dat uw Magento ongemerkt heeft gekaapt — front-end beveiligingsaudit 2026
In juni 2024 werd het polyfill.io-domein omgevormd tot een aanvalsvector. Twee jaar later sleept ongeveer één Magento-shop op vijf bij Wimakeit deze afhankelijkheid nog mee. Audit + 6 andere veelvoorkomende front-end-kwetsbaarheden.
TL;DR
- In juni 2024 werd het
polyfill.io-domein opgekocht en omgevormd tot een aanvalsvector, met meer dan 100 000 sites blootgesteld, waaronder duizenden Magento-shops. - Twee jaar later tonen onze audits bij Wimakeit aan dat ~1 op 5 Magento-shops die we overnemen, nog steeds een afhankelijkheid van dit domein of een vergelijkbaar niet-gecontroleerd extern script meeslepen.
- In 2026 heeft geen enkele Magento 2.4.4+-shop externe polyfills nodig. Hier is hoe u dit in 5 minuten controleert, wat moet verdwijnen, en 6 andere veelvoorkomende front-end-kwetsbaarheden.
1. Het polyfill.io-incident in 30 seconden
Polyfill.io was oorspronkelijk een legitieme open-sourcedienst van de Financial Times, bedoeld om JavaScript-polyfills te leveren (code die moderne functies aan oude browsers toevoegt, met IE11 voorop).
In februari 2024 werd het domein overgenomen door het Chinese bedrijf Funnull. Enkele maanden later, in juni 2024, ontdekten beveiligingsonderzoekers (met name Sansec en Cloudflare) dat de dienst voortaan kwaadaardig JavaScript injecteerde: omleidingen naar online gokwebsites, crypto-scams, malware gericht op mobiele apparaten op basis van user-agent en geolocatie.
De reacties waren onmiddellijk:
- Google haalde sites die actief
polyfill.iolaadden uit zijn index. - Cloudflare zette een automatische omleiding op naar hun eigen schone mirror
cdnjs.cloudflare.com/polyfill/. - Mozilla publiceerde een aanbeveling tot onmiddellijke verwijdering.
- Namecheap, dat de DNS hostte, schorste het domein tijdelijk.
Het probleem: getroffen websites werden nooit verwittigd. Als u <script src="https://polyfill.io/v3/polyfill.min.js"> in uw <head> had staan, laadde u malware zonder het te weten.
2. Waarom Magento bijzonder kwetsbaar was
Drie structurele redenen:
Magento 1-erfenis. Veel externe modules die in het Magento 1-tijdperk (2015-2018) werden ontwikkeld, integreerden polyfill.io "voor de zekerheid" om IE9-IE11 te ondersteunen. Die modules werden naar M2 geport zonder de afhankelijkheid opnieuw te bekijken.
Legacy-thema's. Oude Luma-thema's en enkele populaire commerciële thema's uit de periode 2017-2020 bevatten een polyfill.io-oproep in default_head_blocks.xml of in een aangepaste layout/default.xml.
Externe stack in de admin. Sommige back-office-uitbreidingen (met name aangepaste WYSIWYG-editors) laden polyfill.io alleen aan de adminzijde — onzichtbaar voor klanten, maar uit te buiten tegen beheerders zelf.
Resultaat: een Magento 2.4-shop die front-end netjes is gemoderniseerd, kan nog steeds polyfill.io serveren in zijn admin, en een van uw medewerkers kan tijdens een catalogusbeheer-sessie het doelwit worden.
Denkt u dat u getroffen bent?
Gratis polyfill.io-diagnose in 15 minuten — wij vertellen u of uw shop het besmette script nog laadt. Vrijblijvend.
3. Hoe u kunt controleren of uw shop nog getroffen is
Server-side grep-audit
# Broncode
cd /var/www/vhosts/uw-shop.be/src
grep -ri "polyfill.io" pub/ app/ vendor/ | grep -v ".git"
# Uitgerolde statische assets
grep -ri "polyfill.io" pub/static/ 2>/dev/null
Client-side DOM-audit
Open een willekeurige pagina van uw shop, open DevTools → Network → JS, herlaad (Ctrl+Shift+R) en zoek op polyfill in de filter.
Controleer ook met een console-oneliner:
Array.from(document.scripts)
.map(s => s.src)
.filter(src => /polyfill|cdn\.|unpkg|jsdelivr/i.test(src))
.forEach(src => console.log(src));
Alles wat verschijnt, moet worden gecontroleerd: het gaat om scripts die vanaf een externe CDN worden geserveerd die u niet beheert.
4. Waarom we in 2026 geen polyfills meer nodig hebben
Magento Open Source 2.4.4+ en Mage-OS 2.0+ ondersteunen IE11 officieel niet meer sinds 2022. De beoogde browsers zijn Chrome 90+, Firefox 88+, Safari 14+, Edge 90+ (Chromium). Alle moderne functies (fetch, Promise, Object.entries, Array.from, optional chaining…) zijn sinds minstens 2020 native in die browsers. Geen enkele polyfill heeft nog reden van bestaan op een correct onderhouden Magento 2.4.7 / Mage-OS 2.x.
De uitzondering: als uw shop specifiek mikt op een B2B-markt met een vloot Windows 7 + IE11-computers (zeldzaam, vooral overheidssector en bepaalde landen). In dat geval: host de polyfills zelf via npm + lokale bundle, nooit via een externe CDN.
5. Zes andere veelvoorkomende front-end-kwetsbaarheden
Terwijl u polyfill.io opruimt, dit is wat we ook stelselmatig terugvinden in onze overname-audits:
- Zombie-jQuery uit Magento 1. Externe modules die
jquery-1.x.min.jsladen (kwetsbaar voor diverse bekende XSS-aanvallen). Magento 2.4 levert jQuery 3.6+ via requirejs. - Niet-gecontroleerde externe trackers. Google Tag Manager, Hotjar, Clarity enz.: een minimale GDPR/security-audit vereist te weten wat die tags laden.
- Aangepaste lettertypes op niet-EU CDN. Google Fonts rechtstreeks van fonts.googleapis.com = overdracht van gebruikers-IP naar de VS (zie uitspraak LG München 2022). Host ze lokaal.
- SRI ontbreekt. Subresource Integrity valideert dat een vanaf een CDN geladen script niet is gewijzigd. Dat had polyfill.io geblokkeerd zodra het werd aangepast.
- eval() in geminifieerde bundles. Sommige externe modules produceren
eval()dat statische analyse onmogelijk maakt. - Ontbrekende security-headers.
Content-Security-Policy,X-Frame-Options,Referrer-Policy,Permissions-Policy: 2 op de 3 Magento-shops in België hebben er geen enkele geconfigureerd.
6. Audit in 1 commando
Hier is het script dat wij bij Wimakeit als pre-audit gebruiken. U kunt het op uw eigen Magento-repo draaien:
#!/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. Hoe Wimakeit met deze onderwerpen omgaat
Alle modules in onze marketplace worden vóór publicatie tegen deze checklist gecontroleerd: nul externe CDN-afhankelijkheden, geen polyfill, SRI ingeschakeld op de zeldzame externe scripts die overblijven, CSP-compatibel, halfjaarlijkse audit van de afhankelijkheidsboom in composer.json + package.json. Onze Hyvä-ready-modules gaan verder: helemaal geen jQuery (uitsluitend Tailwind + Alpine.js), JS-bundle gedeeld door tien tegenover een equivalente Luma-module.
8. Conclusie
Het polyfill.io-incident is geen geïsoleerd geval. Het toont aan dat de front-end-stack van een Magento-shop net zo kritiek is als de backend — en te vaak wordt verwaarloosd omdat hij minder zichtbaar is. Een volledige audit duurt twee tot zes uur afhankelijk van de grootte van de shop; de ROI op gebruikersvertrouwen, SEO (Google de-indexering) en GDPR-conformiteit is onmiddellijk.
Wilt u er zeker van zijn dat uw Magento clean is?
Ons team in Presles (Wallonië) voert Magento front-end security-audits uit op afstand of ter plaatse, in het Nederlands, Frans of Engels.
Audit inplannen →Verder lezen: Mozilla Web Security Advisory (juni 2024), Cloudflare-blogpost, oorspronkelijke Sansec-disclosure, OWASP Top 10 A06:2021.
Gepubliceerd op 12 mei 2026
Une question sur cet article ?
30 min, sans engagement, avec un interlocuteur technique senior.