Resposta rápida: o ataque à cadeia de suprimentos do Polyfill.io começou quando o domínio polyfill.io, amplamente incorporado, foi vendido à Funnull em fevereiro de 2024 e passou a servir JavaScript malicioso em junho. A cside foi a primeira a relatar a dimensão real do ataque: mais de 490.000 sites, não os 100.000 que quase todos os veículos repetiram. Esse número menor era apenas onde a ferramenta de busca parava de contar. Um ano depois, o Tesouro dos EUA sancionou a Funnull pela operação. Esta é a linha do tempo completa, o que o código fazia e como encontrá-lo e removê-lo.
O ataque ao Polyfill.io é um dos incidentes de cadeia de suprimentos no navegador mais claros já registrados. Uma utilidade gratuita e confiável ficou em centenas de milhares de sites por anos. Novos donos a transformaram em uma superfície de ataque da noite para o dia. Nenhum proprietário de site mudou uma linha de código, mas seus visitantes foram expostos.
Esta página reúne a história inteira em um só lugar: uma linha do tempo datada, a verdade por trás do número de "100.000 sites", o que o payload realmente fazia, o CVE, as sanções contra a Funnull que se seguiram e uma lista prática de limpeza. Para aprofundamentos, cada seção remete às nossas reportagens originais de 2024 e 2025.
A versão curta
- O domínio polyfill.io foi vendido à Funnull em fevereiro de 2024. Em junho, já estava servindo redirecionamentos maliciosos.
- Não existe um CVE para todo o incidente; o mais próximo, CVE-2024-38526, tem como escopo a ferramenta de documentação pdoc que carregava o polyfill.io — não o ataque em si.
- A dimensão real era de 490.000+ sites, não os 100.000 amplamente citados. Esse número era o limite de resultados padrão do PublicWWW. A cside relatou o número real primeiro.
- O payload capturado era um redirecionamento apenas em dispositivos móveis para sites de fraude e apostas, construído para evadir pesquisadores.
- Em 2025-05-29, a OFAC sancionou a Funnull e seu administrador Liu Lizhi.
- Em 2026-05-18, mais de 61.000 páginas ainda incorporam o polyfill.io. Se a sua é uma delas, remova-o.
Linha do tempo completa (2009–2026)
| Data | Evento |
|---|---|
| 2009–2010 | Remy Sharp cunha o termo "polyfill"; a ideia se espalha pela comunidade de desenvolvimento web |
| 2014 | Andrew Betts cria o serviço polyfill.io no Financial Times Labs; uma única tag de script adapta os polyfills a cada navegador |
| 2014-10-28 | O HTML5 se torna uma Recomendação do W3C; navegadores evergreen, que se atualizam automaticamente, logo tornam o polyfill.io largamente desnecessário |
| ~2023 | O Financial Times entrega o projeto a seu mantenedor de longa data, Jake Champion |
| Fev 2024 | O domínio polyfill.io e o repositório no GitHub são vendidos à Funnull, uma empresa de operação chinesa |
| 2024-02-25 | Andrew Betts alerta publicamente: "Se o seu site usa polyfill.io, remova-o IMEDIATAMENTE" |
| 2024-02-29 | A Cloudflare publica um espelho seguro no cdnjs para reduzir o risco da cadeia de suprimentos; a Fastly disponibiliza seu próprio espelho dias antes |
| 2024-06-24 | O pesquisador japonês "piyokango" sinaliza o comportamento malicioso |
| 2024-06-25 | A Sansec publica sua divulgação forense; a cside publica no mesmo dia e relata a dimensão real de 490.000+ |
| 2024-06-26 | A Cloudflare começa a reescrever automaticamente o polyfill.io para o seu espelho; o Google alerta os anunciantes afetados |
| 2024-06-27 | A Namecheap suspende o domínio polyfill.io |
| 2024-07-02 | A Censys conta de forma independente 384.773 hosts afetados |
| 2025-05-29 | A OFAC sanciona a Funnull e o administrador Liu Lizhi; o FBI liga 548 CNAMEs da Funnull a mais de 332.000 domínios |
| 2026-05-18 | 61.593 páginas ainda incorporam o polyfill.io |
O número de "100.000 sites" estava errado
Quase todos os relatos sobre este ataque usaram o mesmo número: cerca de 100.000 sites. Esse número é um artefato da ferramenta, não uma medição do ataque.
Os pesquisadores, incluindo a cside, usaram o PublicWWW para encontrar todas as páginas que continham o snippet do polyfill.io. O PublicWWW limita os resultados a 100.000 por padrão. Assim, toda contagem que dependeu dele chegou a "100.000+". Quando executamos a busca além do limite, o número real era de mais de 490.000 sites.
Isso importa porque o conjunto afetado não era aleatório. Ele pendia fortemente para destinos de alto tráfego e alta confiança: bancos, sites governamentais, grandes veículos e marcas conhecidas. Relatar "100.000" subestimava um ataque quase cinco vezes maior. A cside trazendo à tona o número real de 490.000+ é a correção que o registro público precisava, e a contagem independente da Censys de 384.773 hosts em 2024-07-02 confirma que a dimensão estava muito além de 100.000.
O que o código malicioso realmente fazia
O comportamento que foi capturado, decodificado e publicado era um redirecionamento. O relatório forense da Sansec em 2024-06-25 mostrou o script adulterado enviando alguns visitantes móveis através de um typosquat falso do Google Analytics, googie-anaiytics[.]com (note as letras trocadas), e em seguida para sites de apostas esportivas e adultos.
A técnica é o que o tornou perigoso e difícil de detectar. O redirecionamento:
- disparava apenas em dispositivos móveis, nunca em desktop;
- variava por região geográfica e por hora do dia;
- atingia cada dispositivo ou IP apenas uma vez, de modo que nem a vítima nem o pesquisador conseguiam reproduzi-lo ao recarregar;
- ficava em silêncio quando detectava um usuário administrador ou a presença de ferramentas de análise web;
- vinha com proteções anti-engenharia-reversa.
Como o polyfill.io era um serviço dinâmico por design, o operador podia servir código limpo a um visitante e código malicioso ao seguinte. O Subresource Integrity não podia ajudar, porque ele fixa o hash de um arquivo fixo e este serviço não tinha arquivo fixo. O script rodava como first-party na própria origem de cada site, então tinha acesso ao DOM, aos formulários e aos cookies daquela página, e estava nas allowlists de CSP de centenas de milhares de domínios confiáveis.
Foi apenas um redirecionamento? Essa é a parte honesta e não resolvida. A desofuscação independente do payload recuperado encontrou lógica de redirecionamento e nada mais, sem captura de teclas, sem roubo de credenciais. Mas o design por requisição significa que uma variante voltada a um único visitante de alto valor não precisaria jamais aparecer em nenhuma varredura pública. O redirecionamento é o que foi capturado. O que mais pode ter rodado durante aqueles meses não pode ser provado de nenhuma forma. Apresentamos o argumento da capacidade em detalhe em O ataque ao Polyfill.io: muito mais do que um simples ataque de redirecionamento.
Para o relato completo do incidente da época, veja O ataque Polyfill explicado e nosso relatório do mesmo dia, Mais de 490 mil sites alvos de um ataque à cadeia de suprimentos web.
Existe um CVE para o ataque ao Polyfill.io?
Não existe um único CVE atribuído ao próprio incidente do Polyfill.io. O identificador mais próximo no National Vulnerability Database é o CVE-2024-38526, mas seu escopo é o pdoc — uma ferramenta de documentação de API em Python que criava links para o polyfill.io na documentação que gerava (corrigido no pdoc 14.5.1). Ele não cobre o cdn.polyfill[.]io nem o conjunto mais amplo de sites afetados. Se você gerencia um programa de vulnerabilidades, rastreie este incidente pelos domínios afetados (cdn.polyfill[.]io, além dos relacionados bootcdn[.]net, bootcss[.]com, staticfile[.]net, staticfile[.]org e unionadjs[.]com) em vez de um único CVE, e referencie o CVE-2024-38526 apenas para a exposição ao pdoc.
A conexão com a Funnull e as sanções de 2025
O Polyfill.io não foi um caso isolado. O comprador do domínio, a Funnull, operava algo muito maior.
Em 2025-05-29, o Office of Foreign Assets Control do Tesouro dos EUA sancionou a Funnull Technology Inc. e seu administrador, Liu Lizhi. O Tesouro ligou a infraestrutura da Funnull a mais de 200 milhões de dólares em perdas reportadas por vítimas nos EUA em esquemas de investimento, o padrão muitas vezes chamado de pig butchering. Seu comunicado descreveu a conexão com o polyfill sem nomear o serviço: em 2024 a Funnull "comprou um repositório de código usado por programadores web e alterou o código de forma maliciosa para redirecionar visitantes de sites legítimos para sites de fraude e sites de apostas online".
No mesmo dia, o FBI ligou 548 CNAMEs da Funnull a mais de 332.000 domínios. Isso é lavagem de infraestrutura: alugar espaço de cloud e CDN respeitáveis através de contas ilícitas e revendê-lo a fraudadores para que sites maliciosos pareçam legítimos e continuem difíceis de remover. Cobrimos as sanções e o que significam para equipes de segurança em Funnull sancionada: o que o ataque ao Polyfill.io revelou sobre lavagem de infraestrutura.
Quem ainda está exposto
Sanções perturbam uma empresa. Elas não removem código do seu site. Em 2026-05-18, o PublicWWW ainda listava 61.593 páginas contendo polyfill.io, bem mais de um ano após o domínio ter sido suspenso.
Esse resíduo é a verdadeira lição. Dependências do navegador continuam incorporadas muito depois de um domínio ser bloqueado, porque as pessoas não removem as coisas. Cada uma dessas páginas ainda aponta para um domínio que já foi transformado em arma uma vez.
Como encontrar e remover o Polyfill.io hoje
Comece pelas páginas que tocam login, checkout, criação de conta, pagamento e dados pessoais.
- Procure em seu código-fonte, tag managers, templates de CMS e snippets legados por
polyfill.io, além dos domínios relacionadosbootcdn[.]net,bootcss[.]com,staticfile[.]net,staticfile[.]orgeunionadjs[.]com. - Remova as referências. Navegadores modernos não precisam mais desses polyfills, então a exclusão é mais segura do que trocar por um espelho.
- Mapeie cada script de terceiros restante para um proprietário, uma finalidade, um escopo de página e um nível de acesso a dados.
- Sinalize scripts que carregam outros scripts, constroem URLs dinamicamente ou se comportam de forma diferente por user agent, região ou sessão.
- Use o Subresource Integrity apenas onde um script é estático e o fornecedor suporta hashes estáveis.
- Reforce a Content Security Policy em fluxos sensíveis, começando em modo report-only.
- Monitore o que os scripts realmente fazem em tempo de execução, para que uma mudança de propriedade ou um novo payload sejam visíveis quando usuários reais carregam a página.
O que este ataque ensina sobre segurança no lado do cliente
O ataque ao Polyfill.io funcionou porque a confiança foi tratada como permanente. Um script aprovado uma vez continuou rodando depois que a empresa por trás dele mudou e depois que o código que ele servia mudou. Os logs de servidor não o viram. Os questionários de fornecedor não o detectaram. O navegador o executou mesmo assim.
Essa lacuna, entre a inclusão confiável e a execução em tempo de execução, é exatamente o que a cside foi construída para fechar. A cside trabalha na camada do navegador, onde os scripts de terceiros realmente rodam. Ela mostra quais scripts carregam em páginas reais, o que eles chamam, como mudam e se tentam comportamento suspeito, como redirecionamentos inesperados ou acesso a dados. No caso do Polyfill.io, essa visão em tempo de execução é o que sinaliza uma dependência confiável no momento em que ela se torna hostil.
O próximo polyfill.io já está na web em algum lugar, incorporado e confiável. A única forma confiável de detectá-lo é observar o que seus scripts fazem, não apenas quem os enviou. Proteja seu site gratuitamente com a cside e veja todos os scripts que seus usuários realmente carregam.
