Por dentro do ataque à cadeia de suprimentos do lado do cliente de $3M contra a Polymarket

Resumo: drainer por approval-phishing de 1.893 ETH na Polymarket

• Os contratos estavam bem: Os smart contracts da Polymarket estavam bem. A blockchain funcionou exatamente como projetada. O roubo aconteceu na aba do navegador, via um script de fornecedor que a plataforma ja confiava ha meses.
• O roubo no navegador: Um fornecedor terceirizado comprometido injetou um drainer que drenou cerca de 3 milhoes de dolares de menos de 15 carteiras, lavados como 1.893 ETH via a carteira 0xe65b1C586757c5510B60F998Eebb14C1eF71E1eD. cside observa o script em runtime e bloqueia um confiavel que subitamente pede token approvals.
• Revogue approvals hoje: Se seu dApp ou checkout carrega JS de terceiros, adicione monitoramento de script em runtime neste trimestre. Se nao pode, ao menos revogue approvals de carteira sem uso hoje, foi o que todo investigador disse aos usuarios da Polymarket.

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

Em 2026-06-25, a plataforma de mercados de previsão Polymarket confirmou que atacantes haviam roubado cerca de 3 milhões de dólares de um pequeno número de usuários. O investigador on-chain Specter, que sinalizou o roubo primeiro, rastreou cerca de 2,94 milhões de dólares desviados de pelo menos 11 carteiras; a empresa de análise blockchain Bubblemaps estimou o total em menos de 15 contas e publicou os endereços envolvidos. A Polymarket conteve o incidente rapidamente, removeu a dependência responsável e se comprometeu a reembolsar integralmente cada usuário afetado.

Para qualquer pessoa que opere um site por onde circulam dinheiro ou dados sensíveis, o detalhe que importa é onde o ataque aconteceu. Os smart contracts da Polymarket nunca foram comprometidos. A blockchain funcionou exatamente como projetada. O roubo aconteceu no navegador, por meio de um script de terceiros em que a plataforma confiava. Este é um caso clássico de ataque à cadeia de suprimentos do lado do cliente, a mesma classe de ataque que atinge toda semana as páginas de pagamento de e-commerce, as páginas de login de fintech e os painéis SaaS.

A mecânica importa, porque explica por que tantas equipes estão expostas ao mesmo risco.

O que aconteceu

Em seu próprio comunicado, a Polymarket disse ter "descoberto que um fornecedor terceiro havia sido comprometido, injetando um script malicioso em nosso frontend para alguns usuários", e que havia contido o incidente e removido a dependência afetada. Até a publicação, nem a Polymarket nem a imprensa independente identificaram o fornecedor ou a dependência comprometida.

O alvo era o pUSD, a stablecoin da Polymarket lastreada em USDC e o principal colateral de negociação da plataforma. Quando os usuários afetados conectaram suas carteiras, o código injetado os induziu a assinar ou aprovar transações que, de forma silenciosa, entregavam fundos ao atacante. A empresa de segurança PeckShield relatou que o pUSD roubado foi transferido de Polygon para Ethereum e trocado por cerca de 1893 ETH, que os investigadores rastrearam até um único endereço de consolidação. Várias empresas classificaram o evento como um comprometimento da cadeia de suprimentos combinado com uma campanha de phishing que operou por meio da própria interface da plataforma.

A mecânica é simples, e se aplica a quase qualquer site moderno:

• O atacante nunca precisou invadir os servidores nem os smart contracts da Polymarket.
• Ele comprometeu um fornecedor confiável cujo código já tinha permissão para ser executado no site.
• Assim que esse código foi executado dentro do frontend ao vivo, ele parecia idêntico ao código legítimo para as pessoas que usavam o site.

Um usuário olhando para a interface normal não tinha forma prática de saber que o script que processava sua transação havia mudado. Essa é a característica que define essa classe de ataque, e é por isso que ela é tão difícil de detectar de fora.

Indicadores de comprometimento (on-chain)

Os investigadores on-chain rastrearam os fundos roubados até uma única carteira de consolidação, alimentada por seis carteiras intermediárias. Os valores abaixo somam 1.892,92 ETH, o saldo consolidado completo. Esses endereços são controlados pelo atacante e listados como referência para defensores; não são carteiras de vítimas.

