Resumo: linha do tempo do ataque Polyfill.io
- As manchetes disseram 100.000 sites e estava errado, porque era o limite de resultados por defeito da ferramenta de pesquisa PublicWWW usada pelos investigadores, e a dimensão real era muito maior e mais concentrada em propriedades de alta confiança.
- A cside refez a pesquisa além do limite e encontrou mais de 490.000 sites a carregar o polyfill.io, e a Censys contou de forma independente 384.773 hosts afetados em 2 de julho de 2024, antes de o OFAC sancionar a Funnull em 29 de maio de 2025.
- Se um único script de fornecedor pode tornar-se malicioso depois de ser confiável desde 2015, a aprovação baseada na fonte não é um controlo, por isso monitorize o comportamento em runtime em cada sessão em vez de confiar numa aprovação pontual do fornecedor.
Resposta rápida: um ataque à cadeia de suprimentos web compromete uma biblioteca ou serviço de CDN de terceiros em que sites legítimos já confiam, e depois usa essa confiança para executar código controlado pelo invasor no navegador de cada visitante. O ataque ao Polyfill.io é o exemplo documentado mais claro: o serviço de polyfill confiável foi adquirido pela Funnull em fevereiro de 2024, tornou-se malicioso em junho e atingiu mais de 490.000 sites antes que alguém desse por isso. Esta página explica como funciona esta categoria de ataque, documenta o incidente do Polyfill.io na íntegra e mostra o que o seu site precisa de fazer de forma diferente.
Atualização de 2026-07-19: foi adicionada uma secção sobre tipos de ataques à cadeia de suprimentos web e como a categoria funciona, além de novas entradas de FAQ. A linha do tempo principal e os dados do Polyfill.io permanecem inalterados.
O que é um ataque à cadeia de suprimentos web?
Um ataque à cadeia de suprimentos web compromete uma biblioteca JavaScript de terceiros, uma CDN ou um serviço que sites legítimos carregam e em que confiam. Como a página carrega esse código como se fosse seu, o invasor obtém execução de código no navegador de cada visitante sem tocar diretamente no site-alvo.
Um ataque à cadeia de suprimentos web tem algumas propriedades que o definem. O site vítima aprovou o script uma vez, e o invasor herda essa confiança de forma permanente. O payload é executado do lado do cliente, depois de o servidor já ter enviado a página, pelo que uma única biblioteca comprometida se propaga a todos os sites que a carregam. As WAFs, os registos de CDN e os scanners do lado do servidor não veem nenhuma anomalia, porque o ataque acontece inteiramente no navegador.
O Polyfill.io é o caso mais documentado desta categoria. Um utilitário gratuito e amplamente confiável estava presente em centenas de milhares de sites. Novos proprietários transformaram-no numa superfície de ataque de um dia para o outro, e nenhum proprietário de site mudou uma única linha de código.
Como funcionam os ataques à cadeia de suprimentos web: quatro vetores principais
Os ataques à cadeia de suprimentos web partilham o mesmo modelo de abuso de confiança, mas chegam aos sites através de diferentes pontos de entrada.
| Tipo de ataque | Como funciona | Como o ataque polyfill.io se enquadra |
|---|---|---|
| Apropriação de CDN / domínio | O invasor adquire um domínio que os sites já carregam via tags de script | A Funnull comprou o polyfill.io; os sites continuaram a carregá-lo sem qualquer alteração de código |
| Sequestro de pacotes npm | Um pacote popular é tomado ou é publicado um typosquat; os pipelines de CI puxam a versão maliciosa para o build | Não foi este ataque, mas o risco é o mesmo se o resultado do build incorporar o pacote do lado do cliente |
| Comprometimento de repositório de código aberto | A conta de um mantenedor é tomada; é publicada uma versão maliciosa no pacote oficial | O repositório GitHub do polyfill.io mudou de proprietário juntamente com o domínio |
| Confusão de dependências | Um nome de pacote interno é registado no registo público; o build passa a descarregar por defeito a versão do invasor | Não foi este ataque, mas afeta sites que empacotam e servem dependências a partir da sua própria CDN |
O fio condutor: nos quatro casos, código que não escreveu acaba por ser executado nos navegadores dos seus utilizadores com o mesmo nível de confiança do seu próprio JavaScript.
O ataque à cadeia de suprimentos web do Polyfill.io: registo completo
A versão resumida
- O domínio polyfill.io foi vendido à Funnull em fevereiro de 2024. Em junho, já estava a servir redirecionamentos maliciosos.
- Não existe um CVE para o incidente como um todo; o mais próximo, o CVE-2024-38526, tem como âmbito a ferramenta de documentação pdoc que carregava o polyfill.io, e não o ataque em si.
- A dimensão real foi de 490.000+ sites, não os 100.000 amplamente citados. Esse número era o limite de resultados por defeito do PublicWWW. A cside relatou o número real em primeiro lugar.
- O payload capturado era um redirecionamento apenas em dispositivos móveis para sites de fraude e de apostas, construído para evadir investigadores.
- Em 2025-05-29, o OFAC sancionou a Funnull e o seu administrador Liu Lizhi.
- Em 2026-05-18, mais de 61.000 páginas ainda incorporam o polyfill.io. Se a sua for uma delas, remova-o.
Linha do tempo completa (2009-2026)
| Data | Evento |
|---|---|
| 2009-2010 | Remy Sharp cunha o termo "polyfill"; a ideia espalha-se 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 torna-se uma Recomendação do W3C; navegadores evergreen, que se atualizam automaticamente, tornam rapidamente o polyfill.io largamente desnecessário |
| ~2023 | O Financial Times entrega o projeto ao 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 o seu próprio espelho dias antes |
| 2024-06-24 | O investigador japonês "piyokango" assinala o comportamento malicioso |
| 2024-06-25 | A Sansec publica a sua divulgação forense; a cside publica no mesmo dia e relata a verdadeira dimensão de 490.000+ |
| 2024-06-26 | A Cloudflare começa a reescrever automaticamente o polyfill.io para o seu espelho; a 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 | O 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 artefacto da ferramenta, não uma medição do ataque.
Os investigadores, 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 defeito. Assim, todas as contagens que dependiam dele chegavam a "100.000+". Quando fizemos a pesquisa além do limite, o número real era de mais de 490.000 sites.
Isto importa porque o conjunto afetado não era aleatório. Pendia fortemente para destinos de alto tráfego e alta confiança: bancos, sites governamentais, grandes órgãos de comunicação e marcas conhecidas. Relatar "100.000" subestimava um ataque quase cinco vezes maior. A cside trouxe à tona o número real de 490.000+, corrigindo o registo público, 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 fazia realmente o código malicioso
O comportamento que foi capturado, descodificado e publicado era um redirecionamento. O relatório forense da Sansec de 2024-06-25 mostrou o script adulterado a enviar alguns visitantes móveis através de um typosquat falso do Google Analytics, googie-anaiytics[.]com (note as letras trocadas), e daí para sites de apostas desportivas e para sites de conteúdo adulto.
A técnica é o que o tornou perigoso e difícil de detetar. 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 uma vítima nem um investigador conseguiam reproduzi-lo ao atualizar a página;
- ficava silencioso quando detetava um utilizador administrador ou a presença de ferramentas de análise web;
- vinha equipado com proteções anti-engenharia-reversa.
Como o polyfill.io era, por conceção, um serviço dinâmico, o operador podia servir código limpo a um visitante e código malicioso ao seguinte. O Subresource Integrity não podia ajudar, porque fixa o hash de um ficheiro fixo, e este serviço não tinha ficheiro fixo. O script corria como first-party na própria origem de cada site, pelo que tinha acesso ao DOM, aos formulários e aos cookies dessa página, e constava das allowlists de CSP de centenas de milhares de domínios confiáveis.
Foi apenas um redirecionamento? Essa é a parte honesta e por resolver. A desofuscação independente do payload recuperado encontrou apenas lógica de redirecionamento: nada de captura de teclas, nada de roubo de credenciais. Mas o design por pedido significa que uma variante dirigida a um único visitante de alto valor nunca precisaria de aparecer em qualquer varrimento público. O redirecionamento é o que foi capturado. O que mais possa ter corrido durante aqueles meses não pode ser provado nem num sentido nem noutro. Apresentámos 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 na altura, veja O ataque Polyfill explicado e o nosso relatório do mesmo dia, Mais de 490 mil sites visados num 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 o seu âmbito é o pdoc, uma ferramenta de documentação de API em Python que ligava para o polyfill.io na documentação que gerava (corrigido no pdoc 14.5.1). Não cobre o cdn.polyfill[.]io nem o conjunto mais amplo de sites afetados. Se gere um programa de vulnerabilidades, acompanhe 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 cite o CVE-2024-38526 apenas para a exposição do pdoc.
A ligação à Funnull e as sanções de 2025
O Polyfill.io não foi um caso isolado. A compradora do domínio, a Funnull, geria uma operação muito maior.
Em 2025-05-29, o Office of Foreign Assets Control do Tesouro dos EUA sancionou a Funnull Technology Inc. e o 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 provenientes de esquemas de investimento, o padrão muitas vezes chamado de pig butchering. O seu comunicado descreveu a ligação ao polyfill sem nomear o serviço: em 2024, a Funnull "comprou um repositório de código usado por programadores web e alterou maliciosamente o código 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. Isto é lavagem de infraestrutura: alugar espaço de cloud e de CDN respeitáveis através de contas ilícitas e revendê-lo a burlões para que sites maliciosos pareçam legítimos e continuem difíceis de remover. Cobrimos as sanções e o que significam para as equipas de segurança em Funnull sancionada: o que o ataque ao Polyfill.io revelou sobre lavagem de infraestrutura.
Quem continua exposto
As sanções perturbam uma empresa. Não removem código do seu site. Em 2026-05-18, o PublicWWW continuava a listar 61.593 páginas que continham polyfill.io, bem mais de um ano depois de o domínio ter sido suspenso.
Esse resíduo é a verdadeira lição. As 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 continua a apontar 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 no seu código-fonte, gestores de tags, modelos de CMS e snippets antigos por
polyfill.io, além dos domínios relacionadosbootcdn[.]net,bootcss[.]com,staticfile[.]net,staticfile[.]orgeunionadjs[.]com. - Remova as referências. Os navegadores modernos já não precisam destes polyfills, pelo que a eliminação é mais segura do que substituir por um espelho.
- Mapeie cada script de terceiros restante para um proprietário, uma finalidade, um âmbito de página e um nível de acesso a dados.
- Sinalize scripts que carregam outros scripts, constroem URLs de forma dinâmica ou se comportam de forma diferente consoante o user agent, a região ou a sessão.
- Use o Subresource Integrity apenas onde um script é estático e o fornecedor suporta hashes estáveis.
- Reforce a Content Security Policy nos fluxos sensíveis, começando em modo report-only.
- Monitorize o que os scripts realmente fazem em tempo de execução, para que uma mudança de proprietário ou um novo payload sejam visíveis quando utilizadores reais carregam a página.
O que este ataque ensina sobre a segurança da cadeia de suprimentos web
O ataque ao Polyfill.io resultou porque a confiança foi tratada como permanente. Um script aprovado uma vez continuou a correr depois de a empresa por trás dele mudar e depois de o código que servia mudar. Os registos do servidor não o viram. Os questionários a fornecedores não o detetaram. O navegador executou-o na mesma.
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 correm. Mostra quais os scripts que carregam em páginas reais, o que chamam, como mudam e se tentam comportamentos suspeitos, como redirecionamentos inesperados ou acesso a dados. No caso do Polyfill.io, é essa visão em tempo de execução que sinaliza uma dependência confiável no momento em que se torna hostil.
O próximo polyfill.io já está algures na web, incorporado e confiável. A única forma fiável de o detetar é observar o que os seus scripts fazem, não apenas quem os publicou. Proteja o seu site gratuitamente com a cside e veja todos os scripts que os seus utilizadores realmente carregam.
