Recentemente, mais de 490.000 sites foram alvos de um ataque à cadeia de suprimentos web. (A Censys contou de forma independente 384.773 hosts que ainda referenciavam o domínio em 2024-07-02.) Fomos os primeiros a relatar a dimensão real do ataque em nossa reportagem original. Para a história completa de 2024–2026, veja nossa linha do tempo e análise completas do Polyfill.io.
Alguns artigos que nos mencionaram incluem:
NOTA: Se um site está referenciando os domínios polyfill[.]io bootcdn[.]net, bootcss[.]com, staticfile[.]net, staticfile[.]org e unionadjs[.]com hoje, eles ainda estão abertos a este ataque.
O que era o projeto de serviço Polyfill?
Polyfill era originalmente um projeto de código aberto que permitia que sites usassem recursos modernos de JavaScript em navegadores mais antigos como o Internet Explorer. Isso era necessário quando a comunidade online gradualmente migrou para frameworks de navegador mais modernos.
Apesar de ser amplamente desnecessário, já que a quantidade de tráfego do Internet Explorer se tornou negligenciável, milhares de sites ainda referenciam este domínio.
Criado em outubro de 2014, o Polyfill recebia atualizações regulares. Em fevereiro de 2024, o colaborador Andrew Betts (@triblondon no X) alertou a comunidade quando o domínio polyfill[.]io foi adquirido por uma empresa chinesa de seus proprietários originais:
Se o seu site usa
, remova-o IMEDIATAMENTE.
Eu criei o projeto de serviço polyfill, mas nunca fui dono do nome de domínio e não tive influência sobre sua venda.
— Andrew Betts (@triblondon)
Como Polyfill[.]io facilitou um ataque à cadeia de suprimentos web
Domínios usados para servir scripts populares de terceiros são uma grande preocupação de segurança, pois podem mudar dinamicamente sem notificar ninguém ou nada. Isso inclui servir scripts totalmente diferentes com base no seu navegador, User-Agent, geolocalização, IP ou qualquer outro vetor. Eles têm liberdade total no que servem para quem, com base em quê.
Polyfill[.]io e Polyfill[.]com foram comprados por uma empresa chinesa chamada Funnull.
Após esta venda e a postagem de Andrew no X, o colaborador do Github "renchap" fornece algum contexto extra sobre a transação:
"Polyfill[.i]o era de propriedade da equipe web do Financial Times, depois passou para gestão comunitária, e o último mantenedor vendeu o projeto para uma estranha empresa chinesa de CDN, e eles o moveram para longe do Fastly (a plataforma CDN / Edge compute executando o código OSS para o serviço) e começaram a mexer com os arquivos retornados."
O colaborador do GitHub "munierujp" mencionou que Jake Champion decidiu transferir a propriedade do Polyfill para a Funnull:
O link que ele referencia foi removido desde então. Também não há uma página do Internet Archive disponível.
Andrew Betts e Jake Champion, ambos anteriormente do Financial Times e proprietários originais do Polyfill, agora trabalham na Fastly.
Outros membros da comunidade neste tópico do Github mencionam que:
"Funnull é notória por fornecer serviços para as indústrias de apostas e pornografia."
Isso foi um prenúncio do que realmente aconteceu após o ataque.
Anteriormente a tudo isso, o Polyfill rodava na plataforma de edge compute da Fastly. Como isso não está disponível na nuvem chinesa, "renchap" no Github notou que polyfill[.]io agora tinha um registro CNAME para polyfill[.]io.bsclink[.]cn.
Após a mudança suspeita de propriedade, a Fastly configurou um espelho da biblioteca Polyfill como um domínio alternativo para ajudar as pessoas a continuarem usando o serviço, polyfill-fastly.io. Eles forneceram isso apenas dias após a venda ser comunicada.
Um dia após o anúncio da Fastly, a Cloudflare lançou um endpoint alternativo para Polyfill[.]io no CDNJS para mitigar o risco de um ataque.
Esta não é uma solução 100% perfeita. As vulnerabilidades do cndnjs de 2021 mostraram ao mundo que até grandes CDNs JavaScript respeitáveis podem sofrer com risco de cadeia de suprimentos. Isso mostra que não se pode simplesmente confiar nas fontes. Em vez disso, o monitoramento contínuo deve ser usado para detectar anomalias. Isso faz parte do motivo pelo qual a cside foi fundada.
O que aconteceu no ataque Polyfill?
Um arquivo JavaScript adulterado injetado pelo domínio polyfill[.]io redirecionou uma porcentagem de usuários para sites adultos e de apostas com base em seu User-Agent. Um usuário japonês do X, "piyokango" foi provavelmente o primeiro a relatar seu ataque em 24 de junho.
Em 25 de junho, "Huli" conseguiu reproduzir este ataque e relatá-lo em inglês. Ele encontrou uma postagem do GitHub do dia anterior, onde um usuário chamado "alitonium" explica como ele descobriu.
Após atender certas condições, o arquivo JavaScript alterado se revela. Após decodificação, mostra um link falso do Google Analytics googie-anaiytics[.]com/gtags.js. Observe como este domínio é um typosquatting: a letra i é usada em vez de um l, tanto em "googie" quanto em "anaiytics". A empresa de segurança Sansec publicou uma análise forense completa do payload. (O CVE-2024-38526 relacionado foi atribuído ao pdoc, a ferramenta de documentação Python que carregava o polyfill.io, e não ao incidente como um todo.)
Este domínio typosquatted redireciona usuários para vários sites de apostas esportivas e adultos, aparentemente com base em sua região. Este é um dos sites para os quais fomos redirecionados:
Embora este ataque à cadeia de suprimentos web neste momento apenas redirecionasse usuários, uma infinidade de coisas poderia ter acontecido. De ataques watering hole a captura de detalhes de cartão de crédito. Um ataque watering hole é um tipo onde hackers visam um site que um grupo específico de pessoas frequentemente visita. Eles infectam o site com malware para que quando os membros do grupo visitam o site, seus computadores sejam infectados.
Como a maioria das medidas de segurança comuns depende apenas de verificar fontes, ataques como este ainda estão acontecendo hoje. Como este exemplo particular mostrou, fornecedores de feeds de ameaças não listaram o domínio polyfill[.]io como malicioso até dias após os relatórios. Isso está operando a partir de uma abordagem experiência primeiro, reaja depois, que fundamentalmente permite que ataques como este continuem acontecendo.
A cside foi fundada especificamente para desafiar a dependência de feeds de ameaças, pois o ritmo de novos métodos de ataque criativos é maior do que a velocidade com que os feeds de ameaças os processam. Isso ficou claro recentemente com a crise do National Vulnerability Database (NVD), onde mais de 10.000 ataques conhecidos estavam esperando em um backlog para serem revisados e processados em Common Vulnerabilities and Exposures (CVEs).
No exemplo do Polyfill, nosso mecanismo foi capaz de detectar os polyfills injetados e impediu que eles acontecessem. Ele protegeu o usuário e alertou o proprietário do site sobre o código malicioso.
Como "Huli" do blog mencionado acima postou sobre a mudança de comportamento, começamos a escrever nosso próprio relatório, que foi ao ar logo depois. Primeiro relatamos que cerca de 110.000 sites foram afetados. Mais tarde corrigimos isso para a estimativa atual, que é mais de 490.000 sites.
Revelando marcas proeminentes impactadas como o serviço de streaming Hulu, de propriedade da Disney, The Guardian, Intuit e muitos mais.
Notamos que o site Polyfill[.]io adicionou um cabeçalho 'Cloudflare Security Protection' à sua página inicial entre 7 e 8 de março. Isso nos pareceu estranho na época, assim como para outros na comunidade. Um dia após nosso relatório, a Cloudflare confirmou que não autorizou seu uso.
Também observamos que o redirecionamento malicioso acontecia apenas uma vez por IP. Isso foi provavelmente projetado para contornar a detecção pelo maior tempo possível.
As consequências
O domínio Polyfill[.]io foi comprado através da Namecheap. Durante a comoção, a Namecheap desligou o domínio conforme relatado por MalwareHunterTeam no X:
Atualização muito importante/grande: na última hora,
finalmente decidiu derrubar o domínio polyfill[.]io.
Nenhum 👏 para eles, de jeito nenhum, porque levou muito mais tempo do que deveria, mas provavelmente um pequeno agradecimento ainda por fazer tarde do que nunca fazer...
🤷♂️
— MalwareHunterTeam (@malwrhunterteam)
O site então voltou novamente em Polyfill[.]com, mas desde então também foi desligado.
O Google também respondeu. Eles pararam de servir anúncios para sites com os scripts neles e colocaram pressão sobre os proprietários de sites, tirando sua receita de anúncios para remover os scripts. O Google também enviou avisos que mencionavam alguns outros domínios, como notado por Michal Špaček no X:
O Google agora está enviando um aviso sobre carregar JS de terceiros de domínios como polyfill.io bootcss.com bootcdn.net & staticfile.org que podem fazer coisas desagradáveis aos seus usuários se o seu site usa JS desses domínios.
— Michal Špaček (@spazef0rze)
O que nos traz de volta ao MalwareHunterTeam que fez mais investigações. Eles mencionaram que todos esses domínios são gerenciados pelo mesmo grupo. Isso foi confirmado quando um token de API da Cloudflare e ZoneID vazaram no GitHub.
Esses domínios incluíam Polyfill[.]io mas também bootcdn[.]net, bootcss[.]com, polyfill[.]io, staticfile[.]net, staticfile[.]org e unionadjs[.]com.
Além disso, eles encontraram evidências de código malicioso sendo servido através desses domínios. Afetando centenas de milhares de sites.
Atualização importante sobre a situação de ataque tipo cadeia de suprimentos polyfill[.]io.
Então, quando o Google começou a fazer avisos de que anúncios para páginas/sites que usam polyfill[.]io podem ser suspensos, eles mencionaram mais 3 domínios:
bootcss[.]com
bootcdn[.]net
staticfile[.]org
Mas de alguma forma todos…
— MalwareHunterTeam (@malwrhunterteam)
Esses domínios também não foram listados como maliciosos por fornecedores de feeds de ameaças. Mesmo que alguns desses domínios estivessem servindo ataques à cadeia de suprimentos desde junho de 2023. Isso é mais de um ano de ataques não detectados.
Então, eu estava esperando que os ataques tipo cadeia de suprimentos usando esses serviços/domínios estivessem acontecendo desde algum tempo do ano passado, mas só agora confirmado graças a
(
) que está voltando pelo menos ao junho passado, então um pouco mais de 1 ano…
— MalwareHunterTeam (@malwrhunterteam)
A cside não estava por perto para detectá-los naquela época.
Em uma tentativa de salvar as aparências, uma conta do X com o nome Polyfill começou a acusar a Cloudflare, a mídia e outros de difamação. A conta foi criada em fevereiro de 2024, provavelmente na época em que a venda do domínio aconteceu.
Alguém nos difamou maliciosamente. Não temos riscos de cadeia de suprimentos porque todo o conteúdo é estaticamente armazenado em cache. Qualquer envolvimento de terceiros poderia introduzir riscos potenciais ao seu site,
mas ninguém faria isso, pois colocaria em risco nossa própria reputação.
Nós já…— Polyfill (@Polyfill_Global)
Em 30 de junho, o agente malicioso tentou colocar seu site no ar novamente em polyfill[.]site. Ele foi derrubado desde então.
Em 1º de julho, eles saíram e colocaram seu produto novamente. Desta vez sob polyfillcache[.]com. Esperamos que isso seja derrubado novamente em breve.
Os aprendizados
Este ataque ressalta o risco estendido de scripts de terceiros. Uma vez incorporados em milhares de sites, eles se tornam alvos principais para agentes maliciosos. Com algumas linhas de código, esses sites e milhões de visitantes estão em risco. Esta é uma área sensível da cadeia de suprimentos web, mas as ferramentas para monitorar a superfície de ataque estão ficando para trás e são escassamente usadas.
A cside foi criada para impedir que isso aconteça. Nosso script, que carrega primeiro, força todos os outros através de nosso proxy. Lá, verificamos o código completo para qualquer coisa maliciosa com base em mais de 60 parâmetros. Se nosso mecanismo de detecção decidir que não é seguro, o script é bloqueado de carregar. Também otimizamos esses scripts para combater qualquer latência criada pelo proxy, em muitos casos tornando-os mais rápidos em vez de mais lentos.
Nota do editor (2026): Este parágrafo descreve a arquitetura original da cside, de 2024. A cside agora realiza monitoramento completo de scripts no lado do cliente — um único snippet JavaScript first-party que observa o que os scripts de terceiros realmente fazem nos navegadores de visitantes reais, incluindo os payloads condicionais, restritos por geolocalização e horário (como este), que mostram código limpo a scanners e crawlers. O proxy de entrega de scripts descrito acima foi descontinuado no início de 2026.
O ataque Polyfill serve como um lembrete: medidas de segurança que não verificam o código completo antes de servi-lo aos usuários falharão em detectar novos ataques e dependerão de detecções através da comunidade, colocando sites e visitantes em risco.
Aqui o agente malicioso optou por apenas redirecionar usuários para sites adultos e de apostas, no entanto, muito pior poderia ter acontecido. Ouvir pressionamentos de teclas em uma pequena porcentagem de sessões com base em geolocalização e hora do dia, injetar malware, minerar criptomoeda ou reescrever botões em sites para redirecionar para portais de pagamento falsificados. De um simples redirecionamento a captura de detalhes de cartão de crédito, ataques JavaScript do lado do cliente podem fazer tudo. O ataque Polyfill poderia ter tido muito mais impacto negativo, de certa forma tivemos sorte. Que isso seja o lembrete, devemos monitorar nossos scripts do lado do cliente. Explicamos por que isso foi muito mais do que um simples ataque de redirecionamento e, em 2025, a história fechou o ciclo quando a OFAC sancionou a Funnull, a empresa por trás do domínio.
Você pode proteger seu site em segundos usando a cside. Nosso plano gratuito protege seu site contra este e ataques semelhantes.
