Polymarket sofre ataque de supply chain via fornecedor terceirizado e perde US$ 3 milhões em pUSD; usuários afetados serão reembolsados
Plataforma de mercados de previsão descentralizada confirmou injeção de script malicioso no frontend por meio de dependência comprometida; atacante moveu pUSD da Polygon para Ethereum e converteu em cerca de 1.893 ETH, segundo a PeckShield.
A Polymarket, principal mercado de previsão descentralizado em criptomoeda, confirmou que um fornecedor terceirizado foi comprometido e injetou um script malicioso no frontend de parte dos usuários, resultando em um roubo estimado em US$ 3 milhões em pUSD — a moeda de negociação interna da plataforma, lastreada em USDC. A empresa diz ter contido o incidente, removido a dependência afetada e promete reembolso integral aos atingidos, em mais um capítulo na crescente onda de ataques de cadeia de suprimentos contra Web3.
O que aconteceu
Em nota publicada na quinta-feira no X (antigo Twitter), a Polymarket informou ter descoberto na manhã do mesmo dia que “um fornecedor terceirizado havia sido comprometido, injetando um script malicioso no frontend para alguns usuários”. A empresa diz que conteve o incidente, removeu a dependência afetada e está em contato com os atingidos para reembolso integral. Não foram divulgados oficialmente o número de vítimas nem o montante exato roubado.
A estimativa de US$ 3 milhões vem da empresa de segurança em blockchain PeckShield, que rastreou as transações on-chain. Segundo a análise, o atacante converteu pUSD roubado em USDC, fez a ponte (bridge) do valor entre a rede Polygon e a Ethereum e finalmente trocou os fundos por aproximadamente 1.893 ETH. Um analista independente confirmou que ao menos 11 vítimas foram impactadas até o momento. A autoria do ataque permanece desconhecida.
Como o ataque funciona
O vetor é o mesmo que vem assombrando plataformas DeFi nos últimos dois anos: comprometimento de uma dependência JavaScript carregada no navegador do usuário. Quando o frontend da exchange ou do dApp puxa um script — seja de um CDN, de um analytics, de uma biblioteca de UI ou de um SDK terceiro — qualquer alteração maliciosa nesse pacote é entregue diretamente ao browser da vítima, com origem de confiança igual à do site oficial.
Em casos como este, o script injetado costuma interceptar transações antes da assinatura, trocar endereços de destino dentro do wallet popup ou, em variantes mais agressivas, solicitar aprovações ilimitadas (“infinite approval”) em contratos ERC-20 para drenar o saldo do usuário a qualquer momento. A criptografia da blockchain não é tocada; o que é manipulado é a camada de interface, onde o usuário decide o que assinar.
“Nesta manhã descobrimos que um fornecedor terceirizado havia sido comprometido, injetando um script malicioso em nosso frontend para alguns usuários. Contivemos o incidente e removemos a dependência afetada.”
Polymarket, em comunicado oficial
Riscos e limitações
- Promessa de reembolso, mas sem detalhes: a Polymarket diz que reembolsará todos os afetados, mas não publicou cronograma, mecanismo ou critério de elegibilidade. Em incidentes semelhantes no passado, fundos foram cobertos integralmente — em outros, ressarcimentos parciais ou condicionados foram a regra.
- Janela de exposição desconhecida: não foi divulgado por quanto tempo o script malicioso permaneceu ativo, o que dificulta o levantamento total de vítimas. Usuários que não notaram movimentações estranhas devem verificar histórico recente.
- Vendor não identificado: sem o nome do fornecedor comprometido, outras plataformas que usem a mesma dependência não conseguem se proteger preventivamente. É padrão que essa informação seja revelada com atraso, por razões legais e contratuais.
- Risco residual em wallets conectadas: aprovações de contratos concedidas durante a janela do ataque podem permanecer ativas. Usuários precisam revogar permissões via ferramentas como Revoke.cash ou Etherscan Token Approval Checker.
Análise
O ataque à Polymarket repete um padrão que já é o vetor número um de comprometimento em DeFi: cadeia de suprimentos no frontend. Em 2022, o Curve.fi sofreu um sequestro de DNS via Iwantmyname; em 2024, a BadgerDAO foi vítima de um Cloudflare Worker malicioso; o caso Ledger Connect Kit em dezembro de 2023 contaminou centenas de dApps de uma só vez. O vetor é eficiente porque os smart contracts em blockchain são, na grande maioria, auditados, enquanto a camada web tradicional — com seu emaranhado de bibliotecas npm, scripts de analytics e SDKs de carteira — segue sendo o elo frágil pelo qual o adversário consegue atingir o usuário final.
Há também a dimensão geopolítica. A Polymarket vive um momento de alta visibilidade após sua integração com o X em 2025 e o uso intenso da plataforma para precificar eleições, decisões da Justiça norte-americana e até resultados de processos contra figuras públicas. Cada notícia de roubo via frontend reforça a tese regulatória — sobretudo da CFTC e de reguladores europeus — de que mercados de previsão precisam de controles operacionais mais rígidos. Para o setor cripto como um todo, US$ 3 milhões é um valor relativamente baixo, mas o tipo de ataque pesa mais que o dígito: confirma que mesmo plataformas com infraestrutura on-chain robusta dependem de uma camada web tão vulnerável quanto qualquer e-commerce tradicional.
Para usuários brasileiros, vale o alerta: a CVM publicou em 2025 a Resolução 175, que regula a oferta de tokens, mas mercados de previsão como a Polymarket operam em zona cinzenta, sem cobertura local em caso de prejuízo. Diferente de uma corretora de cripto regulada, a janela para reaver fundos depende exclusivamente da boa-fé do operador.
Recomendações práticas
- Revogar imediatamente aprovações ERC-20 concedidas a contratos da Polymarket nos últimos sete dias, usando ferramentas como Revoke.cash; em caso de dúvida, mover saldos para uma carteira nova.
- Habilitar, sempre que possível, hardware wallets (Ledger, Trezor) com tela própria — elas exibem o endereço real de destino, frustrando a maioria dos ataques de “address swap” no frontend.
- Em uso institucional, exigir Subresource Integrity (SRI) e CSP estrito em dApps próprios, com whitelisting explícito de cada dependência externa; auditar periodicamente o package-lock.json.
- Para operadores Web3, considerar arquitetura de “frontend congelado” — builds reproducíveis, assinados e publicados em IPFS — reduzindo o vetor de injeção do servidor de hospedagem.
- Equipes de SOC monitorando endereços corporativos devem incluir alertas para transações inesperadas em Polygon (rede onde a Polymarket opera) e bridges suspeitos para Ethereum.
- Acompanhar canais oficiais da Polymarket para detalhes sobre o reembolso e divulgar internamente para que vítimas em equipes não fiquem desinformadas.
Fonte: SecurityWeek





