Resumo: o ataque por script à Polymarket em outubro
- Outro fornecedor comprometido: Em 2026-10-29, um script de monitoramento de desempenho substituído usou sessões ativas da Polymarket para vender posições e movimentar fundos.
- O precedente de junho: A Polymarket divulgou um ataque semelhante à cadeia de suprimentos do frontend em 2026-06-25. A cside analisou o roubo relatado de aproximadamente US$ 3 milhões.
- Reembolsos: A Polymarket anunciou US$ 3,9 milhões em reembolsos pelo incidente de outubro, incluindo US$ 1,2 milhão por perdas relacionadas à pausa nas negociações.
Sem tempo? Conheça a segurança do lado do cliente da cside para monitoramento de scripts e proteção durante a execução no navegador.
Um script de monitoramento de desempenho virou uma via de acesso aos fundos dos usuários. Quatro meses após o comprometimento de seu frontend em junho, a Polymarket sofreu outro ataque envolvendo scripts de terceiros.
Em 2026-10-29, um script comprometido de um fornecedor usou sessões ativas da Polymarket para vender posições e movimentar fundos das carteiras afetadas. Na atualização de 2026-10-30, a Polymarket informou que o reembolso total seria de US$ 3,9 milhões, incluindo US$ 1,2 milhão por perdas relacionadas à pausa nas negociações. O relatório do incidente da Polymarket descreve a resposta e os reembolsos.
Para equipes que operam aplicações financeiras, o problema recorrente merece atenção: JavaScript de terceiros faz parte do seu perímetro de segurança.
O que aconteceu em 2026-10-29
A Polymarket afirmou que um invasor substituiu o script de monitoramento de desempenho de um fornecedor por código direcionado aos seus usuários. A empresa removeu o script e limpou os caches. Também pausou as negociações e seu relayer, depois redefiniu todas as sessões de login ativas. O relatório posterior descreveu mais controles de integridade, monitoramento, versões fixadas, isolamento e uma Content Security Policy mais restritiva.
Os valores dos reembolsos exigem precisão. Os US$ 3,9 milhões anunciados pela Polymarket incluem compensações além dos fundos roubados. Tratar todo esse valor como dinheiro roubado exageraria o roubo relatado. Fonte
Como o código de monitoramento acessou funções de negociação
A investigação técnica da Hudson Rock identificou JavaScript malicioso servido por uma URL da DebugBear associada à integração de monitoramento de usuários reais da Polymarket.
O código malicioso lia o contexto da conta armazenado no navegador e percorria estruturas internas do React para localizar o cliente de negociação e o assinante da aplicação. Seus diferentes caminhos tentavam transferir tokens de posições ou vender posições e depois transferir os valores obtidos. O código solicitava assinaturas e tentava enviar as operações pelo relayer da Polymarket.
Uma ferramenta de desempenho tentava exercer autoridade financeira dentro da página.
A análise da Hudson Rock não estabeleceu que todas as solicitações de assinatura eram concluídas sem avisar o usuário. As confirmações da carteira, as regras da sessão e a execução das transações continuam determinantes. Os pesquisadores também não identificaram uma rotina que extraísse chaves privadas ou frases de recuperação. A abordagem observada se concentrava em reutilizar a autoridade disponível na aplicação autenticada. Fonte
A Polymarket sofreu um ataque semelhante em junho
Nós analisamos o ataque anterior à cadeia de suprimentos do lado do cliente da Polymarket após sua divulgação em 2026-06-25. Naquele incidente, um fornecedor externo comprometido injetou código malicioso no frontend, com um roubo relatado de aproximadamente US$ 3 milhões.
Nossa análise de junho descreveu um fluxo de phishing de aprovações pela interface legítima da Polymarket. A investigação de outubro descreve código malicioso que procura o cliente de negociação e o assinante dentro de uma sessão existente.
| Incidente | Mecanismo relatado | Impacto financeiro relatado |
|---|---|---|
| 2026-06-25 | Fornecedor comprometido injeta código no frontend associado a solicitações maliciosas de aprovação ou assinatura | Aproximadamente US$ 3 milhões roubados, segundo nossa análise anterior |
| 2026-10-29 | Script de monitoramento substituído abusa de sessões ativas; pesquisadores identificam lógica de negociação e assinatura | Polymarket anuncia US$ 3,9 milhões em reembolsos, incluindo compensações relacionadas à pausa |
O padrão comum é o acesso de scripts de terceiros a um fluxo financeiro sensível. Essa semelhança não estabelece que se trate do mesmo invasor, fornecedor ou método de comprometimento inicial.
O que as equipes de aplicações devem mudar
A pergunta prática em uma revisão de segurança é se uma integração de monitoramento pode acessar recursos que vão muito além de sua função prevista.
Comece reduzindo a execução de scripts de terceiros em páginas autenticadas de negociação e assinatura. Exija uma justificativa comercial clara para cada integração, um responsável e um procedimento de remoção. Revise o limite de acesso à assinatura e decida quais ações exigem uma nova confirmação explícita.
Para dependências que podem ser fixadas, use Subresource Integrity. O SRI permite que o navegador compare um arquivo obtido com um hash criptográfico esperado e o rejeite se houver diferença. Implementações entre origens exigem suporte adequado a CORS e um processo controlado para atualizações aprovadas.
Preserve também o conteúdo dos scripts entregues aos usuários. Uma investigação precisa de provas do que foi executado, de quando mudou e de quais sessões poderiam tê-lo recebido.
O que a cside oferece
A cside fornece visibilidade da execução no navegador, um inventário de scripts, um histórico de seu conteúdo e detecção de comportamento malicioso. Esses recursos ajudam as equipes a investigar alterações no código executado nas sessões dos clientes. Conheça a segurança do lado do cliente da cside.
Os incidentes de junho e outubro tornam a prioridade concreta: revisar o código autorizado a executar junto aos fluxos mais sensíveis, limitar sua autoridade e verificar continuamente o que chega aos usuários.
