Réponse rapide : l'attaque de la chaîne d'approvisionnement Polyfill.io a commencé lorsque le domaine polyfill.io, très largement intégré, a été vendu à Funnull en février 2024 et a commencé à servir du JavaScript malveillant dès juin. cside a été le premier à signaler l'ampleur réelle de l'attaque : plus de 490 000 sites web, et non les 100 000 que presque tous les médias ont repris. Ce chiffre inférieur correspondait simplement à l'endroit où l'outil de recherche cessait de compter. Un an plus tard, le Trésor américain a sanctionné Funnull pour cette opération. Voici la chronologie complète, ce que faisait le code, et comment le trouver et le supprimer.
L'attaque Polyfill.io est l'un des incidents de chaîne d'approvisionnement dans le navigateur les plus clairs jamais documentés. Un utilitaire gratuit et de confiance était installé sur des centaines de milliers de sites depuis des années. De nouveaux propriétaires l'ont transformé en surface d'attaque du jour au lendemain. Aucun propriétaire de site n'a changé une ligne de code, et pourtant leurs visiteurs ont été exposés.
Cette page rassemble toute l'histoire en un seul endroit : une chronologie datée, la vérité derrière le chiffre des « 100 000 sites », ce que la charge utile faisait réellement, le CVE, les sanctions contre Funnull qui ont suivi, et une checklist de nettoyage pratique. Pour aller plus loin, chaque section renvoie à nos articles d'origine de 2024 et 2025.
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. Le fait que cside ait mis en lumière le vrai chiffre de 490 000+ est la correction dont le récit public avait besoin, et le comptage indépendant de 384 773 hôtes par Censys le 2024-07-02 confirme que l'échelle dépassait largement 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é côté client
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.