Carteira de consolidação: 0xe65b1C586757c5510B60F998Eebb14C1eF71E1eD

O ângulo técnico: um drenador de carteiras entregue pela cadeia de suprimentos

A maior parte da cobertura para em "ataque à cadeia de suprimentos". O mecanismo é mais específico, e é o que torna este incidente digno de estudo.

Todo o ataque viveu na camada de execução do navegador. A camada de blockchain e de contratos inteligentes nunca foi violada: funcionou exatamente como foi projetada, porque a assinatura foi autorizada no navegador:

1. Fornecedor terceirizado comprometido. Uma dependência foi envenenada e, nas palavras da Polymarket, servida "para alguns usuários".
2. Script malicioso injetado no frontend de polymarket.com.
3. Interface real da Polymarket. O script aproveitou a UI genuína: o usuário clicava em "Conectar carteira" e, em seguida, o script apresentava uma solicitação maliciosa de aprovação / assinatura ERC-20.
4. O atacante varre o pUSD da vítima assim que a aprovação era assinada.
5. Transferido de Polygon para Ethereum, trocado por cerca de 1.893 ETH e lavado através da carteira de consolidação 0xe65b…E1eD.

Um skimmer clássico de Magecart é passivo. Ele lê o que a vítima digita em um formulário de pagamento e copia para o servidor do atacante. Este ataque não tinha nenhum formulário para roubar, então o script injetado tornou-se ativo e foi atrás da assinatura em si.

Com base na análise on-chain, quando um usuário afetado conectava sua carteira, o script apresentava uma solicitação maliciosa de aprovação ou de assinatura por meio da interface genuína da Polymarket. Aprová-la dava ao atacante a capacidade de mover o pUSD da vítima. Esta é a mesma técnica de phishing de aprovações em que os drenadores de carteiras se apoiam: conseguir que o titular assine uma aprovação ERC-20 ou um permit de tokens e depois varrer o saldo para um endereço controlado pelo atacante. O sinal mais claro é a remediação que todos os investigadores deram, que foi revogar as aprovações de tokens. Só se revogam aprovações quando as aprovações foram a arma.

Aqui está o que é diferente neste caso. Os drenadores de carteiras costumam alcançar as vítimas por meio de sites falsos de airdrop, anúncios maliciosos, domínios com typosquatting ou links sociais sequestrados. Todos eles dependem de atrair você para um lugar falso, então o conselho habitual funciona: verifique a URL, use o site oficial, procure o cadeado. Nada disso ajudou aqui. O drenador foi executado no polymarket.com real, em uma sessão em que o usuário já havia conectado sua carteira e tinha todos os motivos para confiar no próximo aviso. A injeção na cadeia de suprimentos transformou o frontend legítimo na página de phishing.

Esse padrão tem um precedente claro e com nome. Em dezembro de 2023, atacantes aplicaram phishing na conta npm de um ex-funcionário da Ledger e publicaram versões maliciosas de @ledgerhq/connect-kit, a biblioteca de código aberto que muitas dApps usam para conectar as carteiras de hardware da Ledger. As versões envenenadas injetaram um drenador de carteiras no frontend de todos os sites que carregavam a biblioteca, incluindo SushiSwap, Zapper e Revoke.cash, e levaram cerca de 600.000 dólares em poucas horas. Uma única dependência de código aberto sequestrada drenou usuários de muitos sites ao mesmo tempo, sem nenhuma URL falsa. A dependência comprometida da Polymarket não foi identificada, mas o esquema é o mesmo.

As próprias palavras da Polymarket carregam o detalhe que mais importa para os defensores: o script foi injetado "para alguns usuários". O payload era condicional. Essa é a mesma propriedade que permite a esses ataques escapar de um scanner que rastreia de um data center, e é por isso que um controle que só verifica a origem de um script não pode ajudar uma vez que a origem é confiável.

Onde este ataque realmente aconteceu

Arquivar isto como "mais um hack cripto" esconde a parte com que toda equipe web deveria se importar. A camada de blockchain se comportou corretamente. Os smart contracts não foram explorados. Não houve bug de reentrancy, nem flash loan, nem manipulação de oráculo. O ataque viveu inteiramente no runtime do navegador, a camada entre o seu servidor e a tela do seu usuário, onde o JavaScript de terceiros é executado com os mesmos privilégios que o seu próprio código.

