Resumo

  • Um site que carregavacdn.polyfill.iofazia mais do que citar um projeto de código aberto. Ele permitia que um serviço remoto ativo selecionasse JavaScript e o retornasse para execução no contexto do navegador do site. O objeto de confiança, portanto, incluía o domínio, operador, roteamento e caminho de resposta, não apenas o código-fonte que poderia ser inspecionado em outro lugar. [15][16][17]
  • O controle do domínio Polyfill.io e da presença associada mudou em fevereiro de 2024. Fastly, Cloudflare e um projeto FormatJS reagiram na época, mostrando que a reavaliação downstream era possível antes que a entrega maliciosa fosse publicamente relatada em junho. A transferência em si não deve ser descrita como prova de intenção maliciosa. [2][3][4]
  • Sansec relatou em 25 de junho que o serviço estava retornando seletivamente JavaScript modificado que redirecionava visitantes qualificados. Cloudflare disse que os indicadores do Page Shield incluíam correspondências desde 8 de junho, enquanto Akamai descreveu amostragem no servidor seguida por verificações no cliente. Essas observações estabelecem uma campanha de redirecionamento, nem toda ação que um JavaScript fornecido remotamente poderia teoricamente realizar. [1][5][9]
  • A estimativa da Sansec de mais de 100.000 sites referia-se a sites que incorporavam ou usavam o serviço. Cloudflare citou uma estimativa de uso próxima a quatro por cento dos sites. Nenhum dos números é um total verificado de sites que serviram o ramo malicioso, redirecionaram visitantes ou sofreram perda. [1][5]
  • As reescritas automáticas da Cloudflare e a retenção do domínio pela Namecheap restringiram o caminho de entrega. Eles não removeram referências obsoletas do código downstream, estabeleceram o que cada visitante anterior recebeu ou concluíram a investigação de cada proprietário de site. [5][6][10]
  • Fides, Jellyfish e Wordfence ilustram três tarefas de evidência diferentes: determinar se um caminho condicional era alcançável, rastrear um fornecedor transitivo, verificar a remoção e evitar tratar uma referência ao endpoint como prova de exploração. [11][12][13][14][22]
  • Responsabilidade aqui não é uma conclusão legal ou uma afirmação de culpa igual. Significa que cada parte deve ser responsável pelos controles que poderia realmente exercer. Os proprietários de sites mantiveram controle sobre necessidade, inventário, escolha de provedor, auto-hospedagem, monitoramento de propriedade, observação no navegador, investigação, reparo e comunicação.

Uma tag de script delegou autoridade, não apenas conveniência

A decisão técnica central parecia comum. Um site colocou um elementoscriptem uma página e o apontou paracdn.polyfill.io. Quando um visitante carregava aquela página, o navegador solicitava JavaScript do serviço remoto. O serviço podia inspecionar características da requisição e fornecer polyfills adequados ao navegador, permitindo que navegadores antigos usassem recursos web que não implementavam nativamente.

Essa configuração resolvia um problema prático de compatibilidade. Em vez de enviar todas as funções de compatibilidade para cada visitante, um site podia pedir a um serviço especializado que retornasse o que um navegador específico parecia precisar. O resultado podia ser menor e mais fácil de manter do que um pacote local universal. Mas a eficiência vinha de manter a resposta dinâmica. O site não apenas baixava um pacote fixo durante o desenvolvimento e implantava bytes revisados da sua própria infraestrutura. Ele convidava outro operador a decidir, no momento do carregamento da página, quais bytes um visitante executaria.

A distinção determina o quadro de responsabilidade. Um repositório de código aberto é código e histórico inspecionáveis. Um serviço hospedado é um relacionamento operacional. O serviço ao vivo depende de um domínio, DNS, roteamento, hospedagem, certificados, acesso à implantação e as pessoas ou organizações capazes de alterar a resposta. Um site pode confiar no código público enquanto ainda falha em examinar se o endpoint que atende seus visitantes permanece sob o mesmo controle, segue o mesmo processo ou retorna a mesma classe de saída.

HTTPS não elimina essas questões. Ele pode ajudar um navegador a autenticar que alcançou o titular de autoridade válida para o domínio solicitado e proteger a resposta em trânsito. Ele não promete que o titular do domínio permanece inalterado, que o programa retornado é benigno ou que o conteúdo é invariável entre requisições. Quando o controle do domínio muda legitimamente, HTTPS pode continuar funcionando exatamente como projetado, enquanto autentica uma nova realidade operacional.

O navegador concede ao JavaScript carregado remotamente uma influência prática extensa sobre a página que o inclui. O alcance preciso depende da página e dos controles do navegador, mas a fraqueza básica é bem estabelecida: funcionalidade de terceiros executa dentro do contexto web da primeira parte. A CWE-830 da MITRE descreve essa classe de inclusão como uma transferência de confiança para código de outro domínio, e a OWASP trata JavaScript de terceiros como um problema de governança porque pode afetar dados e comportamento da página.

A orientação do CodeQL do GitHub aplica a mesma lógica a funcionalidades carregadas de um domínio não confiável. [15][16][17]

É por isso que o incidente não deve ser reduzido a "código aberto se tornou inseguro." O código aberto original, uma cópia auto-hospedada revisada e um serviço controlado por domínio ativo eram objetos de confiança distintos. Um site usando uma cópia local fixa não fazia a mesma delegação em tempo de execução que um site solicitando uma resposta mutável decdn.polyfill.io. Um host alternativo também criava um relacionamento operacional diferente, mesmo que servisse código derivado do mesmo projeto.

A primeira questão de responsabilidade, portanto, não é se os desenvolvedores devem desconfiar de toda biblioteca externa. É se o site sabia qual parte poderia escolher bytes executáveis para seus visitantes no momento do uso. Um inventário útil responderia a pelo menos cinco perguntas: quais páginas solicitavam o script, se a inclusão era direta ou transitiva, quais usuários e caminhos de navegador poderiam alcançá-lo, qual função de negócio o exigia e quem controlava atualmente o endpoint.

Essas perguntas pertencem ao proprietário do site porque o site tornou a inclusão efetiva. Um visitante não negociou com o Polyfill.io ou escolheu seu operador. O visitante solicitou uma página do site e razoavelmente experienciou os scripts retornados como parte dessa página. Mesmo onde um tema, plugin, gerenciador de tags ou fornecedor inseriu a referência, a organização downstream permaneceu a parte que apresentava a experiência combinada aos seus usuários.

Isso não faz do proprietário do site o autor do código malicioso nem apaga o controle do operador do serviço. Significa que poder delegado não elimina a responsabilidade da primeira parte. O operador do serviço podia escolher a resposta. O proprietário do site podia escolher se aquele operador mantinha um lugar na página. Esses são controles diferentes, e o incidente testou ambos.

