Polymarket: script RUM di DebugBear manomesso ruba criptovalute

Il 29 ottobre 2026 Polymarket, la piattaforma di mercati predittivi basata su criptovalute, ha sospeso per circa un’ora le contrattazioni sulla sua piattaforma internazionale, Polymarket.com, dopo la compromissione di un fornitore terzo. Secondo BleepingComputer, SecurityWeek e The Record, il fornitore è DebugBear, servizio britannico di monitoraggio delle prestazioni dei siti web: dalla sua infrastruttura è stato servito un JavaScript malevolo che ha usato le sessioni degli utenti collegati per trasferire le loro attività verso portafogli controllati dall’attaccante.

Polymarket ha confermato l’incidente, lo ha segnalato alle forze dell’ordine e si è impegnata a rimborsare tutti gli utenti colpiti. Non ha però indicato il nome del fornitore, il numero delle vittime né l’importo sottratto. Secondo SecurityWeek, la piattaforma statunitense di Polymarket non è stata coinvolta.

La cronologia

Le tre testate concordano sui passaggi principali, ricostruiti dalla pagina di stato e dai messaggi pubblici di Polymarket (orari in UTC):

• 17:50–17:56: secondo l’analisi della blockchain di BleepingComputer, il portafoglio sospetto esegue numerose transazioni sul contratto dei token dei mercati predittivi di Polymarket;
• 17:59: Hudson Rock individua una build di produzione di Polymarket con il messaggio di commit chore(polymarket): remove debugbear rum script (#15337), cioè la rimozione dell’integrazione di DebugBear;
• 18:05: l’exchange passa in modalità «solo cancellazione» e le operazioni del relayer vengono sospese;
• 18:37: Polymarket comunica di aver individuato e corretto il problema, ma ferma le contrattazioni per prudenza;
• 19:05: incidente chiuso e contrattazioni di nuovo attive.

DebugBear ha confermato di essere colpita da un «incidente di sicurezza in corso», ha chiesto ai clienti del prodotto RUM (Real User Monitoring) di togliere il codice di integrazione dai propri siti e, secondo SecurityWeek, ha coinvolto specialisti di risposta agli incidenti.

Come funzionava lo script

I servizi RUM funzionano con uno snippet JavaScript inserito nelle pagine del cliente, che misura le prestazioni nel browser dei visitatori. Proprio per questo lo script gira con gli stessi privilegi del codice del sito. Secondo Hudson Rock e BleepingComputer, la versione malevola era servita da cdn.debugbear[.]com/C7xcKKrjUnXK.js e:

1. verificava se il visitatore era autenticato su Polymarket;
2. leggeva i saldi in criptovaluta e le posizioni sui mercati predittivi per stimarne il valore;
3. a seconda del tipo di autenticazione dell’account, vendeva le posizioni e spostava il ricavato, oppure trasferiva direttamente i token delle posizioni a un indirizzo scelto dall’attaccante;
4. convertiva le criptovalute in attività trasferibili usando le funzioni di transazione della piattaforma stessa.

BleepingComputer, che ha analizzato una copia del file, riferisce che lo script scambiava dati con data.debugbear[.]com per ricevere istruzioni e inviare account presi di mira, indirizzi dei portafogli, saldi ed esiti delle transazioni: la stessa infrastruttura del fornitore faceva quindi da distribuzione e da canale di comando e controllo. Hudson Rock precisa che il codice legge materiale legato alle credenziali, ma di non aver trovato routine che inviino password, seed phrase o chiavi private: l’approccio è riusare l’autorità già presente nell’applicazione autenticata.

Come sia stato manomesso lo script non è ancora noto. Hudson Rock dice di non avere elementi su un attacco più ampio ad altri clienti di DebugBear.

Nella nostra lettura le tecniche MITRE ATT&CK pertinenti sono T1195.002 (Compromise Software Supply Chain), T1185 (Browser Session Hijacking), T1071.001 (Web Protocols), T1041 (Exfiltration Over C2 Channel) e T1657 (Financial Theft).

Le perdite: stime diverse

Le cifre non coincidono e nessuna è ufficiale:

• BleepingComputer ha tracciato circa 28,6 milioni di POL (circa 2,57 milioni di dollari) trasferiti dal portafoglio sospetto ad altri tre portafogli;
• Hudson Rock ha visto circa 2,19 milioni sull’indirizzo di riserva scritto nello script, precisando che non è un conteggio verificato;
• secondo SecurityWeek, GoPlus stima circa 2,71 milioni, con un percorso che passa per 710 portafogli di deposito e 731 indirizzi (che non equivalgono al numero delle vittime), mentre i dati di Arkham indicano circa 2,65 milioni sullo stesso indirizzo;
• The Record parla di oltre 2,1 milioni secondo diverse società di sicurezza della blockchain.

SecurityWeek ricorda anche che a giugno Polymarket aveva già comunicato un’altra compromissione di un fornitore terzo, con uno script malevolo iniettato nel frontend e perdite stimate intorno ai 3 milioni di dollari.

Impatto per le aziende europee e italiane

Il caso va oltre le criptovalute. Qualsiasi script di terzi caricato in una pagina (monitoraggio delle prestazioni, statistiche, tag manager, chat, test A/B) può leggere e fare tutto ciò che può fare l’utente collegato. Nelle aree riservate di banche, e-commerce, portali sanitari e applicazioni SaaS questo significa dati personali, ordini, pagamenti e operazioni dispositive.

Per i soggetti NIS2 i fornitori di questi script rientrano nella sicurezza della catena di fornitura: vanno inventariati e valutati come gli altri fornitori ICT. Uno script compromesso che legge dati nelle pagine autenticate va valutato anche come possibile violazione dei dati personali ai fini del GDPR.

Cosa fare subito

1. Se usi DebugBear RUM, togli il codice di integrazione come indicato dal fornitore e cerca nei log del proxy, del firewall e nei report CSP le richieste verso cdn.debugbear[.]com e data.debugbear[.]com.
2. Fai l’inventario degli script esterni caricati in produzione, partendo dalle pagine autenticate e da quelle che avviano transazioni.
3. Togli dalle pagine sensibili gli script che non servono al loro funzionamento: monitoraggio e statistiche raramente devono girare dove l’utente dispone di denaro o dati.
4. Applica una Content Security Policy con script-src e connect-src limitati ai domini necessari e con la segnalazione delle violazioni attiva.
5. Dove lo script è statico, ospitane una copia versionata o usa la Subresource Integrity; per gli script che cambiano spesso, sorveglia le modifiche del contenuto.
6. Lato server, chiedi una conferma separata per le operazioni ad alto rischio (prelievi, trasferimenti verso nuovi destinatari) e sorveglia raffiche anomale di transazioni dalla stessa sessione: uno script che riusa la sessione non supera un secondo fattore richiesto al momento dell’operazione.
7. Per chi opera con criptovalute, aggiungi alle liste di blocco l’indirizzo segnalato da Hudson Rock: 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18.

Come aiuta ARXDOME

ARX Horizon permette di cercare gli indicatori pubblici di questo incidente nelle fonti di threat intelligence, e gli eventi dei firewall raccolti da ARX Sentry, arricchiti con le liste di minacce, aiutano a capire se postazioni e server dell’azienda hanno contattato i domini usati dallo script.

Ultimo aggiornamento: 30 ottobre 2026