Essa camada é uma das superfícies menos monitoradas das aplicações web modernas. As equipes repetem a regra "nunca confie no lado do cliente" e depois carregam rotineiramente dezenas de requisições de terceiros nesse lado do cliente: analytics, gerenciadores de tags, widgets de chat, pixels de marketing e SDKs. Cada um deles é uma dependência, e cada dependência é um possível ponto de entrada. O atacante da Polymarket usou uma relação com um fornecedor que já era confiável, porque o fornecedor do outro lado havia sido comprometido.

Já documentamos esse padrão antes. O comprometimento do AppsFlyer Web SDK seguiu o mesmo roteiro: os atacantes sequestraram um SDK de marketing confiável e serviram um payload malicioso a milhares de sites cujos proprietários não faziam ideia de que seus scripts haviam mudado. Também rastreamos extensões de navegador maliciosas que se passavam pelo Microsoft Clarity para sobrescrever tokens de indicação e desviar receita. Payloads diferentes, a mesma causa raiz: código de terceiros confiável que se torna hostil, é executado no navegador e permanece invisível para as defesas tradicionais.

Por que as defesas padrão não detectam essa classe de ataque

Se você está se perguntando por que os controles de segurança comuns não impedem isso, a resposta é estrutural. A maior parte das ferramentas em que as equipes confiam simplesmente não consegue ver este ataque.

• A segurança do lado do servidor e de rede monitora a sua própria infraestrutura. O código malicioso nunca a tocou. O fornecedor foi comprometido a montante, e o payload foi executado no dispositivo do usuário.
• A Content Security Policy (CSP) autoriza quais domínios podem servir scripts, mas valida a origem, não o comportamento. Se um fornecedor confiável e autorizado começa a servir código malicioso, a CSP o deixa passar. Ela não faz ideia se o script está lendo um campo de formulário ou pedindo à carteira uma aprovação de tokens. Para um olhar mais aprofundado, veja por que a CSP sozinha não impede ataques do lado do cliente.
• Os scanners estáticos rastreiam o seu site em busca de scripts maliciosos conhecidos. Atacantes mais sofisticados detectam o scanner e servem a ele uma versão limpa, enquanto entregam o payload real aos usuários reais. O script da Polymarket foi executado "para alguns usuários", que é exatamente esse tipo de entrega condicional, e um scanner é a coisa mais fácil de excluir.

O comportamento que deveria ter se destacado é específico: um script de terceiros que nunca havia tocado o provedor da carteira interagindo de repente com ele e pedindo aos usuários que aprovassem transferências de tokens. Isso é observável no runtime de JavaScript, onde o script de fato é executado. É invisível para um controle que só verifica de onde o script veio.

Um padrão em toda a web

Se você der um passo atrás, a tendência fica clara. A DefiLlama registrou o segundo trimestre de 2026 como o pior trimestre de incidentes de segurança cripto que já documentou, com cerca de 74,9 milhões de dólares perdidos em 29 exploits só em junho. A história que define a segurança web em 2026 não é mais o smart contract com bugs nem o servidor sem patch. É a dependência confiável que dá errado, e o runtime do navegador onde essa falha se desenrola.

Os atacantes estão se diversificando porque os pontos de entrada mais antigos estão cada vez mais difíceis de abrir. À medida que as defesas no nível de protocolo e de servidor amadurecem, o lado do cliente continua sendo o alvo mais brando. Ele é fácil de alcançar e raramente é monitorado em tempo real. O ataque à cadeia de suprimentos do polyfill[.]io, que atingiu centenas de milhares de sites por meio de uma única dependência confiável, é a mesma história em uma escala muito maior.

Como prevenir um ataque à cadeia de suprimentos do lado do cliente

O incidente da Polymarket mostra um padrão repetível. Toda aplicação web que carrega JavaScript de terceiros tem a mesma exposição. Esses quatro controles reduzem o risco em qualquer stack.

Mantenha um inventário de scripts atualizado. Conheça cada dependência que é executada nos navegadores dos seus usuários: quem é o proprietário, a quais dados ela pode acessar e por que está lá. Não se trata de uma auditoria única. Os scripts mudam. Os fornecedores adicionam sub-dependências. Um código revisado e aprovado há um ano pode carregar comportamentos muito diferentes hoje. O PCI DSS 4.0.1 §6.4.3 exige um inventário em tempo real para páginas de pagamento precisamente porque um script desconhecido é um script não monitorado. Comece pelos fluxos de pagamento e pelas páginas de autenticação.