A transferência de fevereiro foi um evento de governança de software

A cronologia pública fornece um intervalo de aviso extraordinariamente importante. Em fevereiro de 2024, o controle do domínio Polyfill.io e da presença associada no GitHub mudou para Funnull, conforme descrito nas fontes contemporâneas. As fontes estabelecem uma mudança no controle e na base de confiança. Elas não estabelecem, por esse fato apenas, o motivo do novo operador, um plano criminoso, uma violação legal ou a identidade final de cada pessoa que mais tarde influenciou a entrega.

Para um site informativo convencional, uma transferência de domínio pode alterar principalmente a autoridade de publicação. Para um domínio que retorna JavaScript executável para outros sites, a transferência altera quem pode influenciar o software que é executado nessas páginas downstream. Isso torna a informação de propriedade parte do estado da dependência. Um novo proprietário do endpoint é operacionalmente comparável a um novo mantenedor, autoridade de assinatura ou canal de lançamento, mesmo quando o repositório de origem parece familiar.

O aviso da Fastly em 28 de fevereiro torna visível o significado de governança. Anunciou domínios de substituição e deu aos usuários opções que incluíam migrar, auto-hospedar ou remover o serviço. Essas opções não eram meras alternativas de marca. Cada uma alterava quem controlaria os bytes entregues aos visitantes. Migração selecionava um relacionamento de serviço diferente. Auto-hospedagem colocava a entrega sob os controles de implantação do próprio site. Remoção eliminava a dependência de compatibilidade se não fosse mais necessária. [3]

Cloudflare seguiu em 29 de fevereiro com uma alternativa hospedada em cdnjs. Sua explicação conectou a transição de provedor ao risco de cadeia de suprimentos: sites confiaram em outra parte para manter e proteger um serviço que podia executar código em suas páginas. A alternativa da Cloudflare não tornou a hospedagem de terceiros livre de riscos, mas mostrou que provedores de infraestrutura entendiam a mudança de propriedade como motivo para uma nova decisão de confiança. [2]

Uma issue do FormatJS aberta em 28 de fevereiro fornece um registro de projeto downstream do mesmo período. Levantou preocupações sobre a propriedade e o relacionamento CNAME e pediu ao projeto que parasse de recomendar o endpoint. Esse registro importa porque mostra um mantenedor agindo sobre uma dependência de documentação antes de uma campanha maliciosa publicamente relatada. Remover uma recomendação não repara todos os sites que a seguiram anteriormente, mas limita a propagação futura e cria um aviso rastreável. [4]

Juntos, esses registros impedem uma narrativa excessivamente conveniente em que os proprietários downstream não tinham sinal até 25 de junho. Nem todos os proprietários de sites teriam visto o aviso da Fastly, o post da Cloudflare ou a issue do FormatJS. As fontes não estabelecem aviso universal, e seria injusto converter a disponibilidade pública em prova de que cada organização realmente sabia. Elas estabelecem que a mudança de propriedade era observável, que alternativas estavam disponíveis e que algumas partes responsáveis reavaliaram o endpoint meses antes do relatório do incidente.

Essa distinção é essencial para a responsabilidade. Um dever de monitorar não significa onisciência. Significa projetar um processo que possa receber mudanças relevantes para dependências de alta autoridade. Um site pode rastrear avisos de pacotes enquanto ignora propriedade de domínio, DNS ou mudanças de hospedagem. Para um pacote versionado, feeds de lançamento e vulnerabilidade podem ser os sinais importantes. Para um endpoint de script remoto, registro, DNS, operador e comportamento de resposta também pertencem ao modelo de monitoramento.

O evento de fevereiro também expõe os limites de uma revisão de fornecedor única. Uma equipe pode ter aprovado o Polyfill.io anos antes com base no operador, infraestrutura, reputação do projeto e necessidades do navegador na época. Se o registro de aprovação continha apenas a stringcdn.polyfill.io, a equipe poderia tratar erroneamente a dependência como inalterada enquanto a URL permanecesse inalterada. Na realidade, a parte por trás do nome estável havia mudado.

Uma aprovação responsável deve registrar a base da confiança, não apenas o endereço. Essa base poderia incluir o operador, propósito do serviço, características esperadas de resposta, relacionamento contratual ou comunitário, evidência de auditoria disponível, plano de contingência e gatilhos de revisão. Uma transferência de propriedade invalidaria ou pelo menos reabriria a aprovação. Sem tal registro, uma organização não pode explicar facilmente por que a delegação continuada permanecia justificada após a premissa mudar.

A questão da necessidade também deveria ter sido reaberta. Polyfills estão ligados à capacidade do navegador. As populações de navegadores evoluem, as políticas de suporte de produtos mudam e o código de compatibilidade que antes era essencial pode se tornar residual. Uma dependência remota com autoridade ao nível da página não deve persistir apenas porque ninguém é dono da sua remoção. Os avisos de fevereiro ofereceram um momento para perguntar se o suporte a navegadores antigos ainda exigia o endpoint e se um pacote local menor poderia atender à necessidade restante.

Nada disso prova que todos os sites que mantiveram a referência agiram com negligência, e não transforma a transferência de domínio em si em um ataque. Estabelece um ponto mais restrito: a transferência alterou um controle de software material mesmo antes que uma saída prejudicial fosse observada. A responsabilidade do site começa com saber se essa mudança material era detectável e revisível.

Entrega seletiva tornou a inspeção casual não confiável

Em 25 de junho, a Sansec relatou quecdn.polyfill.ioestava entregando JavaScript modificado através de sites que o incorporavam. O comportamento observado redirecionava visitantes selecionados através de domínios projetados para se assemelhar ao Google Analytics em direção a destinos de golpe ou apostas. Sansec descreveu condições que incluíam segmentação móvel, verificações no servidor e no cliente, comportamento baseado em tempo e evitação de alguns contextos de administrador ou análise. [1]

O ato observado precisa de um substantivo preciso. Foi uma campanha de redirecionamento entregue através de JavaScript modificado. O registro não suporta a atualização dessa observação para roubo de credenciais, roubo de dados da página, comprometimento do host, execução de código fora do navegador ou uma perda financeira quantificada. Um endpoint de script controlado remotamente poderia, em princípio, retornar JavaScript capaz de uma gama muito mais ampla de ações no navegador. O CNCF TAG Security, CWE-830 e o modelo geral de execução do navegador suportam essa conclusão de capacidade.

Capacidade não é evidência de que cada ação possível ocorreu. [8][16]

