Polymarket e lo script di un fornitore: cosa insegna a chi assume il rischio cyber

Il 29 ottobre 2026 uno script di monitoraggio di un fornitore, caricato su Polymarket, è stato sostituito e ha sottratto circa 2,7 milioni di dollari da oltre 700 conti. L'analisi: quale polizza risponde, il cumulo sugli script di terzi, i controlli e le domande per i rinnovi.

Tema della settimana dal 24 al 31 ottobre 2026 · di cybercoverinsurance

Il 29 ottobre 2026, per circa un'ora, il sito di Polymarket ha caricato nelle sessioni dei propri utenti uno script di un fornitore che non era più quello originale. Lo script serviva a misurare le prestazioni delle pagine. Il codice sostituito ha usato il client di trading del sito per spostare fondi da centinaia di conti verso un unico portafoglio. Le stime indipendenti parlano di circa 2,7 milioni di dollari.

La cifra è piccola rispetto ad altri eventi della stessa settimana. Il caso conta per un altro motivo. Il punto di ingresso non era un sistema dell'assicurato né un fornitore critico, ma uno strumento di monitoraggio che quasi nessun questionario di assunzione elenca. Per chi assume il rischio cyber, la domanda è quanti fornitori eseguono codice dentro le pagine più sensibili dei propri assicurati, e chi li controlla.

Cosa si sa

L'incidente. Polymarket ha comunicato che un fornitore terzo «è stato compromesso», che il caso è stato segnalato alle forze dell'ordine e che gli utenti colpiti saranno rimborsati. Polymarket non ha indicato il nome del fornitore né l'importo sottratto (The Record). La società di threat intelligence Hudson Rock ha identificato il fornitore in DebugBear, società britannica di monitoraggio delle prestazioni web, il cui script di real user monitoring era incorporato su polymarket.com. DebugBear ha confermato di essere coinvolta in un «incidente di sicurezza in corso» e ha chiesto ai clienti di rimuovere il suo codice dai siti (ICOBench).

La sequenza. Secondo la ricostruzione di Ohey, lo script malevolo è stato servito nelle sessioni autenticate da circa le 16:54 UTC del 29 ottobre. I primi fondi sono arrivati al portafoglio di destinazione alle 17:10 UTC. Polymarket ha pubblicato una versione del sito senza lo script alle 17:59 UTC. DebugBear ha annunciato l'incidente alle 18:00 UTC (Ohey). Polymarket ha messo la piattaforma in modalità di sola cancellazione degli ordini alle 18:05 UTC e ha riaperto il trading alle 19:00 UTC (ICOBench). La piattaforma colpita è quella internazionale (The Record).

Come funzionava il codice. Hudson Rock ha analizzato lo script. Il codice leggeva dal browser i dati dell'account, individuava il client di trading già caricato nella pagina, controllava i saldi e, sopra una soglia minima, trasferiva le posizioni o le vendeva per poi trasferire il ricavato. Le firme venivano chieste attraverso il sistema di firma già attivo nella sessione e inviate al servizio di inoltro di Polymarket. Gli autori non hanno trovato routine che esportassero chiavi private o frasi di recupero (Hudson Rock). Ohey osserva che tutti gli indirizzi contattati dallo script, tranne quelli di DebugBear, erano già autorizzati dalla Content Security Policy di Polymarket.

Le cifre. Sono stime di terzi, non dati della società. Bitquery indica circa 2,73 milioni di dollari da 737 conti tra le 17:10 e le 18:10 UTC. GoPlus indica circa 2,71 milioni da 731 indirizzi. La perdita mediana per vittima è di 171 dollari (ICOBench). Polymarket non ha pubblicato un totale.

Cosa non è noto. Non è stato chiarito come gli attaccanti abbiano raggiunto l'infrastruttura di distribuzione di DebugBear (Safestate). Non è noto quanti altri siti caricassero lo stesso script. Hudson Rock non ha trovato prove di una compromissione più ampia che abbia colpito altri clienti di DebugBear (The Record). Nessuno ha attribuito l'attacco.

Il fornitore che nessuno elenca

Uno script di monitoraggio ha gli stessi poteri del codice del sito. Un browser non distingue tra il codice scritto dall'assicurato e quello caricato da un fornitore. Una volta nella pagina, lo script di terzi legge ciò che legge il sito e può chiedere ciò che il sito può chiedere. Nel caso Polymarket non è servito rubare credenziali: lo script ha usato la sessione già aperta dall'utente.

I questionari guardano altrove. Le domande sulla supply chain si concentrano di solito su fornitori IT, cloud e software gestito. Strumenti di analisi, tag manager, chat, widget di recensione e monitoraggio delle prestazioni restano fuori, perché sono considerati marketing o strumenti accessori. È proprio la categoria con meno controlli e più accesso alle pagine di login, pagamento e conferma.

Esiste già uno standard da cui prendere le domande. Il PCI DSS 4.0 chiede, per le pagine di pagamento con carta, un inventario di tutti gli script con la giustificazione di ciascuno, un metodo per autorizzarli e uno per verificarne l'integrità (requisito 6.4.3). Chiede anche un meccanismo che segnali modifiche non autorizzate alla pagina come la riceve il browser, almeno ogni sette giorni (requisito 11.6.1). Entrambi sono obbligatori dal 31 marzo 2025 (PageCrawl). Polymarket non tratta carte, ma la logica vale per qualsiasi pagina in cui un utente autorizza un trasferimento di valore.

Quale polizza risponde