Monitore o que os scripts realmente fazem, não apenas de onde vêm. A CSP valida a origem. Uma vez que um fornecedor confiável é comprometido, a CSP não tem como detectar que a tag de analytics dele agora está solicitando aprovações de carteira. Um domínio confiável não é o mesmo que um comportamento confiável. O monitoramento na camada de runtime do JavaScript, onde os scripts de fato são executados, detecta o que qualquer controle baseado em origem não consegue ver: um script que fazia analytics ontem e hoje está interagindo com o provedor da carteira.

Alerte sobre drift de comportamento antes que uma assinatura seja publicada. A inteligência de ameaças é reativa por definição. Um fornecedor comprometido esta manhã não aparecerá em nenhum feed até que o dano já esteja feito. A detecção que responde ao drift de comportamento, um script que contata novos domínios externos, obtém acesso a novas APIs do navegador ou lê estruturas de dados que antes ignorava, fecha essa janela.

Pratique o processo de remoção antes de precisar dele. A equipe da Polymarket identificou a dependência comprometida, a removeu e se comprometeu a reembolsar os usuários afetados. A maioria das equipes não praticou essa sequência. Saber quais scripts remover e em quanto tempo um build limpo pode ser implantado transforma um comprometimento da cadeia de suprimentos de uma crise de dias em um incidente controlável.

Como a cside detecta essa classe de ataque

A cside foi construída exatamente para a superfície que este ataque usou. Veja como ele apareceria por meio do nosso motor de detecção.

Comportamento, não apenas a origem. Não verificamos só de onde um script vem. Observamos o que ele faz no runtime: manipulação do DOM, event listeners, quais dados acessa e para onde os envia. O script de um fornecedor confiável que de repente recorre ao provedor da carteira, pede uma aprovação de tokens ou contata um domínio recém-registrado é exatamente o tipo de anomalia que trazemos à tona.

Detecção de drift. Os scripts não ficam estáticos. Uma dependência que na semana passada fazia analytics e nesta semana começa a tocar APIs de carteira e um domínio novo dispara um alerta. Nossa IA gera uma explicação em linguagem simples do que mudou e por que importa, para que você não precise de um pesquisador para ler um diff de hashes.

Modo Script. o cside funciona em dois modos, Método Script e Método Scan. No Método Script, observamos o comportamento de cada script na sessão ao vivo do usuário e o analisamos no lado do servidor em nossa própria infraestrutura, e então o bloqueamos no momento em que o comportamento é confirmado como malicioso, sem necessidade de um proxy. Como observamos o que de fato é executado na sessão, o truque de "servir uma versão limpa ao scanner" não ajuda, e capturamos payloads que só disparam para usuários, geografias ou sessões específicas, a mesma segmentação "para alguns usuários" vista aqui.

Bloqueio em tempo real, não apenas relatórios. Os scanners relatam. A CSP bloqueia com dados limitados. A cside pode bloquear um script com base no comportamento observado antes que ele esvazie uma carteira ou roube um cartão. Uma ferramenta que só avisa sobre uma violação depois que ela acontece deixa você reagindo.

A resposta da Polymarket, conter o incidente, remover a dependência e reembolsar integralmente os usuários afetados, é a aparência de uma resposta sólida depois de um ataque. A oportunidade para qualquer outra plataforma é garantir que nunca haja um "depois". A monitoração de integridade do frontend em tempo real ainda não é padrão na web, e incidentes como este são a razão pela qual ela deveria ser.

A Polymarket foi atingida no lado do cliente, onde os ataques são mais fáceis de esconder e mais difíceis de detectar. Se há JavaScript de terceiros sendo executado no seu site, e há, essa superfície está exposta esteja você observando ou não.

Os números e a atribuição acima refletem os primeiros relatos de Specter, PeckShield e Bubblemaps e estão corretos em 2026-06-26.

Quer ver o que está realmente sendo executado nos navegadores dos seus usuários? Comece gratuitamente ou agende uma demo para falar com a nossa equipe.