Cloudflare disse que seus dados do Page Shield corroboravam os indicadores e incluíam correspondências desde 8 de junho. Essa é a correspondência mais antiga no conjunto de dados da Cloudflare descrito no registro da fonte. Não é prova de que toda atividade maliciosa começou nessa data, que o mesmo ramo alcançou todos os sites continuamente a partir de então ou que nenhuma entrega anterior ocorreu fora da visibilidade da Cloudflare. [5]

A Akamai descreveu separadamente um padrão de dois estágios em que a seleção no servidor com base em cabeçalhos de requisição poderia determinar o que era enviado, seguida por verificações no cliente antes do redirecionamento. Essa arquitetura explica por que a inspeção comum poderia perder o problema. Um desenvolvedor solicitando o script de um navegador de desktop poderia receber um polyfill esperado. Um visitante móvel com cabeçalhos, localização, tempo ou estado de página diferentes poderia receber ou ativar outro ramo. [9]

A entrega seletiva altera o ônus da evidência. Um único download limpo não prova segurança histórica. Uma comparação de código-fonte de um navegador em um momento pode mostrar apenas a resposta selecionada para aquela requisição. Um rastreador de mecanismo de busca, monitor de uptime ou scanner de segurança pode ter características deliberadamente excluídas pela lógica de entrega. Um administrador testando enquanto logado pode ver comportamento diferente de um visitante de primeira viagem.

Isso não significa que a detecção era impossível. Significa que o monitoramento tinha que corresponder à variabilidade da dependência. A observação útil amostraria navegadores, dispositivos, locais e condições de requisição; preservaria corpos de resposta e hashes ao longo do tempo; detectaria novos domínios e cadeias de redirecionamento; e compararia o comportamento visto por clientes reais com o propósito declarado do serviço. O monitoramento no lado do cliente tinha um papel importante porque o programa consequente era montado e executado no navegador.

O incidente também ilustra como a otimização pode se tornar camuflagem. A segmentação dinâmica do navegador fazia parte do modelo de serviço legítimo do Polyfill.io: o serviço selecionava código de compatibilidade de acordo com as capacidades do navegador. Um ramo malicioso poderia explorar a expectativa de que as respostas naturalmente diferem. A variabilidade em si não era prova de abuso. Tornou mais difícil aplicar um modelo simples de "hash conhecido igual a serviço seguro" e deu à entrega seletiva espaço para se esconder dentro de um padrão operacional aceito.

A responsabilidade depende, portanto, de definir a variabilidade esperada. Um site deve ser capaz de declarar quais atributos de requisição o provedor usa legitimamente, quais famílias de código podem ser retornadas, quais destinos o script pode contatar e quais ações da página estão fora do propósito. Sem essa linha de base, o monitoramento pode observar mudança sem saber se a mudança é autorizada.

A amostragem no servidor também complica a investigação retrospectiva. O repositório estático de um site pode conter apenas a URL do script, não os bytes maliciosos que um visitante recebeu. Os bytes vieram de outro sistema no momento da requisição e podem não estar mais disponíveis após a contenção. Telemetria do navegador, logs de CDN, respostas salvas, relatórios de segurança de conteúdo e registros de endpoint podem ser a única evidência para reconstruir o alcance. Se esses registros nunca foram coletados ou foram retidos muito brevemente, um site pode não ser capaz de responder quais visitantes encontraram o ramo.

Essa incerteza não deve ser escondida com uma afirmação ampla de que todos estavam seguros ou todos estavam comprometidos. Uma declaração de incidente responsável pode, em vez disso, definir o que foi encontrado: o endpoint foi referenciado; um caminho condicional particular era alcançável ou não; a telemetria cobria datas e populações especificadas; os redirecionamentos observados correspondiam ou não a indicadores conhecidos; e permanecem lacunas para requisições fora da evidência retida.

A entrega seletiva é, portanto, central para o teste de responsabilidade. Explica como a saída prejudicial podia coexistir com inspeção benigna, por que referências de endpoint não são contagens de vítimas e por que a remediação verificada requer mais do que carregar a página uma vez após o domínio ser suspenso.

Estimativas de escala não eram contagens de vítimas

A Sansec descreveu mais de 100.000 sites como incorporando ou usando o serviço. A Cloudflare citou estimativas de que o Polyfill.io aparecia em cerca de quatro por cento dos sites. Esses números transmitem a amplitude potencial de um serviço amplamente reutilizado. Eles não compartilham o mesmo denominador, e nenhum estabelece um conjunto completo de comprometimentos confirmados. [1][5]

Várias populações devem permanecer separadas. Uma é o conjunto de sites cujo código atual ou histórico referenciou um endpoint Polyfill.io. Outra é o conjunto para o qual o caminho de inclusão relevante era alcançável em produção. Uma terceira é o conjunto que solicitou uma resposta maliciosa durante a campanha. Uma quarta é o conjunto cujos visitantes satisfizeram as condições do servidor e do cliente. Uma quinta é os visitantes que foram realmente redirecionados. Uma sexta é qualquer população que sofreu uma perda mensurável posterior.

O registro público disponível não fornece uma contagem verificada para a maioria desses grupos. Portanto, seria impreciso chamar cada referência de vítima, cada site que inclui de comprometido ou cada visitante de exposto. Seria igualmente impreciso descartar referências como inofensivas simplesmente porque a entrega seletiva impediu a observação universal. Uma referência estabelece um caminho de confiança. Evidência adicional é necessária para estabelecer alcance, entrega e impacto.

Esse vocabulário importa para notificações downstream. "Nosso código continha uma referência" é diferente de "nossa telemetria mostra que o script foi solicitado." Ambos diferem de "observamos o ramo malicioso" e de "um visitante relatou um redirecionamento." Combiná-los pode criar alarme desnecessário ou falsa segurança. Separar permite que os usuários entendam o que a organização sabe.

O tratamento da Wordfence sobre padrões de plugins WordPress afetados reforça esse limite. Seu catálogo identificou usos do Polyfill.io, mas alertou contra assumir que cada instância de plugin entregou conteúdo malicioso. Plugins podiam introduzir o endpoint em muitos sites, tornando o trabalho de inventário urgente, enquanto a presença do código ainda ficava aquém de provar execução maliciosa em cada instalação. [14]

Relatórios governamentais repetiram a séria preocupação de escala enquanto focavam os operadores em remoção e investigação. CERT-AGID descreveu a aquisição e entrega dependente de cabeçalho e referiu-se ao número de mais de 100.000. Esse aviso independente suporta atenção defensiva ampla, mas não muda o denominador para visitantes afetados confirmados. [21]

