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.
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.
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 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 Gatekeeper. Nosso motor no edge pode se posicionar entre os terceiros não confiáveis e os seus usuários, servindo o script por meio de um conduit que controlamos, para os scripts que você escolher. Mantemos uma cópia do que foi de fato entregue, o que anula o truque de "servir uma versão limpa ao scanner", e ele captura 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.
