Kort samengevat: tijdlijn Polyfill.io-aanval
- Het aantal klopte niet: De koppen zeiden 100.000 sites en dat klopte niet, want dat was het standaardplafond van de PublicWWW-zoektool die onderzoekers gebruikten, en de werkelijke footprint was veel groter en zwaarder gericht op high-trust properties.
- De echte footprint: cside herhaalde de zoekopdracht voorbij dat plafond en vond meer dan 490.000 websites die polyfill.io laadden, en Censys telde onafhankelijk 384.773 getroffen hosts op 2 juli 2024 voordat OFAC Funnull op 29 mei 2025 sanctioneerde.
- Vertrouwen is geen controle: Als één vendor-script kwaadaardig kan worden na sinds 2015 vertrouwd te zijn, is bron-gebaseerde goedkeuring geen controle, dus monitor runtime-gedrag op elke sessie in plaats van te vertrouwen op een eenmalige akkoordverklaring.
Weinig tijd? Bekijk cside's in-browser Magecart- en skimmerblokkering. Dit dekt alles hieronder in één deployment.
Kort antwoord: een web supply chain-aanval compromitteert een bibliotheek of CDN-service van derden waarmee legitieme websites al vertrouwen hebben, en gebruikt dat vertrouwen vervolgens om aanvallergecontroleerde code in de browser van elke bezoeker te laten uitvoeren. De Polyfill.io-aanval is het meest gedocumenteerde voorbeeld: de vertrouwde polyfill-service werd in februari 2024 overgenomen door Funnull, werd in juni kwaadaardig en trof meer dan 490.000 websites voordat iemand het merkte. Deze pagina legt uit hoe de aanvalscategorie werkt, documenteert het Polyfill.io-incident volledig en laat zien wat je site anders moet doen.
Update 2026-07-19: een sectie toegevoegd over web supply chain-aanvalstypen en hoe de categorie werkt, plus nieuwe FAQ-vermeldingen. De kerntijdlijn en -gegevens van Polyfill.io zijn ongewijzigd.
Wat is een web supply chain-aanval?
Een web supply chain-aanval compromitteert een JavaScript-bibliotheek van derden, een CDN of een service die legitieme websites laden en vertrouwen. Omdat de pagina die code laadt alsof het zijn eigen code is, krijgt de aanvaller code-uitvoering in de browser van elke bezoeker zonder de doelsite direct aan te raken.
Een web supply chain-aanval heeft een aantal bepalende eigenschappen. De slachtoffersite heeft het script eenmalig goedgekeurd, en de aanvaller erft dat vertrouwen permanent. De payload wordt client-side uitgevoerd, nadat de server de pagina al heeft verzonden, waardoor één gecompromitteerde bibliotheek zich verspreidt naar elke site die hem laadt. WAF's, CDN-logs en server-side scanners zien geen enkele anomalie, omdat de aanval zich volledig in de browser afspeelt.
Polyfill.io is het meest gedocumenteerde geval in deze categorie. Een gratis, breed vertrouwde tool stond op honderdduizenden sites. Nieuwe eigenaren maakten er van de ene op de andere dag een aanvalsoppervlak van, en geen enkele site-eigenaar wijzigde één regel code.
Hoe web supply chain-aanvallen werken: vier belangrijkste vectoren
Web supply chain-aanvallen delen hetzelfde vertrouwensmisbruikmodel maar bereiken sites via verschillende ingangspunten.
| Aanvalstype | Hoe het werkt | Hoe de polyfill.io-aanval hierbij past |
|---|---|---|
| CDN-/domeinovername | Aanvaller verkrijgt een domein dat sites al laden via scripttags | Funnull kocht polyfill.io; sites bleven het laden zonder enige codewijziging |
| npm-pakkethijacking | Een populair pakket wordt overgenomen of een typosquat wordt gepubliceerd; CI-pipelines downloaden de kwaadaardige versie naar de build | Niet deze aanval, maar het risico is hetzelfde als de buildoutput het pakket client-side integreert |
| Compromittering van open source-repository | Maintaineraccount wordt overgenomen; een kwaadaardige release wordt naar het officiële pakket gepusht | De GitHub-repository van polyfill.io wisselde samen met het domein van eigenaar |
| Dependency confusion | Een interne pakketnaam wordt geregistreerd in het publieke register; de build download standaard de versie van de aanvaller | Niet deze aanval, maar treft sites die dependencies bundelen en serveren vanuit hun eigen CDN |
De rode draad: in alle vier gevallen eindigt code die jij niet hebt geschreven met uitvoering in de browsers van je gebruikers met hetzelfde vertrouwensniveau als je eigen JavaScript.
De Polyfill.io web supply chain-aanval: volledig dossier
De korte versie
- Het domein polyfill.io werd in februari 2024 verkocht aan Funnull. Tegen juni serveerde het kwaadaardige omleidingen.
- Er is geen incident-brede CVE; de identifier die er het dichtst bij komt, CVE-2024-38526, is afgebakend tot de documentatietool pdoc die polyfill.io laadde, niet de aanval zelf.
- De werkelijke omvang was 490.000+ websites, niet de breed geciteerde 100.000. Dat getal was de standaard resultaatlimiet van PublicWWW. cside rapporteerde het echte getal als eerste.
- De vastgelegde payload was een omleiding die alleen op mobiel werkte naar scam- en goksites, gebouwd om onderzoekers te ontwijken.
- Op 2025-05-29 sanctioneerde OFAC Funnull en zijn beheerder Liu Lizhi.
- Per 2026-05-18 bedden nog steeds meer dan 61.000 pagina's polyfill.io in. Als de jouwe daar een van is, verwijder het.
Volledige tijdlijn (2009-2026)
| Datum | Gebeurtenis |
|---|---|
| 2009-2010 | Remy Sharp bedenkt de term "polyfill"; het idee verspreidt zich door de webontwikkelaarscommunity |
| 2014 | Andrew Betts bouwt de polyfill.io-service bij Financial Times Labs; één scripttag past polyfills aan op elke browser |
| 2014-10-28 | HTML5 wordt een W3C Recommendation; evergreen, automatisch bijwerkende browsers maken polyfill.io al snel grotendeels overbodig |
| ~2023 | De Financial Times draagt het project over aan zijn langdurige beheerder, Jake Champion |
| Feb 2024 | Het domein polyfill.io en de GitHub-repository worden verkocht aan Funnull, een door Chinezen geleid bedrijf |
| 2024-02-25 | Andrew Betts waarschuwt publiekelijk: "Als je website polyfill.io gebruikt, verwijder het ONMIDDELLIJK" |
| 2024-02-29 | Cloudflare publiceert een veilige cdnjs-mirror om het supply chain-risico te verkleinen; Fastly zet enkele dagen eerder zijn eigen mirror op |
| 2024-06-24 | De Japanse onderzoeker "piyokango" signaleert het kwaadaardige gedrag |
| 2024-06-25 | Sansec publiceert zijn forensische onthulling; cside publiceert dezelfde dag en rapporteert de werkelijke omvang van 490.000+ |
| 2024-06-26 | Cloudflare begint polyfill.io automatisch te herschrijven naar zijn mirror; Google waarschuwt getroffen adverteerders |
| 2024-06-27 | Namecheap schorst het domein polyfill.io |
| 2024-07-02 | Censys telt onafhankelijk 384.773 getroffen hosts |
| 2025-05-29 | OFAC sanctioneert Funnull en beheerder Liu Lizhi; de FBI koppelt 548 Funnull-CNAMEs aan 332.000+ domeinen |
| 2026-05-18 | 61.593 pagina's bedden nog steeds polyfill.io in |
Het getal van "100.000 sites" was fout
Bijna elk rapport over deze aanval gebruikte hetzelfde getal: ongeveer 100.000 sites. Dat getal is een artefact van de tool, niet een meting van de aanval.
Onderzoekers, cside inbegrepen, gebruikten PublicWWW om elke pagina te vinden die de polyfill.io-snippet bevatte. PublicWWW beperkt resultaten standaard tot 100.000. Dus elke telling die erop steunde, eindigde op "100.000+." Toen wij de zoekopdracht voorbij die limiet uitvoerden, was het echte getal meer dan 490.000 websites.
Dit doet ertoe omdat de getroffen verzameling niet willekeurig was. Ze leunde sterk naar bestemmingen met veel verkeer en veel vertrouwen: banken, overheidssites, grote uitgevers en bekende merken. "100.000" rapporteren onderschatte een aanval die bijna vijf keer zo groot was. cside bracht het werkelijke cijfer van 490.000+ naar buiten en corrigeerde daarmee het publieke verslag, en de onafhankelijke telling van Censys van 384.773 hosts op 2024-07-02 bevestigt dat de omvang ver boven de 100.000 lag.
Wat de kwaadaardige code eigenlijk deed
Het gedrag dat werd vastgelegd, gedecodeerd en gepubliceerd, was een omleiding. Sansecs forensische rapport van 2024-06-25 liet zien dat het gemanipuleerde script sommige mobiele bezoekers via een nep Google Analytics-typosquat, googie-anaiytics[.]com (let op de verwisselde letters), naar sportweddenschap- en adultsites stuurde.
De tradecraft maakte het gevaarlijk en moeilijk te betrappen. De omleiding:
- vuurde alleen op mobiele apparaten, nooit op desktop;
- varieerde per geografische regio en per tijdstip;
- raakte elk apparaat of IP slechts één keer, zodat noch een slachtoffer noch een onderzoeker het bij een refresh kon reproduceren;
- werd stil zodra het een beheerder of de aanwezigheid van webanalytics detecteerde;
- werd geleverd met anti-reverse-engineering-pantser.
Omdat polyfill.io van nature een dynamische service was, kon de operator schone code aan de ene bezoeker en kwaadaardige code aan de volgende serveren. Subresource Integrity kon niet helpen, omdat het een hash van een vast bestand vastpint en deze service geen vast bestand had. Het script draaide first-party in de eigen origin van elke site, dus het had toegang tot de DOM, formulieren en cookies van die pagina, en het stond op de CSP-allowlists van honderdduizenden vertrouwde domeinen.
Was het alleen een omleiding? Dat is het eerlijke, onopgeloste deel. Onafhankelijke deobfuscatie van de herstelde payload vond omleidingslogica en niets anders, geen toetsaanslagvastlegging, geen diefstal van inloggegevens. Maar het ontwerp per verzoek betekent dat een variant gericht op één waardevolle bezoeker nooit in een publieke scan hoeft te verschijnen. De omleiding is wat werd betrapt. Wat er verder die maanden gedraaid kan hebben, valt op geen enkele manier te bewijzen. We hebben de capaciteitscasus in detail uiteengezet in De Polyfill.io-aanval: meer dan alleen een omleidingsaanval.
Voor het volledige incidentverslag van destijds, zie De Polyfill-aanval uitgelegd en ons rapport van dezelfde dag, Meer dan 490k websites doelwit van een web supply chain-aanval.
Is er een CVE voor de Polyfill.io-aanval?
Er is geen enkele CVE toegewezen aan het Polyfill.io-incident zelf. De identifier die er in de National Vulnerability Database het dichtst bij komt, is CVE-2024-38526, maar die is afgebakend tot pdoc, een Python-API-documentatietool die naar polyfill.io linkte in de documentatie die het genereerde (opgelost in pdoc 14.5.1). Het dekt cdn.polyfill[.]io of de bredere verzameling getroffen sites niet. Als je een kwetsbaarheidsprogramma beheert, houd dit incident dan bij via de getroffen domeinen (cdn.polyfill[.]io, plus de gerelateerde bootcdn[.]net, bootcss[.]com, staticfile[.]net, staticfile[.]org en unionadjs[.]com) in plaats van via één enkele CVE, en verwijs alleen naar CVE-2024-38526 voor pdoc-blootstelling.
De Funnull-connectie en de sancties van 2025
Polyfill.io was geen eenmalige zaak. De koper van het domein, Funnull, runde een veel grotere operatie.
Op 2025-05-29 sanctioneerde het Office of Foreign Assets Control van het Amerikaanse ministerie van Financiën Funnull Technology Inc. en zijn beheerder, Liu Lizhi. Treasury koppelde Funnulls infrastructuur aan meer dan 200 miljoen dollar aan door Amerikaanse slachtoffers gerapporteerde verliezen uit investeringsfraude, het patroon dat vaak pig butchering wordt genoemd. De aankondiging beschreef de polyfill-connectie zonder de service te noemen: in 2024 "kocht Funnull een coderepository die door webontwikkelaars werd gebruikt en wijzigde de code kwaadaardig om bezoekers van legitieme websites door te sturen naar scamwebsites en online goksites."
Dezelfde dag koppelde de FBI 548 Funnull-CNAMEs aan meer dan 332.000 domeinen. Dit is infrastructuurwitwassen: gerenommeerde cloud- en CDN-ruimte huren via illegale accounts en doorverkopen aan scammers zodat kwaadaardige sites legitiem lijken en moeilijk te verwijderen blijven. We behandelden de sancties en wat ze betekenen voor securityteams in Funnull gesanctioneerd: wat de Polyfill.io-aanval liet zien over infrastructuurwitwassen.
Wie er nog steeds blootgesteld is
Sancties verstoren een bedrijf. Ze verwijderen geen code van je site. Per 2026-05-18 vermeldde PublicWWW nog steeds 61.593 pagina's met polyfill.io, ruim een jaar nadat het domein was geschorst.
Die restanten zijn de echte les. Browserafhankelijkheden blijven lang nadat een domein is geblokkeerd ingebed, omdat mensen dingen niet verwijderen. Elk van die pagina's wijst nog steeds naar een domein dat al een keer is bewapend.
Hoe je Polyfill.io vandaag vindt en verwijdert
Begin met de pagina's die login, checkout, accountcreatie, betaling en persoonsgegevens raken.
- Doorzoek je broncode, tagmanagers, CMS-templates en oude snippets op
polyfill.io, plus de gerelateerde domeinenbootcdn[.]net,bootcss[.]com,staticfile[.]net,staticfile[.]orgenunionadjs[.]com. - Verwijder de verwijzingen. Moderne browsers hebben deze polyfills niet meer nodig, dus verwijderen is veiliger dan een mirror inwisselen.
- Koppel elk overgebleven script van derden aan een eigenaar, een doel, een page scope en een niveau van datatoegang.
- Markeer scripts die meer scripts laden, URLs dynamisch bouwen of zich anders gedragen per user agent, regio of sessie.
- Gebruik Subresource Integrity alleen waar een script statisch is en de provider stabiele hashes ondersteunt.
- Versterk je Content Security Policy op gevoelige flows, beginnend in report-only-modus.
- Monitor wat scripts runtime daadwerkelijk doen, zodat een eigenaarswissel of een nieuwe payload zichtbaar is wanneer echte gebruikers de pagina laden.
Wat deze aanval leert over web supply chain-beveiliging
De Polyfill.io-aanval werkte omdat vertrouwen als permanent werd behandeld. Een script dat één keer was goedgekeurd, bleef draaien nadat het bedrijf erachter was veranderd en nadat de code die het serveerde was veranderd. Serverlogs zagen het niet. Vendorvragenlijsten betrapten het niet. De browser voerde het toch uit.
Die kloof, tussen vertrouwde insluiting en runtime-uitvoering, is precies wat cside is gebouwd om te dichten. cside werkt op de browserlaag, waar scripts van derden echt draaien. Het laat zien welke scripts op echte pagina's laden, wat ze aanroepen, hoe ze veranderen en of ze verdacht gedrag proberen, zoals onverwachte omleidingen of datatoegang. In het geval van Polyfill.io is die runtime-view wat een vertrouwde afhankelijkheid markeert op het moment dat die vijandig wordt.
De volgende polyfill.io staat al ergens op het web, ingebed en vertrouwd. De enige betrouwbare manier om die te betrappen, is kijken naar wat je scripts doen, niet alleen naar wie ze heeft geleverd. Beveilig je site gratis met cside en zie elk script dat je gebruikers echt laden.
Voor een recenter voorbeeld van precies dit patroon in een DeFi-context, zie de Polymarket-supplychainaanval van $3M aan de clientzijde, waar een gecompromitteerd vendor-script wallets leegde via de eigen UI van het platform, zonder ook maar één smart contract aan te raken.