A afirmação de escala mais forte é, portanto, também a mais limitada: o endpoint tinha uma grande pegada downstream, e a campanha seletiva observada criou risco através dessa pegada. O impacto exato tinha que ser estabelecido site por site e população de visitantes por população.

Contenção mudou o caminho; não terminou a remediação

A resposta envolveu partes com diferentes tipos de controle. Cloudflare reescreveu automaticamente as referências ao Polyfill.io nas páginas de clientes proxy para um espelho hospedado pela Cloudflare. A empresa explicou que simplesmente bloquear o domínio original poderia quebrar sites que ainda dependiam do serviço. A reescrita tentava preservar a compatibilidade esperada enquanto removia a dependência imediata do endpoint alterado. [5]

Essa intervenção ilustra uma verdadeira troca operacional. Equipes de segurança frequentemente preferem remoção imediata de um recurso suspeito. Equipes de produto sabem que eliminar abruptamente uma camada de compatibilidade pode tornar um site inutilizável para alguns visitantes. A posição da Cloudflare na cadeia de entrega permitiu que substituísse uma fonte diferente sem esperar que cada proprietário de site implementasse uma mudança.

A substituição foi contenção, não prova de reparo completo. Mudou o operador confiável e o caminho de resposta para o tráfego coberto pelo mecanismo. Não estabeleceu que a substituição tinha comportamento idêntico para todos os navegadores, que todas as páginas e caminhos de entrega estavam cobertos, ou que os repositórios downstream não continham mais a referência antiga. Também não respondeu o que os visitantes receberam antes da reescrita.

Namecheap então colocou o domínio Polyfill.io em espera, e avisos governamentais descreveram o endpoint como suspenso em 27 de junho. A ação ao nível do domínio removeu o caminho de serviço imediato, mas também podia quebrar sites que ainda esperavam uma resposta. A espera foi uma importante alavanca de contenção detida pelo registrador. Ela não limpou templates downstream, configurações de plugins, páginas em cache, configurações de gerenciadores de tags ou produtos de fornecedores. [6][10]

A diferença torna-se mais clara quando o domínio está indisponível. Um site pode parecer protegido porque o navegador não pode mais recuperar o script suspeito. No entanto, a referência obsoleta permanece uma dependência não resolvida. Se o status de controle mudar novamente, se um hostname alternativo persistir, ou se uma cópia interna não foi examinada, o problema de governança subjacente permanece. Mesmo um endpoint permanentemente morto pode impor custos de desempenho, tratamento de erros e compatibilidade.

CERT-FR e a Unidade de Segurança Cibernética da Austrália Ocidental aconselharam os operadores a identificar e remover referências, migrar para uma alternativa controlada quando necessário e considerar controles do navegador como Subresource Integrity e Content Security Policy. Semgrep também focou na detecção em todo o repositório, em vez de tratar a suspensão do domínio como suficiente. [6][7][20]

Essa sequência sugere quatro alegações de encerramento distintas. "Contido" significa que o caminho de entrega prejudicial conhecido foi interrompido. "Removido" significa que a referência downstream e os caminhos de inserção transitivos desapareceram. "Investigado" significa que a evidência disponível foi usada para avaliar alcance e impacto históricos. "Verificado" significa que testes e monitoramento demonstram que o site atual não depende mais do caminho antigo e que a substituição se comporta dentro do escopo pretendido.

Um proprietário de site podia confiar em um provedor de infraestrutura para a primeira alegação enquanto ainda possuía as outras três. Cloudflare podia reescrever o tráfego que via. Namecheap podia suspender um domínio que registrou. Nenhum dos dois podia saber todos os lugares onde um cliente tinha incorporado a URL, cada caminho condicional de navegador dentro de um plugin ou cada população de visitantes que o site precisava investigar.

Essa separação também protege contra exagerar a intervenção de terceiros. Uma retenção de registrador não é uma conclusão de atribuição. Reescrita automática não estabelece que todo cliente protegido serviu o ramo malicioso. Uma correspondência de indicador de um fornecedor de detecção não é um relatório forense completo para cada site. Cada ação deve ser descrita de acordo com o controle que exerceu e a evidência que produziu.

Operacionalmente, a remediação downstream deve começar com uma busca completa. O hostname literal pode aparecer em arquivos fonte, pacotes gerados, campos de gerenciamento de conteúdo, código de plugin, gerenciadores de tags, templates, configurações arquivadas ou respostas de fornecedores. Ferramentas de busca podem encontrar strings conhecidas, mas um inventário de dependências também deve explicar quem introduziu a referência e qual caminho de build ou runtime a tornou ativa.

A remoção então precisa de uma decisão funcional. Se o polyfill não for mais necessário, eliminá-lo é a redução mais limpa de autoridade. Se o suporte a navegadores legados ainda for necessário, um pacote local revisado ou um provedor explicitamente aprovado pode ser apropriado. A substituição não deve ser escolhida apenas porque sua URL é conveniente. Seu operador, processo de atualização, variabilidade de resposta e modelo de monitoramento tornam-se parte da nova base de confiança.

Finalmente, a avaliação histórica requer evidência proporcional ao risco do site. Observações do lado do navegador, logs de rede, relatórios de segurança, reclamações de clientes e respostas de script preservadas podem ajudar a determinar se indicadores de redirecionamento conhecidos apareceram. Ausência de evidência deve ser vinculada à cobertura. Um site sem telemetria de cliente retida pode dizer que não encontrou relatos ou indicadores nos registros disponíveis; não pode converter registros faltantes em prova de que nenhum visitante recebeu o ramo.

Fides mostrou por que um ramo condicional ainda importa

CVE-2024-38537 registra um problema downstream no Fides. O caminho relevantefides.jspodia carregar Polyfill.io para navegadores legados. O registro identifica versões afetadas e diz que a versão 2.39.1 removeu a exposição. Também preserva uma fronteira importante: nenhuma exploração através do Fides foi identificada. [11][12]

Esse caso é útil porque resiste a dois erros opostos. O primeiro descartaria o problema porque apenas um caminho de navegador antigo carregava o endpoint. Acessibilidade condicional ainda é acessibilidade. Se uma página de produção podia solicitar JavaScript remoto para uma população de visitantes suportada, a dependência pertencia ao inventário de segurança do produto, mesmo que a maioria dos desenvolvedores nunca a acionasse.

O segundo erro trataria o CVE como prova de que usuários do Fides foram explorados. Um registro de vulnerabilidade pode estabelecer um caminho de inclusão inseguro e versões afetadas sem estabelecer que o ramo malicioso alcançou uma implantação particular. "Podia carregar" e "foi observado explorando" respondem perguntas diferentes. O registro do Fides manteve explicitamente essa distinção.

