En bref : chronologie de l'attaque Polyfill.io
- Les gros titres annonçaient 100 000 sites et c'était faux, car c'était le plafond par défaut de l'outil PublicWWW utilisé par les chercheurs, et l'empreinte réelle était bien plus large et concentrée sur des sites à forte confiance.
- cside a relancé la recherche au-delà du plafond et a trouvé plus de 490 000 sites embarquant polyfill.io, et Censys a compté indépendamment 384 773 hôtes affectés le 2 juillet 2024 avant que l'OFAC ne sanctionne Funnull le 29 mai 2025.
- Si un seul script fournisseur peut basculer en malveillant après avoir été approuvé depuis 2015, l'approbation à la source n'est pas un contrôle, donc surveillez le comportement à l'exécution à chaque session au lieu d'une simple signature unique.
Réponse rapide : une attaque de la chaîne d'approvisionnement web compromet une bibliothèque ou un service CDN tiers en lequel les sites légitimes font déjà confiance, puis utilise cette confiance pour exécuter du code contrôlé par l'attaquant dans le navigateur de chaque visiteur. L'attaque Polyfill.io est l'exemple documenté le plus clair : le service de polyfill de confiance a été acquis par Funnull en février 2024, est devenu malveillant en juin et a touché plus de 490 000 sites web avant que quiconque ne le remarque. Cette page explique comment la catégorie d'attaque fonctionne, documente l'incident Polyfill.io dans son intégralité et montre ce que votre site doit faire différemment.
Mise à jour 2026-07-19 : ajout d'une section sur les types d'attaques de la chaîne d'approvisionnement web et leur fonctionnement, ainsi que de nouvelles entrées FAQ. La chronologie et les données principales de Polyfill.io restent inchangées.
Qu'est-ce qu'une attaque de la chaîne d'approvisionnement web ?
Une attaque de la chaîne d'approvisionnement web compromet une bibliothèque JavaScript tierce, un CDN ou un service que les sites légitimes chargent et auxquels ils font confiance. Comme la page charge ce code comme si c'était le sien, l'attaquant obtient une exécution de code dans le navigateur de chaque visiteur sans toucher directement le site cible.
Une attaque de la chaîne d'approvisionnement web présente plusieurs propriétés caractéristiques. Le site victime a approuvé le script une fois, et l'attaquant hérite de cette confiance de façon permanente. La charge utile s'exécute côté client, après que le serveur a déjà envoyé la page, de sorte qu'une seule bibliothèque compromise se propage à chaque site qui la charge. Les WAF, les logs CDN et les scanners côté serveur ne voient aucune anomalie, car l'attaque se produit entièrement dans le navigateur.
Polyfill.io est le cas le plus documenté de cette catégorie. Un utilitaire gratuit et largement approuvé était présent sur des centaines de milliers de sites. De nouveaux propriétaires l'ont transformé en surface d'attaque du jour au lendemain, et aucun propriétaire de site n'a changé une seule ligne de code.
Comment fonctionnent les attaques de la chaîne d'approvisionnement web : quatre vecteurs principaux
Les attaques de la chaîne d'approvisionnement web partagent le même modèle d'abus de confiance, mais atteignent les sites via différents points d'entrée.
| Type d'attaque | Comment ça fonctionne | Comment l'attaque polyfill.io s'y inscrit |
|---|---|---|
| Prise de contrôle de CDN / domaine | L'attaquant acquiert un domaine que les sites chargent déjà via des balises de script | Funnull a acheté polyfill.io ; les sites ont continué à le charger sans aucun changement de code |
| Détournement de paquet npm | Un paquet populaire est pris en charge ou un typosquat est publié ; les pipelines CI téléchargent la version malveillante dans le build | Pas cette attaque, mais le risque est identique si le résultat du build intègre le paquet côté client |
| Compromission de dépôt open source | Le compte d'un mainteneur est pris en charge ; une version malveillante est envoyée au paquet officiel | Le dépôt GitHub de polyfill.io a changé de propriétaire avec le domaine |
| Confusion de dépendances | Un nom de paquet interne est enregistré dans le registre public ; le build télécharge par défaut la version de l'attaquant | Pas cette attaque, mais affecte les sites qui empaquettent et servent des dépendances depuis leur propre CDN |
Le fil conducteur : dans les quatre cas, du code que vous n'avez pas écrit finit par s'exécuter dans les navigateurs de vos utilisateurs avec le même niveau de confiance que votre propre JavaScript.
L'attaque de la chaîne d'approvisionnement web Polyfill.io : dossier complet
La version courte
- Le domaine polyfill.io a été vendu à Funnull en février 2024. Dès juin, il servait des redirections malveillantes.
- Il n'existe aucun CVE couvrant l'ensemble de l'incident ; le plus proche, CVE-2024-38526, se limite à l'outil de documentation pdoc qui chargeait polyfill.io, et non à l'attaque elle-même.
- L'ampleur réelle était de 490 000+ sites web, et non les 100 000 largement cités. Ce chiffre correspondait au plafond de résultats par défaut de PublicWWW. cside a signalé le vrai chiffre en premier.
- La charge utile capturée était une redirection mobile uniquement vers des sites d'escroquerie et de paris, conçue pour échapper aux chercheurs.
- Le 2025-05-29, l'OFAC a sanctionné Funnull et son administrateur Liu Lizhi.
- Au 2026-05-18, plus de 61 000 pages intègrent encore polyfill.io. Si la vôtre en fait partie, supprimez-le.
Chronologie complète (2009-2026)
| Date | Événement |
|---|---|
| 2009-2010 | Remy Sharp invente le terme « polyfill » ; l'idée se répand dans la communauté du développement web |
| 2014 | Andrew Betts crée le service polyfill.io aux Financial Times Labs ; une seule balise de script adapte les polyfills à chaque navigateur |
| 2014-10-28 | HTML5 devient une recommandation du W3C ; les navigateurs evergreen, à mise à jour automatique, rendent bientôt polyfill.io largement inutile |
| ~2023 | Le Financial Times confie le projet à son mainteneur de longue date, Jake Champion |
| Févr. 2024 | Le domaine polyfill.io et le dépôt GitHub sont vendus à Funnull, une société exploitée depuis la Chine |
| 2024-02-25 | Andrew Betts avertit publiquement : « Si votre site web utilise polyfill.io, supprimez-le IMMÉDIATEMENT » |
| 2024-02-29 | Cloudflare publie un miroir cdnjs sûr pour réduire le risque de chaîne d'approvisionnement ; Fastly avait mis en place son propre miroir quelques jours plus tôt |
| 2024-06-24 | Le chercheur japonais « piyokango » signale le comportement malveillant |
| 2024-06-25 | Sansec publie sa divulgation forensique ; cside publie le même jour et signale l'ampleur réelle de 490 000+ |
| 2024-06-26 | Cloudflare commence à réécrire automatiquement polyfill.io vers son miroir ; Google avertit les annonceurs concernés |
| 2024-06-27 | Namecheap suspend le domaine polyfill.io |
| 2024-07-02 | Censys compte de son côté 384 773 hôtes affectés |
| 2025-05-29 | L'OFAC sanctionne Funnull et l'administrateur Liu Lizhi ; le FBI relie 548 CNAMEs Funnull à plus de 332 000 domaines |
| 2026-05-18 | 61 593 pages intègrent encore polyfill.io |
Le chiffre des « 100 000 sites » était faux
Presque tous les articles sur cette attaque ont utilisé le même chiffre : environ 100 000 sites. Ce nombre est un artefact de l'outil, pas une mesure de l'attaque.
Les chercheurs, cside inclus, ont utilisé PublicWWW pour trouver chaque page contenant le snippet polyfill.io. PublicWWW plafonne les résultats à 100 000 par défaut. Ainsi, chaque comptage qui s'y appuyait s'arrêtait à « 100 000+ ». Lorsque nous avons poussé la recherche au-delà du plafond, le chiffre réel était de plus de 490 000 sites web.
Cela compte, car l'ensemble des sites affectés n'était pas aléatoire. Il était fortement concentré sur des destinations à fort trafic et à forte confiance : banques, sites gouvernementaux, grands éditeurs et marques connues. Annoncer « 100 000 » sous-estimait une attaque près de cinq fois plus grande. cside a révélé le véritable chiffre de plus de 490 000, corrigeant ainsi le récit public, et le comptage indépendant de 384 773 hôtes par Censys le 2024-07-02 confirme que l'ampleur dépassait largement les 100 000.
Ce que faisait réellement le code malveillant
Le comportement qui a été capturé, décodé et publié était une redirection. Le rapport forensique de Sansec du 2024-06-25 a montré que le script trafiqué envoyait certains visiteurs mobiles via un typosquat de Google Analytics, googie-anaiytics[.]com (notez les lettres permutées), puis vers des sites de paris sportifs et pour adultes.
C'est le savoir-faire opérationnel qui l'a rendu dangereux et difficile à repérer. La redirection :
- ne se déclenchait que sur les appareils mobiles, jamais sur ordinateur ;
- variait selon la région géographique et selon l'heure de la journée ;
- ne frappait chaque appareil ou IP qu'une seule fois, de sorte que ni une victime ni un chercheur ne pouvait la reproduire en rafraîchissant ;
- se taisait lorsqu'elle détectait un utilisateur administrateur ou la présence d'outils d'analyse web ;
- était dotée d'une armure anti-rétro-ingénierie.
Comme polyfill.io était par conception un service dynamique, l'opérateur pouvait servir du code propre à un visiteur et du code malveillant au suivant. La Subresource Integrity ne pouvait pas aider, car elle épingle le hash d'un fichier fixe, et ce service n'avait aucun fichier fixe. Le script s'exécutait en first-party dans l'origine de chaque site, il avait donc accès au DOM, aux formulaires et aux cookies de cette page, et il figurait sur les allowlists CSP de centaines de milliers de domaines de confiance.
N'était-ce qu'une redirection ? C'est la part honnête et non résolue. La désobfuscation indépendante de la charge utile récupérée n'a trouvé qu'une logique de redirection et rien d'autre : aucune capture de frappes, aucun vol d'identifiants. Mais la conception par requête signifie qu'une variante visant un seul visiteur de grande valeur n'a jamais besoin d'apparaître dans un scan public. La redirection est ce qui a été attrapé. Ce qui a pu s'exécuter d'autre durant ces mois ne peut être prouvé ni dans un sens ni dans l'autre. Nous avons détaillé l'argument de la capacité dans L'attaque Polyfill.io : bien plus qu'une simple attaque de redirection.
Pour le compte rendu complet de l'incident à l'époque, voir L'attaque Polyfill expliquée et notre rapport publié le même jour, Plus de 490 000 sites web ciblés dans une attaque de la chaîne d'approvisionnement web.
Existe-t-il un CVE pour l'attaque Polyfill.io ?
Aucun CVE unique n'est attribué à l'incident Polyfill.io lui-même. L'identifiant le plus proche dans la National Vulnerability Database est CVE-2024-38526, mais il se limite à pdoc, un outil de documentation d'API Python qui établissait un lien vers polyfill.io dans la documentation qu'il générait (corrigé dans pdoc 14.5.1). Il ne couvre pas cdn.polyfill[.]io ni l'ensemble plus large des sites affectés. Si vous gérez un programme de gestion des vulnérabilités, suivez cet incident par ses domaines affectés (cdn.polyfill[.]io, ainsi que les domaines liés bootcdn[.]net, bootcss[.]com, staticfile[.]net, staticfile[.]org et unionadjs[.]com) plutôt que par un seul CVE, et ne référencez CVE-2024-38526 que pour l'exposition liée à pdoc.
Le lien avec Funnull et les sanctions de 2025
Polyfill.io n'était pas un cas isolé. L'acheteur du domaine, Funnull, exploitait une opération bien plus vaste.
Le 2025-05-29, l'Office of Foreign Assets Control du Trésor américain a sanctionné Funnull Technology Inc. et son administrateur, Liu Lizhi. Le Trésor a relié l'infrastructure de Funnull à plus de 200 millions de dollars de pertes déclarées par des victimes aux États-Unis dans des escroqueries à l'investissement, le schéma souvent appelé pig butchering. Son avis décrivait le lien avec polyfill sans nommer le service : en 2024, Funnull « a acheté un dépôt de code utilisé par des développeurs web et a modifié de manière malveillante ce code pour rediriger les visiteurs de sites légitimes vers des sites d'escroquerie et des sites de jeux d'argent en ligne ».
Le même jour, le FBI a relié 548 CNAMEs Funnull à plus de 332 000 domaines. C'est du blanchiment d'infrastructure : louer un espace cloud et CDN réputé via des comptes illicites et le revendre à des escrocs pour que les sites malveillants paraissent légitimes et restent difficiles à supprimer. Nous avons couvert les sanctions et ce qu'elles signifient pour les équipes de sécurité dans Funnull sanctionnée : ce que l'attaque Polyfill.io a révélé sur le blanchiment d'infrastructure.
Qui est encore exposé
Les sanctions perturbent une société. Elles ne suppriment pas le code de votre site. Au 2026-05-18, PublicWWW listait encore 61 593 pages contenant polyfill.io, bien plus d'un an après la suspension du domaine.
Ce résidu est la véritable leçon. Les dépendances navigateur restent intégrées longtemps après le blocage d'un domaine, parce que les gens ne suppriment pas les choses. Chacune de ces pages pointe encore vers un domaine qui a déjà été instrumentalisé une fois.
Comment trouver et supprimer Polyfill.io aujourd'hui
Commencez par les pages qui touchent la connexion, le checkout, la création de compte, le paiement et les données personnelles.
- Recherchez
polyfill.iodans votre code source, vos tag managers, vos modèles CMS et vos anciens snippets, ainsi que les domaines liésbootcdn[.]net,bootcss[.]com,staticfile[.]net,staticfile[.]orgetunionadjs[.]com. - Supprimez les références. Les navigateurs modernes n'ont plus besoin de ces polyfills, donc la suppression est plus sûre que le remplacement par un miroir.
- Associez chaque script tiers restant à un propriétaire, un objectif, un périmètre de pages et un niveau d'accès aux données.
- Signalez les scripts qui chargent d'autres scripts, construisent des URLs dynamiquement ou se comportent différemment selon le user agent, la région ou la session.
- Utilisez la Subresource Integrity uniquement là où un script est statique et où le fournisseur prend en charge des hashes stables.
- Renforcez la Content Security Policy sur les parcours sensibles, en commençant en mode report-only.
- Surveillez ce que les scripts font réellement au runtime, afin qu'un changement de propriétaire ou une nouvelle charge utile soit visible lorsque de vrais utilisateurs chargent la page.
Ce que cette attaque enseigne sur la sécurité de la chaîne d'approvisionnement web
L'attaque Polyfill.io a fonctionné parce que la confiance était traitée comme permanente. Un script approuvé une fois a continué de s'exécuter après le changement de la société derrière lui et après le changement du code qu'il servait. Les logs serveur ne l'ont pas vu. Les questionnaires fournisseurs ne l'ont pas attrapé. Le navigateur l'a exécuté malgré tout.
Cet écart, entre l'inclusion approuvée et l'exécution au runtime, est exactement ce que cside a été conçu pour combler. cside travaille à la couche navigateur, là où les scripts tiers s'exécutent réellement. Il montre quels scripts se chargent sur les vraies pages, ce qu'ils appellent, comment ils changent, et s'ils tentent un comportement suspect comme des redirections inattendues ou des accès aux données. Dans le cas Polyfill.io, c'est cette vue au runtime qui signale une dépendance de confiance dès l'instant où elle devient hostile.
Le prochain polyfill.io est déjà quelque part sur le web, intégré et digne de confiance. La seule façon fiable de l'attraper est de surveiller ce que vos scripts font, pas seulement qui les a livrés. Sécurisez votre site gratuitement avec cside et voyez chaque script que vos utilisateurs chargent réellement.
