O Polymarket retomou as negociações em 29 de outubro após um provedor de terceiros comprometido interromper o mercado de previsões internacional. O incidente marcou a segunda violação de segurança de milhões de dólares do Polymarket em quatro meses. O registro oficial de incidentes do Polymarket indica que as restrições às negociações começaram às 18:05 UTC e foram resolvidas às 19:05 UTC. O Polymarket afirmou que o problema foi corrigido e que as autoridades policiais foram notificadas. O Polymarket também prometeu compensação total aos usuários afetados.
A empresa de análise de blockchain Bubblemaps estimou que o ataque de 29 de outubro afetou mais de 700 usuários do Polymarket e comprometeu aproximadamente US$ 3,46 milhões em ativos. Os atacantes trocaram cerca de US$ 2,7 milhões por POL e retiraram os fundos. Outros US$ 750 mil permaneceram no Polymarket quando a avaliação foi feita.
A Polymarket divulgou em 25 de junho que um fornecedor comprometido havia ativado a injeção de um script malicioso. A Polymarket afirmou que a dependência afetada havia sido removida e prometeu reembolsos completos. A Source Defense relatou perdas de aproximadamente US$ 3 milhões decorrentes do ataque de junho. A Source Defense rastreou a entrega até uma tag de marketing que buscava uma biblioteca externa de identidade, que o atacante substituiu por um drainer personalizado para a Polymarket. Pesquisadores da Source Defense disseram que a carga útil de junho visava carteiras com mais de US$ 100.000 e buscou repetidamente autorização digital. Uma autorização aprovada passava pelo relayer da Polymarket, que envia ações assinadas.
A análise de outubro da Hudson Rock descreveu código obtido de uma URL associada à DebugBear que buscava o cliente de negociação ativo e o assinante dentro de uma sessão logada. O assinante é o componente que solicita autorização criptográfica. A Hudson Rock descobriu que o comportamento programado do script variava conforme o tipo de conta. Um ramo solicitava transferências de tokens de posição; outro solicitava vendas seguidas por transferências dos proventos. A Hudson Rock também identificou metadados da versão de produção documentando a remoção do script de monitoramento da DebugBear. No entanto, a análise estática da Hudson Rock não comprovou que o código foi executado, obteve assinaturas silenciosamente ou roubou chaves privadas. A análise também não estabeleceu uma trilha completa desde as vítimas até os destinatários. Os metadados de remoção não estabelecem com precisão quando terminou a exposição dos usuários.
A dependência de marketing de junho e o script associado ao monitoramento de outubro forneceram rotas diferentes para uma interface financeiramente sensível. O mecanismo de junho supostamente dependia de autorizações aprovadas, enquanto o código de outubro buscava ferramentas de negociação e solicitava assinaturas. Substituir apenas um fornecedor comprometido não resolve o problema mais amplo de código malicioso acessar funções financeiras dentro do site. As violações repetidas levantam questões sobre a autoridade financeira que código externo pode acessar por meio do navegador de um trader.
A documentação do navegador da MDN afirma que um script de terceiros carregado diretamente em uma página pode acessar outros scripts e dados dessa página. A MDN explica que hospedar o script em outro local não remove esse acesso, enquanto conteúdo de origem cruzada em um frame separado possui um limite de segurança diferente. Reduzir código externo, limitar solicitações de assinatura e verificar arquivos baixados abordam diferentes estágios da cadeia de ataque. Remover integrações desnecessárias das páginas de negociação e assinatura reduz o código externo permitido nesses ambientes. Revisar o acesso ao assinador e identificar ações que exigem confirmação fresca do usuário restringe as solicitações que o código pode fazer após obter acesso.
A Integridade de Subrecursos permite que os navegadores verifiquem scripts baixados em relação a uma impressão digital criptográfica esperada e rejeitem arquivos alterados. A Integridade de Subrecursos também pode proteger um recurso adequadamente fixado hospedado em um domínio confiável. Um pós-mortem detalhado abordando o período de exposição, as contas afetadas e as rotas de autorização ajudaria a avaliar o risco remanescente. Se outra integração comprometida poderia converter o acesso à interface de negociação em autorização financeira utilizável permanece não resolvido.