A remediação também demonstra por que o reparo versionado importa. Remover a dependência remota em um lançamento nomeado dá aos operadores downstream uma ação concreta e um limite rastreável. Eles podem identificar versões implantadas, atualizar, escanear por referências restantes e testar o caminho legado. Um aviso geral para "ter cuidado com Polyfill.io" não forneceria a mesma evidência de encerramento.

A condição legada deve moldar a verificação. Testar apenas um navegador desktop moderno pode nunca executar o ramo afetado. A verificação deve reproduzir ou inspecionar a condição que originalmente o selecionava. Isso pode exigir revisar código empacotado, simular um user agent antigo, verificar requisições de rede e confirmar que a versão reparada não constrói ou solicita mais o endpoint.

O boletim da SingCERT também discutiu o caso downstream do Fides e reteve o limite de nenhuma exploração observada. A repetição por um CERT nacional aumenta a visibilidade da questão; não converte a possibilidade em exploração observada. [22]

A lição do Fides é, portanto, não que toda requisição condicional de terceiros merece a mesma gravidade. É que um mantenedor deve conhecer a condição, versões afetadas, população alcançável, versão de remediação e limite de evidência. A responsabilidade é mais forte quando um registro formal de vulnerabilidade diz tanto o que podia acontecer quanto o que não foi observado.

Jellyfish mostrou como rastrear uma dependência transitiva

O aviso da Jellyfish documentou um caminho diferente. Seu serviço dependia de um fornecedor que podia carregar Polyfill.io sob condições especiais. Jellyfish identificou o relacionamento transitivo, contatou o fornecedor, verificou a remoção e delimitou a população de navegadores que poderia ter alcançado o caminho. [13]

Essa sequência é um modelo prático porque começa com arquitetura em vez de acusação. Uma organização voltada para o cliente pode não ter colocado a tag de script diretamente em seu próprio repositório. A referência pode vir de um componente de análise, ferramenta de consentimento, plugin, widget de suporte ou código de outro fornecedor. A propriedade direta da linha não é o mesmo que controle sobre a experiência do usuário.

Dependências transitivas criam um problema de evidência. Uma lista de materiais de software orientada a pacotes instalados no momento da construção pode não incluir um domínio que um fornecedor solicita dinamicamente no navegador. Inventários contratuais podem nomear o fornecedor, mas não os próprios fornecedores de script do fornecedor. O monitoramento de rede pode ver o hostname sem identificar o proprietário do negócio que o introduziu. Todas as três visões são necessárias para conectar uma requisição a um relacionamento responsável.

A sequência de resposta da Jellyfish aborda essas lacunas. Primeiro, identificar que a dependência existe e as condições sob as quais pode ser invocada. Segundo, mapeá-la ao relacionamento com o fornecedor. Terceiro, pedir à parte com controle de código que a remova. Quarto, verificar a mudança em vez de tratar a garantia do fornecedor como o fim da questão. Quinto, delimitar a população usando a melhor evidência disponível de navegador e produto.

A verificação é especialmente importante quando a condição é incomum. Um fornecedor pode remover uma referência visível enquanto uma alternativa, pacote antigo ou ativo em cache ainda a contém. O cliente deve testar de fora além de aceitar confirmação interna. Captura de rede através de navegadores relevantes, varreduras de repositório ou pacote e monitoramento no lado do cliente podem mostrar se a requisição realmente desapareceu.

A população delimitada deve reter seu denominador. Se apenas certas versões de navegador ou fluxos de página podiam acionar o caminho do fornecedor, a investigação pode restringir o alcance potencial. Não deve implicar que todo membro daquele grupo de navegadores recebeu conteúdo malicioso. Inversamente, o fato de um caminho ser raro não desculpa falhar em removê-lo. Caminhos raros frequentemente recebem menos testes de rotina, o que pode torná-los lugares atraentes para dependências persistirem despercebidas.

Jellyfish também demonstra responsabilidade compartilhada, mas não fungível. O fornecedor controlava seu código e podia remover a inclusão. A Jellyfish controlava a escalação do fornecedor, investigação voltada ao cliente e aceitação do reparo. Provedores de infraestrutura e segurança podiam contribuir com telemetria. Nenhuma dessas partes podia substituir completamente a outra.

Esse modelo escala além deste incidente. Uma organização downstream precisa de uma rota de escalação para qualquer fornecedor capaz de introduzir código executável. O contrato ou processo de integração técnica deve identificar quem pode responder a perguntas urgentes sobre dependências, quão rapidamente um script de terceiros pode ser desabilitado, quais logs estão disponíveis e como o cliente pode verificar uma mudança.

Plugins WordPress mostraram por que referências e exploração devem permanecer separadas

Wordfence catalogou o uso do Polyfill.io em vários padrões de plugins WordPress. Esse tipo de inventário é valioso porque os plugins podem distribuir uma dependência externa por muitos sites operados independentemente. Uma pequena decisão de mantenedor pode se tornar um amplo relacionamento de confiança downstream sem que cada proprietário de site adicione conscientemente o endpoint. [14]

O catálogo também trazia um aviso crucial: o uso do endpoint não provava que todo plugin ou site entregou conteúdo malicioso. A referência identificava um caminho de execução potencial. Se esse caminho estava ativo dependia da versão do plugin, configuração, renderização da página, cache, condições do navegador e da resposta remota no momento.

Para um proprietário de site WordPress, a resposta correta não é debater se o autor do plugin ou operador do serviço é "o verdadeiro" responsável. As tarefas imediatas são locais: identificar versões instaladas e ativas, determinar quais páginas renderizam a referência, atualizar ou remover componentes afetados, limpar ativos gerados quando necessário e verificar o comportamento de rede do site público.

O mantenedor do plugin tem um conjunto diferente de tarefas. Pode remover a dependência, publicar uma versão corrigida, explicar condições afetadas, atualizar documentação e notificar usuários. Um repositório de plugins ou serviço de segurança pode distribuir avisos. O proprietário do site ainda tem que implantar a mudança. Uma versão corrigida sentada desinstalada não altera o caminho do navegador.

Essa é outra razão pela qual os números de escala não devem ser lidos como uma contagem de organizações prejudicadas. Um plugin pode criar milhares de referências; um site pode conter vários plugins com o mesmo hostname; um plugin dormente ou desabilitado pode permanecer em disco sem renderizar o script; e uma página pública em cache pode continuar servindo uma referência antiga após alterações no código-fonte. Contar strings, instalações, requisições ativas e entregas maliciosas produz números diferentes.

