Il 29 ottobre 2026 DebugBear ha chiesto ai clienti del proprio servizio Real User Monitoring di rimuovere il codice incorporato nei siti. Il servizio serve a misurare le prestazioni delle pagine durante le visite reali. In un successivo aggiornamento, l’azienda ha confermato la compromissione dei record DNS attraverso il registrar del dominio.
Per chi gestisce un’impresa, il caso pone una domanda concreta: sappiamo quali fornitori eseguono codice nel sito, su quali pagine e con quale procedura possiamo disattivarli? Un’integrazione installata per migliorare il marketing o misurare la velocità entra a far parte del funzionamento del sito. Anche quando viene considerata soltanto un piccolo tag.
Che cosa è confermato e che cosa resta da verificare
L’avviso originale di DebugBear riguarda gli utilizzatori del prodotto RUM. Nel successivo comunicato pubblico, il fornitore riferisce che l’indagine preliminare indicava come bersaglio il sito di un cliente e che non erano emerse evidenze di compromissione dei sistemi interni. Sono indicazioni attribuite all’azienda, mentre l’indagine proseguiva.
Questo non consente di concludere che tutti i siti clienti abbiano ricevuto codice malevolo. Al 2 novembre, nelle fonti consultate per questa bozza, non è stata recuperata una successiva autorizzazione ufficiale a reinstallare lo script.
Il cliente coinvolto nel caso documentato è Polymarket. Nel resoconto ufficiale del 30 ottobre, la piattaforma spiega che uno script del fornitore era stato sostituito con codice costruito per colpire i suoi utenti. Per alcune persone con una sessione attiva, il codice ha venduto posizioni e spostato fondi. Polymarket riferisce di aver rimosso lo script, svuotato le cache e reimpostato le sessioni, oltre ad aver sospeso temporaneamente gli scambi.
La ripresa del servizio di Polymarket riguarda quella piattaforma: non certifica lo stato delle integrazioni presenti su altri siti. La copertura SEO del 31 ottobre riprende l’incidente, ma la data dell’evento resta il 29 ottobre.
Perché uno strumento di misurazione riguarda anche la direzione aziendale
Secondo la guida OWASP sulla gestione del JavaScript di terze parti, il codice esterno può cambiare nel tempo e introdurre rischi di esecuzione di codice o divulgazione di informazioni. La sua finalità dichiarata, per esempio raccogliere statistiche, non rappresenta da sola un confine tecnico alle sue capacità.
Nel caso specifico, l’analisi tecnica di Ohey descrive codice adattato a Polymarket e alle funzionalità già disponibili nella pagina. Non è la prova che un normale sito di servizi sia esposto allo stesso identico meccanismo. Mostra però perché la valutazione di un’integrazione debba considerare anche il contesto nel quale viene caricata.
Una landing informativa, un modulo contatti e un’area riservata hanno funzioni e conseguenze commerciali differenti. La proposta operativa è assegnare a ciascuna integrazione un responsabile aziendale, oltre al tecnico che l’ha installata. Il primo ne giustifica l’utilità; il secondo ne documenta il funzionamento e la rimozione.
Se il sito usa DebugBear RUM, quali evidenze chiedere
Per le aziende interessate, il punto di partenza è l’indicazione del fornitore di rimuovere il codice RUM. Le attività seguenti sono una traccia di lavoro per il team tecnico e di sicurezza: non descrivono anomalie già riscontrate sul sito del lettore.
| Domanda aziendale | Evidenza da ottenere | Responsabile da coinvolgere |
|---|---|---|
| Dove è presente l’integrazione? | Elenco dei siti e degli ambienti interessati, delle pagine e del punto di installazione: template, plugin o tag manager. | Sviluppatore o agenzia che gestisce il sito. |
| È stata effettivamente rimossa? | Registrazione dell’intervento e verifica dei caricamenti nelle pagine pubblicate, tenendo conto delle cache. | Team tecnico. |
| Quale periodo dobbiamo esaminare? | Ricostruzione dei tempi di presenza dell’integrazione e dei dati disponibili per l’analisi. | Team tecnico e sicurezza. |
| Ci sono conseguenze confermate? | Risultati delle verifiche su attività, accessi e modifiche pertinenti, distinguendo evidenze e punti ancora aperti. | Responsabile sicurezza con i referenti dei sistemi coinvolti. |
| Che cosa manca nei report? | Annotazione del periodo senza raccolta RUM e indicazione delle misurazioni rimaste disponibili. | Responsabile analytics o SEO. |
La risposta utile per la direzione è un breve verbale con data, perimetro verificato, interventi ed esiti. “Abbiamo tolto il tag” documenta una misura di contenimento. Non sostituisce la valutazione delle attività avvenute mentre il codice era presente. L’eventuale revoca di sessioni o credenziali va decisa dal team competente in base al perimetro e alle evidenze, senza applicare automaticamente a ogni azienda le misure adottate da Polymarket.
Se non usi DebugBear, parti dall’elenco dei fornitori
Il caso può diventare l’occasione per una revisione circoscritta delle integrazioni. Un inventario utile dovrebbe riportare nome del servizio, finalità, pagine sulle quali viene caricato, referente, data dell’ultima revisione e procedura di disattivazione. L’obiettivo è poter prendere una decisione rapidamente quando arriva una segnalazione.
Un esempio ipotetico: un ecommerce conserva un tag di una prova terminata mesi prima. Nessuno lo consulta, ma continua a essere caricato nelle pagine. La domanda commerciale precede quella tecnica: quale beneficio attuale ne giustifica la presenza? Se il beneficio non è più identificabile, il referente può concordare una rimozione verificata, controllando le dipendenze.
Una seconda decisione riguarda le pagine più delicate. È ragionevole chiedere al team di motivare ogni integrazione presente nei percorsi di acquisto o nelle aree riservate. Questo criterio non impone di rinunciare alla misurazione: richiede di valutare dove serve davvero e con quali modalità.
Le protezioni tecniche vanno scelte insieme a chi mantiene il sito
OWASP descrive misure come Subresource Integrity, isolamento e accordi con i fornitori. SRI permette di verificare che una risorsa corrisponda al contenuto atteso, ma richiede condizioni tecniche compatibili e una gestione degli aggiornamenti. Non è una spunta universale da aggiungere a ogni integrazione.
Per l’azienda, la richiesta può essere formulata così: quali controlli sono applicabili alle nostre integrazioni, chi li mantiene e come verifichiamo che non interrompano funzioni necessarie? Conviene ottenere una proposta con priorità, costi e limiti, anziché adottare una singola misura come garanzia assoluta.
Misurazione, continuità del servizio e decisioni commerciali
Se viene sospesa una raccolta dati, il periodo va segnalato nei report. Un numero inferiore di eventi raccolti non deve essere presentato automaticamente come un calo di utenti o richieste. Prima del confronto commerciale, occorre chiarire quali fonti abbiano continuato a funzionare e quali dati non siano disponibili.
La direzione può chiedere un aggiornamento distinto su tre aspetti: stato del servizio, stato delle verifiche di sicurezza e qualità dei dati utilizzati per decidere. Separarli aiuta a evitare che il ritorno online venga confuso con la chiusura dell’indagine o con la piena confrontabilità delle statistiche.
Per la prossima integrazione, la decisione dovrebbe già includere una persona responsabile, le pagine autorizzate e una procedura di uscita. Sono informazioni da definire quando si approva il servizio, mentre il suo valore per l’azienda è ancora chiaro.