O ataque à cadeia de suprimentos que atingiu a Polymarket em 29 de outubro de 2026 demonstrou como um componente aparentemente inofensivo de monitoramento pode se transformar em uma porta de entrada para fraudes financeiras. Em menos de uma hora, um script JavaScript comprometido, fornecido pela plataforma de monitoramento DebugBear, foi utilizado para desviar aproximadamente US$ 2,7 milhões (cerca de R$ 14,7 mi) em ativos de usuários da plataforma de previsões.
O incidente chama a atenção porque não começou com uma invasão convencional aos servidores da Polymarket, nem com uma vulnerabilidade identificada em seus contratos inteligentes. O problema surgiu na cadeia de fornecedores: um código externo, carregado automaticamente pelo navegador, passou a executar instruções maliciosas dentro de uma aplicação que já possuía sessões autenticadas e mecanismos legítimos para movimentar os ativos dos clientes.
Neste artigo, vamos examinar como o comprometimento do serviço da DebugBear permitiu a distribuição do código adulterado, como os invasores aproveitaram as permissões existentes no ambiente da Polymarket e quais medidas podem impedir que situações semelhantes atinjam outras aplicações. O caso também oferece lições importantes sobre Subresource Integrity (SRI), Content Security Policy (CSP) e isolamento de dependências externas.
Como o ataque à cadeia de suprimentos comprometeu o script da DebugBear
A DebugBear oferece ferramentas de monitoramento de desempenho de páginas web, incluindo o recurso Real User Monitoring (RUM). Essa tecnologia coleta informações sobre a experiência real dos visitantes, permitindo que desenvolvedores acompanhem métricas como velocidade de carregamento, estabilidade visual e desempenho de recursos.
Para utilizar o serviço, os clientes incorporam um pequeno script JavaScript em suas aplicações. O navegador dos visitantes baixa e executa esse arquivo automaticamente, permitindo que a ferramenta colete os dados necessários.
Na implementação da Polymarket, o arquivo era hospedado no domínio cdn.debugbear.com. O problema foi que o código disponibilizado nesse endereço deixou de corresponder à versão legítima do componente de monitoramento.
Em 29 de outubro, pesquisadores identificaram que o endereço passou a entregar um arquivo malicioso, desenvolvido especificamente para reconhecer a aplicação da Polymarket e explorar suas funcionalidades de negociação.
Esse tipo de comprometimento é particularmente perigoso porque o navegador não diferencia automaticamente um código legítimo de outro malicioso quando ambos são entregues pelo mesmo endereço autorizado. Se a aplicação confia no fornecedor e executa seu JavaScript, uma alteração no conteúdo distribuído pode comprometer todos os visitantes que carregarem o recurso.
Análise forense da Hudson Rock e da Ohey
A investigação ganhou força com o trabalho dos pesquisadores da Hudson Rock e da equipe de análise da Ohey, que examinaram o arquivo adulterado e compararam seu comportamento com versões anteriores do script.
A análise histórica revelou uma diferença importante. A versão legítima do componente tinha aproximadamente 60 KB e era distribuída a partir de uma infraestrutura associada ao Google Cloud Storage. Já o arquivo malicioso tinha aproximadamente 15 KB e apresentava características de uma infraestrutura diferente, incluindo cabeçalhos HTTP associados a um servidor Nginx.
Os pesquisadores também identificaram divergências nas respostas dos servidores responsáveis pelos domínios da DebugBear. Os registros técnicos apontavam que o endereço de distribuição havia passado a responder por uma infraestrutura diferente daquela utilizada anteriormente.
As evidências indicaram um comprometimento da infraestrutura de DNS e da distribuição do domínio, permitindo que o endereço legítimo fosse associado a um servidor controlado pelos invasores. Relatos sobre o incidente também apontaram comprometimento dos registros DNS por meio do registrador de domínio.
É importante distinguir o que foi efetivamente observado daquilo que ainda depende da investigação: a substituição do arquivo e a mudança na infraestrutura de resposta foram documentadas, mas a cadeia completa de acesso inicial dos invasores não foi esclarecida publicamente.
Outro detalhe relevante é que o código adulterado apresentava características direcionadas à Polymarket. Isso indica uma operação preparada para explorar a estrutura específica da plataforma, em vez de simplesmente distribuir um malware genérico para todos os clientes da DebugBear.
Como o script malicioso drenou contas e carteiras
O aspecto mais preocupante do incidente foi a capacidade do código de aproveitar recursos que já estavam disponíveis no navegador das vítimas.
Segundo a análise técnica da Ohey, o script identificava informações armazenadas localmente, verificava a existência de sessões autenticadas e procurava componentes internos utilizados pela Polymarket para realizar operações financeiras.
Entre os elementos explorados estavam:
- Chaves de API e dados de sessão: o código examinava informações armazenadas no ambiente do navegador para identificar recursos associados à conta autenticada.
- Cliente de negociação: o script localizava funcionalidades legítimas da própria aplicação que permitiam consultar posições e executar operações.
- Mecanismos de assinatura: o malware aproveitava o assinador já conectado à conta para autorizar operações utilizando as permissões disponíveis.
- Relayer da Polymarket: as solicitações eram encaminhadas pela infraestrutura legítima da plataforma, dificultando a identificação imediata de uma operação maliciosa apenas pela origem da comunicação.
O funcionamento variava conforme a modalidade de conta e a estrutura dos ativos. Em determinadas situações, o código tentava vender posições dos usuários, transferindo posteriormente os valores obtidos. Em outras, movimentava diretamente os tokens de posições para carteiras controladas pelos invasores.
Um detalhe merece atenção: não há evidência de que o ataque tenha exigido a descoberta das frases-semente ou a extração direta das chaves privadas das vítimas. O problema foi o abuso de uma aplicação autenticada que já possuía acesso a mecanismos de assinatura e negociação.
Essa diferença é fundamental. Uma aplicação web comprometida pode representar uma ameaça mesmo quando as chaves privadas permanecem protegidas, caso consiga utilizar um assinador conectado para solicitar operações que o usuário não pretendia realizar.
Resposta a incidentes e o impacto financeiro da invasão
A Polymarket precisou agir rapidamente para interromper a movimentação indevida de ativos. A plataforma identificou atividades suspeitas em carteiras de usuários e iniciou procedimentos de contenção ainda durante o ataque, em 29 de outubro.
Uma das medidas foi colocar a exchange internacional em modo de cancelamento (cancel-only), restringindo a criação de novas operações enquanto as equipes investigavam o problema. A plataforma também interrompeu temporariamente as ações do seu relayer, reduzindo a possibilidade de novas transferências não autorizadas.
Paralelamente, a empresa removeu o script comprometido, limpou os caches de distribuição e encerrou as sessões de autenticação que poderiam continuar expostas. A negociação permaneceu temporariamente suspensa até que a aplicação estivesse novamente em condições seguras de funcionamento.
A Polymarket também encaminhou o caso às autoridades responsáveis pela investigação criminal no Reino Unido. A localização da DebugBear e a natureza do comprometimento da infraestrutura de terceiros tornaram a dimensão internacional do incidente especialmente relevante.
Os números dos reembolsos e a compensação aos usuários
As estimativas divulgadas por pesquisadores e empresas de análise de blockchain apontaram para aproximadamente US$ 2,7 milhões em prejuízos, envolvendo centenas de carteiras.
A Polymarket estabeleceu um programa de restituição para os usuários afetados. Até 30 de outubro, informações divulgadas sobre o processo indicavam que 689 das 726 carteiras identificadas já haviam recebido reembolso integral, enquanto as demais permaneciam em processo de verificação e pagamento.
A compensação não ficou restrita aos valores diretamente desviados pelos invasores. A plataforma também destinou aproximadamente US$ 1,19 milhão para usuários prejudicados pela interrupção das negociações e pelo fechamento forçado de determinadas posições.
Com isso, o pacote de restituições chegou a aproximadamente US$ 3,9 milhões.
A iniciativa demonstra a dimensão operacional de um ataque à cadeia de suprimentos: além do prejuízo financeiro provocado diretamente pelo código malicioso, a empresa precisa absorver os custos da interrupção dos serviços, da investigação, da recuperação e da manutenção da confiança dos usuários.
Lições práticas de segurança: como proteger aplicações contra ataques à cadeia de suprimentos
O incidente da Polymarket reforça uma questão frequentemente negligenciada no desenvolvimento frontend: todo JavaScript executado dentro de uma página possui potencial para acessar recursos disponíveis naquele contexto de execução.
Um script de monitoramento pode parecer inofensivo, mas, dependendo da arquitetura da aplicação, ele pode acessar elementos do DOM, consultar dados disponíveis no navegador e interagir com funcionalidades internas.
Isso significa que a segurança de uma aplicação não depende apenas da qualidade do código desenvolvido internamente. Também depende da integridade de cada biblioteca, SDK, ferramenta de análise e serviço externo incorporado ao site.
Para aplicações financeiras, plataformas Web3, sistemas administrativos e páginas de autenticação, essa dependência merece atenção especial.
Ferramentas de telemetria não deveriam receber automaticamente os mesmos privilégios de componentes responsáveis por operações financeiras. Sempre que possível, o monitoramento deve ser executado em um contexto separado, sem acesso direto às funcionalidades de negociação, autenticação e assinatura de transações.
Subresource Integrity (SRI) e Content Security Policy (CSP)
Duas tecnologias fundamentais para reduzir os riscos de comprometimento de scripts externos são Subresource Integrity (SRI) e Content Security Policy (CSP).
Embora sejam frequentemente utilizadas em conjunto, elas resolvem problemas diferentes.
Subresource Integrity (SRI) permite que o navegador verifique se o conteúdo de um arquivo externo corresponde a uma assinatura criptográfica previamente definida pelo desenvolvedor.
Na prática, a aplicação declara um hash associado ao conteúdo esperado do script. Quando o navegador baixa o arquivo, calcula seu próprio hash e compara o resultado com o valor informado.
Se o conteúdo tiver sido modificado, a verificação falha e o navegador bloqueia a execução daquele recurso.
Um exemplo de implementação é:
<script
src="https://cdn.exemplo.com/biblioteca.js"
integrity="sha384-HASH_CRIPTOGRAFICO_DO_ARQUIVO"
crossorigin="anonymous">
</script>O valor apresentado é ilustrativo e deve ser substituído pelo hash SHA-384 real do arquivo utilizado.
Essa proteção teria uma importância direta no caso da Polymarket: mesmo que os invasores conseguissem alterar o arquivo hospedado pela DebugBear, o navegador rejeitaria a versão adulterada caso seu conteúdo não correspondesse ao hash previamente aprovado.
Entretanto, existe uma limitação importante: o SRI funciona melhor com arquivos estáticos e versões controladas. Se o fornecedor modificar legitimamente o conteúdo do script, o hash precisará ser atualizado após uma nova validação.
Já a Content Security Policy (CSP) estabelece quais origens e tipos de recursos podem ser carregados e executados pela aplicação.
Uma política pode restringir a execução de scripts a domínios autorizados, utilizar hashes ou nonces criptográficos e bloquear práticas perigosas, como a execução de código inline não autorizado.
Um exemplo simplificado de cabeçalho é:
Content-Security-Policy:
default-src 'self';
script-src 'self' 'nonce-VALOR_ALEATORIO';
object-src 'none';
base-uri 'self';
frame-ancestors 'none';O exemplo precisa ser adaptado à arquitetura da aplicação, incluindo os recursos externos realmente necessários.
Um erro comum é acreditar que permitir um domínio confiável em script-src garante a integridade de todos os arquivos distribuídos por ele. Isso não é verdade.
Se um domínio autorizado for comprometido, a CSP baseada exclusivamente na origem poderá continuar permitindo a execução do código adulterado. Por isso, CSP e SRI devem ser tratados como camadas complementares, e não como substitutos um do outro.
Boas práticas para desenvolvedores e usuários
Além das proteções criptográficas, o episódio deixa recomendações práticas para equipes responsáveis por aplicações web.
Para desenvolvedores e administradores de sistemas:
- Separe scripts de monitoramento: ferramentas de telemetria não devem compartilhar indiscriminadamente o contexto de execução de páginas financeiras e operações de autenticação.
- Utilize versões estáticas: evite carregar automaticamente arquivos que podem mudar sem controle ou validação prévia.
- Implemente SRI: utilize hashes criptográficos para recursos externos compatíveis com essa proteção.
- Adote CSP restritiva: limite origens, utilize nonces ou hashes e monitore tentativas de violação da política.
- Reduza privilégios: mantenha scripts de terceiros longe de funções responsáveis por assinaturas, transferências e gerenciamento de sessões.
- Monitore alterações: estabeleça alertas para mudanças inesperadas em arquivos JavaScript, registros DNS e infraestrutura de distribuição.
- Prepare respostas a incidentes: tenha procedimentos para remover dependências comprometidas, invalidar sessões, revogar credenciais e interromper operações suspeitas.
O isolamento também merece atenção. Uma alternativa é executar ferramentas de monitoramento em um iframe com atributo sandbox, utilizando permissões estritamente necessárias e evitando conceder acesso ao documento principal.
Essa estratégia não é aplicável a qualquer ferramenta de RUM sem adaptações, mas ajuda a reduzir o impacto de um eventual comprometimento.
Para os usuários de plataformas Web3, a recomendação é igualmente importante: nunca aprove solicitações de assinatura que não correspondam a uma operação iniciada conscientemente.
Antes de confirmar uma transação, verifique o destinatário, os valores, os ativos envolvidos e as permissões solicitadas. Autorizações para movimentação de tokens e assinaturas de mensagens podem produzir consequências financeiras mesmo quando não envolvem a exposição direta da frase-semente.
Também é recomendável revisar periodicamente as permissões concedidas a aplicações descentralizadas e revogar autorizações que não sejam mais necessárias.
O equilíbrio entre telemetria e segurança na web moderna
O ataque à cadeia de suprimentos contra a Polymarket mostra que a confiança em fornecedores externos precisa ser acompanhada de controles técnicos verificáveis.
Ferramentas de monitoramento, bibliotecas JavaScript, sistemas de publicidade e plataformas de análise são importantes para o funcionamento da web moderna. Entretanto, cada dependência adicionada ao frontend amplia a superfície de ataque e pode introduzir riscos que não estão sob controle direto da equipe responsável pelo site.
O problema não está necessariamente em utilizar serviços de terceiros, mas em permitir que esses serviços executem código privilegiado sem mecanismos adequados de validação, isolamento e monitoramento.
O caso da DebugBear também demonstra que uma infraestrutura aparentemente confiável pode ser utilizada como canal de distribuição de malware. Certificados HTTPS, domínios conhecidos e reputação comercial não garantem que o conteúdo entregue permaneça íntegro.
Para desenvolvedores, equipes de DevSecOps e administradores de sistemas, a principal lição é incorporar a segurança da cadeia de suprimentos ao ciclo de desenvolvimento. Isso envolve inventário de dependências, validação de integridade, políticas CSP, isolamento de componentes e procedimentos de resposta rápida.
A telemetria não pode ter prioridade sobre a segurança dos usuários. Uma ferramenta criada para melhorar a experiência de navegação jamais deveria se transformar em um mecanismo capaz de comprometer contas autenticadas e movimentar ativos financeiros.