Um ecossistema responsável mantém essas medidas rotuladas. A inteligência de segurança pode publicar uma ampla lista de exposição para acelerar a ação. Mantenedores podem declarar versões afetadas. Proprietários de sites podem relatar alcance implantado. Investigadores de incidentes podem relatar indicadores observados. Nenhum deve tomar emprestada certeza dos outros.

SRI e CSP eram controles, não respostas mágicas

Subresource Integrity, ou SRI, permite que um autor de página forneça um resumo criptográfico para um recurso externo. Um navegador compatível pode buscar o recurso e se recusar a executá-lo se os bytes retornados não corresponderem ao resumo esperado. A especificação do W3C e o guia de implementação da MDN apresentam SRI como uma forma de evitar que um host de terceiros comprometido altere silenciosamente um recurso que o site que inclui espera que permaneça fixo. [18][19]

Isso é um controle forte para um script estável. Converte uma delegação aberta em aprovação de bytes específicos. Se o host retornar qualquer outra coisa, o navegador bloqueia a execução. O site pode então atualizar o resumo através de seu próprio processo de implantação após revisar uma nova versão.

O design legítimo do Polyfill.io complica esse modelo porque o serviço intencionalmente gerava diferentes conjuntos de acordo com as capacidades do navegador e parâmetros de requisição. Um resumo estável não pode aprovar muitas sequências de bytes válidas a menos que o site mude como consome o serviço. Uma equipe poderia pré-calcular e aprovar um conjunto limitado de recursos fixos em algumas arquiteturas, mas anexar um hash a um endpoint cujo propósito é seleção dinâmica de resposta provavelmente quebraria o comportamento esperado ou deixaria variação importante não vinculada.

A conclusão correta não é que SRI é inútil. É que a escolha de controle deve corresponder ao modelo de recurso. Se um site quer fixação de integridade, pode precisar parar de pedir a um serviço remoto que gere bytes arbitrários específicos da requisição. Auto-hospedar um pacote revisado, servir variantes versionadas fixas ou restringir navegadores suportados pode tornar a aprovação ao nível de byte prática.

Content Security Policy, ou CSP, aborda uma camada diferente. Uma política pode restringir quais origens podem fornecer scripts e pode usar nonces, hashes ou diretivas relacionadas para restringir a execução. Pode bloquear domínios inesperados e reduzir a liberdade de marcação injetada para carregar novos recursos. Mas secdn.polyfill.ioé explicitamente permitido como uma origem de script confiável, uma resposta maliciosa aprovada pela origem não se torna confiável por aparecer na lista de permissões.

CSP ainda pode ajudar a conter comportamento secundário. Uma política cuidadosamente projetada pode restringir conexões, frames ou navegações envolvidas em uma cadeia de ataque, e relatórios de violação podem adicionar evidência de detecção. O efeito exato depende da política e do comportamento do navegador. A limitação central permanece: aprovação de origem responde de onde o código pode vir, não se o operador aprovado sempre retornará código aceitável.

Espelhamento move o limite de confiança novamente. Um site ou provedor de infraestrutura busca ou mantém uma cópia e a serve de um local controlado. Isso pode impedir que o domínio original mude bytes no momento da requisição. Também cria obrigações sobre como o espelho é obtido, revisado, atualizado e protegido. A reescrita automática para o espelho da Cloudflare foi contenção útil, mas selecionou a Cloudflare como a nova autoridade operacional; não eliminou o conceito de confiança.

Auto-hospedagem dá ao proprietário do site controle mais direto sobre a entrega. Pode revisar uma versão, implantá-la com a aplicação e monitorar mudanças através de seu processo normal de lançamento. Auto-hospedagem não garante código seguro. Restringe quem pode alterar a resposta de produção e torna mais fácil vincular os bytes implantados a um lançamento.

Remoção é mais forte quando a função é desnecessária. Se o suporte atual do navegador não requer mais um serviço de polyfill, o script remoto de menor risco é aquele que a página não solicita. É por isso que a revisão do ciclo de vida pertence junto com os controles de segurança. Decisões de compatibilidade tomadas anos antes não devem se tornar concessões permanentes de autoridade.

Sandboxing pode reduzir alguma influência de terceiros quando a funcionalidade pode ser executada em um frame restrito ou contexto isolado. Nem todo script pode ser movido para lá sem mudar o produto. Um polyfill destinado a modificar o ambiente JavaScript da página está especialmente ligado ao contexto de execução principal, o que limita a utilidade do isolamento. Essa limitação deve influenciar se a conveniência ainda vale a autoridade.

Ferramentas de varredura de código ajudam a encontrar referências conhecidas. A orientação específica do CodeQL para Polyfill enfatiza diligência de propriedade, revisão de logs, auto-hospedagem e as limitações dos controles de integridade para conteúdo dinâmico. Semgrep propôs buscas no repositório e regras para identificar uso do Polyfill.io após o incidente. [15][20]

A varredura estática sozinha é incompleta porque a injeção em tempo de execução pode vir de sistemas de conteúdo, gerenciadores de tags ou fornecedores. A observação em tempo de execução sozinha é incompleta porque condições raras podem não ocorrer durante a amostra. Uma pilha de controle madura combina varredura de fonte e pacote, um inventário de scripts de terceiros, monitoramento de DNS e propriedade, telemetria do lado do navegador, revisão de mudanças e um mecanismo de desativação de emergência.

A pilha também deve especificar o comportamento de falha. Se um polyfill falha ao carregar, a página perde um aprimoramento menor, torna-se inutilizável ou impede uma transação crítica? Equipes que entendem o impacto da falha podem remover ou bloquear um recurso suspeito rapidamente sem improvisar durante um incidente. Se a continuidade depende do recurso, uma alternativa local testada é mais segura do que descobrir a dependência quando um registrador suspende o domínio.

Controles não são, portanto, um menu do qual um acrônimo da moda pode ser selecionado. São uma sequência de decisões: remover autoridade desnecessária, tornar o código necessário fixo onde possível, restringir de onde pode vir, observar o que faz, preservar evidência e manter um caminho testado para desabilitá-lo ou substituí-lo.

Responsabilidade deve seguir os controles que cada parte tinha

O incidente envolveu um operador de serviço, proprietários de sites, provedores de infraestrutura, um registrador, pesquisadores de segurança, mantenedores de plugins e produtos, e fornecedores cujo código introduziu o endpoint. Suas responsabilidades se sobrepunham, mas não eram intercambiáveis.