Il danno è dei clienti, il rimborso è una scelta dell'assicurato. I fondi sottratti erano degli utenti. Polymarket ha promesso di rimborsarli. Per chi assume il rischio, la distinzione conta. Le polizze cyber coprono di norma la responsabilità verso terzi accertata o le richieste di risarcimento, non i pagamenti volontari fatti prima di una richiesta e senza il consenso dell'assicuratore. Un rimborso spontaneo, anche se sensato per la reputazione, può restare a carico dell'assicurato se la polizza non prevede una garanzia specifica.

La garanzia crime dipende da chi custodiva i fondi. Le garanzie di frode informatica nelle polizze crime presuppongono di solito una perdita di denaro o beni dell'assicurato, o detenuti per conto di terzi. Qui i fondi stavano in portafogli degli utenti, con le firme chieste nella loro sessione. Molte polizze crime, inoltre, escludono le criptovalute o le coprono solo con estensioni dedicate. Il perito dovrà capire se Polymarket deteneva quei fondi, e in quale forma.

Il fornitore ha una responsabilità, il contratto la limita. DebugBear può essere chiamata a rispondere verso i clienti. La copertura di riferimento è la responsabilità professionale tecnologica (tech E&O) del fornitore, se esiste. Ma i contratti dei servizi SaaS di questo tipo prevedono spesso tetti di responsabilità pari ai canoni annui. Il recupero in surroga dell'assicuratore di Polymarket rischia di valere poco.

L'interruzione è stata breve. Il trading è rimasto sospeso circa un'ora. Le franchigie temporali delle garanzie di business interruption sono in genere di diverse ore. In questo caso il costo vero sta nella risposta all'incidente, nell'analisi forense, nelle comunicazioni agli utenti e nei rimborsi, non nel fermo.

Cumulo: uno script, molti siti

Lo stesso file può arrivare su migliaia di pagine. Uno script distribuito da una rete di contenuti di un fornitore viene caricato da tutti i siti che lo incorporano. Nel caso DebugBear i ricercatori non hanno trovato il codice malevolo presso altri clienti, e il codice era scritto per Polymarket. Ma la stessa posizione, con un codice generico, avrebbe potuto colpire ogni cliente del fornitore nello stesso momento.

È uno scenario di danno da mappare. Per un portafoglio, la domanda non è solo quali fornitori cloud condividono gli assicurati. È anche quali script di terzi compaiono sulle pagine di login e di pagamento di molti assicurati insieme. Tag manager, strumenti di analisi e piattaforme di consenso sono comuni a moltissimi siti. Un evento su uno di questi fornitori produrrebbe sinistri correlati di frode, violazione di dati personali e responsabilità verso i clienti.

Il dato si può osservare dall'esterno. A differenza di molte dipendenze interne, gli script caricati da una pagina pubblica sono visibili a chiunque la apra. Una scansione esterna delle pagine di login e pagamento dei proponenti può mostrare quali fornitori ricorrono nel portafoglio, prima ancora del questionario.

Controlli e tempi di reazione

La Content Security Policy non basta da sola. Polymarket aveva una policy, ma lo script ha usato indirizzi già autorizzati, cioè quelli del sito stesso (Ohey). Una policy limita dove il codice può inviare dati, non cosa può fare dentro la pagina.

L'integrità dei file è il controllo più diretto. Il controllo Subresource Integrity blocca uno script se il suo contenuto cambia rispetto all'impronta attesa. Hudson Rock lo indica tra le misure, insieme alla rimozione degli script non necessari dalle pagine di trading e firma. Il limite è pratico: i fornitori aggiornano spesso i propri script, e l'impronta va aggiornata con un processo controllato.

Un'ora è stata sufficiente. Tra l'arrivo dei primi fondi e la rimozione dello script sono passati circa 50 minuti (Ohey). La reazione è arrivata in meno di un'ora, eppure non ha evitato la perdita. Per transazioni automatiche e irreversibili, contano i controlli che agiscono prima della firma: limiti per sessione, conferme aggiuntive per operazioni insolite, blocco di trasferimenti verso destinazioni nuove.

Cosa portare nei rinnovi

Le domande valgono per qualsiasi assicurato con pagine di login, pagamento o autorizzazione di trasferimenti.

Impatto per gli assicuratoriMedio

Il singolo sinistro è stato contenuto, ma lo stesso vettore su un fornitore molto diffuso produrrebbe sinistri correlati in molti portafogli.

Domande da inserire nel questionario di underwriting

Esiste un inventario degli script di terzi caricati sulle pagine di login, pagamento e conferma, con un responsabile e una motivazione per ciascuno?
Gli script di terzi su quelle pagine sono bloccati da un controllo di integrità o da un sistema che segnala modifiche, e con quale frequenza?
Gli strumenti di analisi e monitoraggio sono esclusi dalle pagine in cui l'utente autorizza un pagamento o un trasferimento?
I contratti con i fornitori di script prevedono obbligo di notifica degli incidenti, tempi certi e limiti di responsabilità adeguati?
Esistono limiti automatici su importi e numero di operazioni per sessione, e conferme aggiuntive per trasferimenti verso destinazioni nuove?
La polizza prevede una garanzia per i rimborsi volontari ai clienti dopo un incidente, e con quale procedura di consenso dell'assicuratore?

Sul lato portafoglio, il lavoro utile è una mappa dei fornitori di script ricorrenti sulle pagine sensibili degli assicurati. Se tre o quattro fornitori compaiono in gran parte del portafoglio, quello è un cumulo da trattare come quello dei grandi fornitori cloud, con scenari e limiti dedicati.