Ataque à cadeia de suprimentos web explicado: o incidente Polyfill[.]io, linha do tempo completa e lições (2024-2026)

Resumo: linha do tempo do ataque Polyfill[.]io

• O número estava errado: 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 dimensão real: 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.
• Confiança não é controlo: 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.

Sem tempo? Veja o bloqueio de Magecart e skimmers no navegador da cside. Cobre tudo o que se segue numa única implementação.

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-09-13: adicionados quatro exemplos documentados de ataques à cadeia de fornecimento JavaScript (event-stream 2018, node-ipc 2022, Ledger ConnectKit 2023, Polymarket 2026) e duas FAQ sobre exemplos e prevenção. A cronologia principal de polyfill[.]io permanece inalterada.

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.

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.

Exemplos de ataques à cadeia de suprimentos JavaScript: quatro casos documentados

Os ataques à cadeia de fornecimento JavaScript podem afetar sistemas de compilação, dependências instaladas ou código entregue aos navegadores. Estes quatro casos mostram diferentes formas de distribuir código malicioso através de um canal de confiança.

event-stream (2018): Um novo responsável adicionou flatmap-stream como dependência. Uma carga cifrada visava o ambiente de compilação do Copay e foi incluída em versões afetadas da carteira, onde podia roubar dados de contas e chaves privadas. A análise do npm descreve esse passo de compilação.

node-ipc (2022): As versões 10.1.1 e 10.1.2 continham código introduzido pelo responsável para sobrescrever ficheiros com base na geolocalização IP. O aviso CVE-2022-23812 identifica as versões afetadas e a remoção na 10.1.3. Esta dependência executava-se no sistema anfitrião, não era um skimmer de navegador.

Ledger ConnectKit (2023-12-14): A conta npm de um antigo funcionário foi comprometida e versões maliciosas do Connect Kit distribuíram Angel Drainer a aplicações que carregavam a biblioteca. O relatório da Ledger explica como a distribuição e a cache da CDN prolongaram a exposição após a publicação de uma correção.

Polymarket (2026): Uma dependência de terceiros comprometida injetou JavaScript para esvaziar carteiras no frontend da plataforma. A informação documentada no nosso caso Polymarket não identificava o fornecedor; atribuí-lo a um prestador de analítica ultrapassaria essas provas.

Os controlos dependem de onde a dependência é executada: proteja a compilação e a distribuição de pacotes, além de monitorizar scripts de terceiros nas sessões do navegador.

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)

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 corretamente configurado rejeita um script cujo conteúdo descarregado não corresponde a um hash aprovado. A variação entre pedidos não contorna essa verificação; dificulta manter hashes aprovados para as variantes legítimas específicas de cada navegador. 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.

1. Para uma pesquisa literal, substitua primeiro cada [.] nestes nomes de domínio por um ponto simples (.). Procure no seu código-fonte, gestores de tags, modelos de CMS e snippets antigos por polyfill[.]io, além dos domínios relacionados bootcdn[.]net, bootcss[.]com, staticfile[.]net, staticfile[.]org e unionadjs[.]com.
2. 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.
3. 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.
4. 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.
5. Use o Subresource Integrity apenas onde um script é estático e o fornecedor suporta hashes estáveis.
6. Reforce a Content Security Policy nos fluxos sensíveis, começando em modo report-only.
7. 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.

Para um exemplo mais recente deste mesmo padrão num contexto DeFi, veja o ataque à cadeia de suprimentos do lado do cliente de $3M à Polymarket, onde um script de fornecedor comprometido esvaziou carteiras através da própria interface da plataforma, sem tocar num único smart contract.