O operador que controlava o serviço hospedado Polyfill.io detinha a autoridade mais direta sobre a resposta retornada por esse serviço. Isso é diferente de manter o código aberto original. A responsabilidade nesta camada diz respeito à custódia do domínio e caminho de implantação, controle de mudanças, integridade da resposta, visibilidade na entrega e comunicação precisa sobre a operação. O registro disponível não deve ser esticado até uma conclusão sobre cada ator individual, relação corporativa ou dever legal.

Fastly e Cloudflare detinham capacidades de infraestrutura e substituição. Seus avisos de fevereiro podiam alertar e oferecer alternativas. A posição posterior da Cloudflare permitia reescrita automática e telemetria no lado do cliente para o tráfego coberto. Esses controles eram significativos, mas não davam a nenhum dos provedores conhecimento completo da fonte, configuração ou impacto no visitante de cada site downstream. [2][3][5]

Namecheap detinha uma alavanca de contenção ao nível de registrador. Colocar o domínio em espera interrompia a resolução ou uso do endpoint. Essa ação reduziu a exposição imediata enquanto potencialmente quebrava sites dependentes. O controle do registrador podia parar um caminho; não podia corrigir aplicações ou estabelecer entrega histórica para cada site. [10]

Pesquisadores de segurança e respondedores governamentais detinham capacidades de detecção, análise e aviso. Sansec publicou indicadores e comportamento observado. Akamai e Cloudflare adicionaram perspectivas de telemetria. CERT-FR, Austrália Ocidental, CERT-AGID e SingCERT traduziram o incidente em orientação operacional para seus públicos. Essas partes podiam aumentar a visibilidade e recomendar controles; não podiam implantar correções em todos os sites. [1][5][6][7][9][21][22]

Mantenedores de plugins, bibliotecas e fornecedores controlavam código que podia introduzir a dependência transitivamente. Suas ações responsáveis incluíam identificar versões e condições afetadas, remover o endpoint, lançar uma correção, comunicar escopo e preservar a distinção entre exposição potencial e exploração observada. Fides e os registros de plugins WordPress mostram por que a versão e a evidência de alcance importam. [11][12][14]

Proprietários de sites controlavam a decisão final de inclusão, mesmo quando executá-la exigia que um fornecedor ou mantenedor mudasse código. Podiam definir navegadores suportados, aprovar provedores de script terceiros, manter inventários, monitorar propriedade, bloquear ou reescrever recursos, auto-hospedar código revisado, reter evidência do navegador, investigar reclamações e comunicar com visitantes.

Isso não implica culpa igual. Um operador de site pequeno pode ter muito menos visibilidade e especialização do que uma empresa global de infraestrutura. Um fornecedor pode ser a única parte capaz de mudar uma alternativa empacotada. Um registrador pode ser a única parte capaz de suspender um domínio rapidamente. Responsabilidade segue o controle prático e a evidência disponível para exercê-lo, não uma suposição de que todo participante tinha a mesma capacidade.

Um mapa de dever útil pode ser organizado em torno de seis perguntas.

Primeiro, quem podia prevenir exposição desnecessária? Proprietários de sites e produtos podiam revisar o suporte do navegador e remover a dependência. Mantenedores podiam parar de recomendá-la ou agrupá-la. Provedores podiam oferecer caminhos de migração mais seguros.

Segundo, quem podia detectar confiança alterada? Monitores de domínio e infraestrutura podiam observar mudanças de propriedade, DNS e roteamento. Mantenedores de projeto podiam rastrear controle de conta e documentação. Proprietários de sites podiam se inscrever em avisos relevantes e revisar dependências de alta autoridade quando seu operador mudava.

Terceiro, quem podia observar entrega prejudicial? O operador do serviço e provedores de infraestrutura podiam ver respostas no servidor. Proprietários de sites e serviços de segurança no lado do cliente podiam ver comportamento do navegador. Pesquisadores podiam comparar amostras entre condições. Nenhuma visão única cobria necessariamente toda a campanha.

Quarto, quem podia conter o caminho? O operador podia parar a entrega, o registrador podia suspender o domínio, provedores de infraestrutura podiam reescrever ou bloquear tráfego, mantenedores podiam lançar correções, e proprietários de sites podiam desabilitar ou remover referências.

Quinto, quem podia investigar o impacto? Cada proprietário de site detinha sua própria arquitetura de página, registros de visitantes, reclamações e histórico de implantação. Fornecedores detinham informações sobre condições transitivas. Provedores de infraestrutura detinham telemetria selecionada de tráfego e resposta. Investigação exigia cooperação sem fingir que o conjunto de dados de uma parte representava todos os visitantes.

Sexto, quem podia verificar o reparo e comunicá-lo? Mantenedores podiam vincular correções a versões. Fornecedores podiam mostrar remoção. Proprietários de sites podiam testar o caminho público e declarar o que sua evidência cobria. Órgãos governamentais e de segurança podiam atualizar orientação. A verificação tinha que permanecer delimitada à visibilidade da parte.

Este mapa torna a responsabilidade testável. Em vez de perguntar apenas quem causou o incidente, pergunta qual parte podia responder a cada pergunta de prevenção, detecção, contenção, investigação e reparo. Também expõe lacunas de controle. Se ninguém monitorava propriedade de domínio para um script com autoridade ao nível da página, a lacuna existia antes do ramo malicioso aparecer.

O que um site downstream deve ser capaz de provar

Uma resposta downstream credível pode ser expressa como uma cadeia de evidência, em vez de uma garantia genérica.

A cadeia começa com inventário. A organização deve identificar cada referência direta e transitiva ao Polyfill.io, o componente ou fornecedor que a introduziu, as páginas que a renderizavam e as condições do navegador que a tornavam alcançável. Os resultados da busca devem ser conectados ao comportamento implantado, não deixados como uma lista de arquivos correspondentes.

Em seguida vem a necessidade. O proprietário deve documentar se a função de compatibilidade ainda é necessária para os navegadores que intencionalmente suporta. Se não, a remoção deve ser preferida. Se for necessária, a organização deve explicar por que a substituição escolhida ou versão auto-hospedada é proporcional à necessidade.

O terceiro passo é a reavaliação da confiança. O registro deve mostrar quando a organização soube da transição de propriedade ou incidente de junho, quem tomou a decisão de continuar, bloquear, substituir ou remover o serviço, e que evidência apoiou essa decisão. Uma revisão em fevereiro e uma resposta de emergência em junho são eventos diferentes e não devem ser colapsados.

O quarto passo é o escopo histórico. A organização deve declarar quais datas, populações de visitantes e fontes de telemetria examinou. Deve separar referências de endpoint, requisições, correspondências de indicadores conhecidos, redirecionamentos e danos relatados. Se logs estão faltando, a lacuna deve permanecer explícita.

O quinto passo é o reparo. O proprietário deve vincular a mudança a um lançamento, configuração ou confirmação do fornecedor. Deve considerar ativos gerados, caches, plugins, gerenciadores de tags e ramos condicionais. Meramente observar que o domínio suspenso não responde mais não é evidência de remoção.

O sexto passo é a verificação. Testes devem cobrir condições relevantes do navegador e confirmar que a página pública não faz requisição ao endpoint antigo. O monitoramento deve procurar reintrodução, origens de script inesperadas e comportamento de redirecionamento. Onde um fornecedor forneceu a correção, o cliente deve verificar o resultado externo.

O sétimo passo é a comunicação. Um aviso deve usar definições estáveis e evitar converter uso em vitimização. Deve explicar que dependência existia, se era alcançável, que evidência de entrega maliciosa foi ou não encontrada, o que mudou e quais incertezas permanecem. Os usuários precisam de fatos práticos, não de uma declaração ampla de que a questão foi "resolvida."

Finalmente, o proprietário deve atualizar seus controles de ciclo de vida. Scripts remotos de alta autoridade precisam de proprietários nomeados, datas de revisão, registros de base de confiança, monitoramento de domínio e operador, caminhos de desativação de emergência e retenção de evidência útil do navegador. Caso contrário, a mesma falha de governança pode se repetir sob um hostname diferente.

Essas provas não exigem divulgação de detalhes defensivos sensíveis. Exigem especificidade suficiente para tornar a resposta falseável. Um visitante, cliente ou revisor deve ser capaz de distinguir "removemos a string" de "encontramos todos os caminhos ativos," e "não vimos exploração" de "nossa evidência a descarta para a população coberta."

Uma transferência de domínio pode ser uma mudança de software

Polyfill.io tornou um princípio simples difícil de ignorar: quando um domínio retorna código executável, a propriedade do domínio é parte do estado de segurança do software. A URL pode permanecer estável enquanto o fornecedor efetivo muda. Um repositório pode permanecer público enquanto a resposta hospedada se move sob controle diferente. HTTPS pode permanecer válido enquanto a base de confiança que justificava a inclusão não existe mais.

Os avisos de fevereiro mostraram que essa mudança era visível e acionável. Os relatórios de junho mostraram por que importava. A entrega seletiva de redirecionamento explorou um modelo no qual diferentes visitantes podiam legitimamente receber código diferente, tornando a inspeção casual uma garantia fraca. A reescrita posterior e a suspensão do domínio restringiram o caminho, mas apenas inventário, remoção, investigação e verificação downstream podiam fechar a parte de cada site do problema.

O incidente não justifica chamar mais de 100.000 sites de vítimas confirmadas. Não prova que cada referência serviu conteúdo malicioso, que cada visitante foi exposto ou que cada produto downstream foi explorado. Também não justifica descrever o código aberto original como universalmente malicioso ou tratar uma cópia auto-hospedada como idêntica ao relacionamento hospedado comprometido.

Tampouco o evento suporta um veredito legal ou uma história de atribuição completa a partir do registro disponível. Responsabilidade aqui é mais restrita e mais operacional. É a obrigação de explicar por que a autoridade executável foi delegada, como o controle alterado foi detectado, que evidência estabeleceu alcance, qual ação reduziu a exposição e como o reparo foi verificado.

O operador do serviço, empresas de infraestrutura, registrador, mantenedores, fornecedores e proprietários de sites detinham diferentes peças dessa resposta. A responsabilidade era compartilhada porque o sistema era compartilhado, mas não era fungível. Um registrador podia suspender um domínio e ainda deixar código obsoleto para trás. Um fornecedor podia remover uma referência e ainda carecer da telemetria de visitante do cliente. Um site podia investigar seus usuários e ainda depender de uma parte upstream para mudar um componente agrupado.

Para proprietários downstream, o padrão durável é direto: conheça toda parte externa que pode escolher código para seus visitantes; monitore os fatos que tornaram essa parte confiável; remova autoridade que não serve mais a uma função necessária; e preserve evidência suficiente para distinguir exposição, entrega e dano.

Uma tag de script pode ser uma linha de HTML, mas cria um relacionamento operacional. Quando o proprietário por trás dessa linha muda, o relacionamento de software também muda. A responsabilidade do site começa em reconhecer essa mudança antes que um visitante tenha que revelá-la.

Fontes

  1. https://sansec.io/research/polyfill-supply-chain-attack
  2. https://blog.cloudflare.com/polyfill-io-now-available-on-cdnjs-reduce-your-supply-chain-risk/
  3. https://community.fastly.com/t/new-options-for-polyfill-io-users/2540
  4. https://github.com/formatjs/formatjs/issues/4363
  5. https://blog.cloudflare.com/automatically-replacing-polyfill-io-links-with-cloudflares-mirror-for-a-safer-internet/
  6. https://cert.ssi.gouv.fr/actualite/CERTFR-2024-ACT-030/
  7. https://soc.cyber.wa.gov.au/advisories/20240626004-JavaScript-Polyfill-Supply-Chain-Attack/
  8. https://tag-security.cncf.io/community/catalog/compromises/2024/polyfill/
  9. https://www.akamai.com/blog/security/polyfill-supply-chain-attack-what-to-know
  10. https://socket.dev/blog/namecheap-takes-down-polyfill-io-service-following-supply-chain-attack
  11. https://www.cve.org/CVERecord?id=CVE-2024-38537
  12. https://nvd.nist.gov/vuln/detail/cve-2024-38537
  13. https://jellyfish.co/library/jellyfish-security-advisory-june-27-2024/
  14. https://www.wordfence.com/threat-intel/vulnerabilities/detail/various-plugins-various-version-use-of-polyfillio
  15. https://codeql.github.com/codeql-query-help/javascript/js-functionality-from-untrusted-domain/
  16. https://cwe.mitre.org/data/definitions/830.html
  17. https://cheatsheetseries.owasp.org/cheatsheets/Third_Party_Javascript_Management_Cheat_Sheet.html
  18. https://www.w3.org/TR/SRI/
  19. https://developer.mozilla.org/en-US/docs/Web/Security/Practical_implementation_guides/SRI
  20. https://semgrep.dev/blog/2024/protect-your-code-from-the-polyfill-supply-chain-attack/
  21. https://cert-agid.gov.it/news/scoperto-un-grave-attacco-alla-supply-chain-del-servizio-polyfill-io-piu-di-100-000-i-siti-coinvolti/
  22. https://isomer-user-content.by.gov.sg/36/8bee5efc-3166-44a1-89ae-0f0b095ecb17/03-July-2024.pdf