Polymarket: script RUM DebugBear compromis fură criptomonede

Pe 29 octombrie 2026, Polymarket, platforma de piețe predictive bazată pe criptomonede, a suspendat timp de aproximativ o oră tranzacționarea pe platforma sa internațională, Polymarket.com, după compromiterea unui furnizor terț. Potrivit BleepingComputer, SecurityWeek și The Record, furnizorul este DebugBear, serviciu britanic de monitorizare a performanței site-urilor web: din infrastructura sa a fost servit un JavaScript malițios care a folosit sesiunile utilizatorilor autentificați pentru a le transfera activele în portofele controlate de atacator.

Polymarket a confirmat incidentul, l-a semnalat autorităților și s-a angajat să despăgubească toți utilizatorii afectați. Nu a precizat însă numele furnizorului, numărul victimelor și nici suma sustrasă. Potrivit SecurityWeek, platforma Polymarket din SUA nu a fost afectată.

Cronologia

Cele trei publicații sunt de acord asupra pașilor principali, reconstituiți din pagina de stare și din mesajele publice ale Polymarket (ore UTC):

• 17:50–17:56: potrivit analizei blockchain făcute de BleepingComputer, portofelul suspect execută numeroase tranzacții pe contractul tokenurilor de piețe predictive al Polymarket;
• 17:59: Hudson Rock identifică un build de producție Polymarket cu mesajul de commit chore(polymarket): remove debugbear rum script (#15337), adică eliminarea integrării DebugBear;
• 18:05: exchange-ul trece în modul „doar anulare” și operațiunile relayer-ului sunt suspendate;
• 18:37: Polymarket anunță că a identificat și corectat problema, dar oprește tranzacționarea din prudență;
• 19:05: incident închis și tranzacționare din nou activă.

DebugBear a confirmat că este afectată de un „incident de securitate în curs”, le-a cerut clienților produsului RUM (Real User Monitoring) să scoată codul de integrare de pe site-uri și, potrivit SecurityWeek, a apelat la specialiști în răspunsul la incidente.

Cum funcționa scriptul

Serviciile RUM folosesc un fragment JavaScript inserat în paginile clientului, care măsoară performanța în browserul vizitatorilor. Tocmai de aceea scriptul rulează cu aceleași privilegii ca propriul cod al site-ului. Potrivit Hudson Rock și BleepingComputer, versiunea malițioasă era servită de la cdn.debugbear[.]com/C7xcKKrjUnXK.js și:

1. verifica dacă vizitatorul era autentificat pe Polymarket;
2. citea soldurile în criptomonede și pozițiile pe piețele predictive pentru a le estima valoarea;
3. în funcție de tipul de autentificare al contului, vindea pozițiile și muta câștigul sau transfera direct tokenurile pozițiilor la o adresă aleasă de atacator;
4. convertea criptomonedele în active transferabile folosind chiar funcțiile de tranzacționare ale platformei.

BleepingComputer, care a analizat o copie a fișierului, arată că scriptul schimba date cu data.debugbear[.]com pentru a primi instrucțiuni și a trimite conturile vizate, adresele portofelelor, soldurile și rezultatele tranzacțiilor: aceeași infrastructură a furnizorului servea deci atât la distribuire, cât și drept canal de comandă și control. Hudson Rock precizează că codul citește materiale legate de credențiale, dar nu a găsit rutine care să trimită parole, seed phrase-uri sau chei private: abordarea este refolosirea autorității deja disponibile în aplicația autentificată.

Încă nu se știe cum a fost modificat scriptul. Hudson Rock spune că nu are indicii despre un atac mai amplu asupra altor clienți DebugBear.

În lectura noastră, tehnicile MITRE ATT&CK relevante sunt T1195.002 (Compromise Software Supply Chain), T1185 (Browser Session Hijacking), T1071.001 (Web Protocols), T1041 (Exfiltration Over C2 Channel) și T1657 (Financial Theft).

Pierderile: estimări diferite

Cifrele nu coincid și niciuna nu este oficială:

• BleepingComputer a urmărit aproximativ 28,6 milioane POL (circa 2,57 milioane de dolari) transferați din portofelul suspect în alte trei portofele;
• Hudson Rock a văzut aproximativ 2,19 milioane la adresa de rezervă scrisă în script, precizând că nu este un total verificat;
• potrivit SecurityWeek, GoPlus estimează aproximativ 2,71 milioane, cu un traseu care trece prin 710 portofele de depunere și 731 de adrese (care nu corespund numărului victimelor), iar datele Arkham indică aproximativ 2,65 milioane la aceeași adresă;
• The Record vorbește de peste 2,1 milioane, potrivit mai multor firme de securitate blockchain.

SecurityWeek amintește și că, în iunie, Polymarket comunicase deja o altă compromitere a unui furnizor terț, cu un script malițios injectat în frontend și pierderi estimate la aproximativ 3 milioane de dolari.

Impactul pentru companiile europene și italiene

Cazul depășește lumea criptomonedelor. Orice script terț încărcat într-o pagină (monitorizarea performanței, statistici, tag manager, chat, teste A/B) poate citi și face tot ce poate face utilizatorul autentificat. În zonele rezervate ale băncilor, magazinelor online, portalurilor medicale și aplicațiilor SaaS, asta înseamnă date personale, comenzi, plăți și operațiuni dispozitive.

Pentru entitățile NIS2, furnizorii acestor scripturi intră în securitatea lanțului de aprovizionare: trebuie inventariați și evaluați ca orice alt furnizor TIC. Un script compromis care citește date în paginile autentificate trebuie evaluat și ca posibilă încălcare a securității datelor personale în sensul GDPR.

Ce să faci acum

1. Dacă folosești DebugBear RUM, scoate codul de integrare, așa cum indică furnizorul, și caută în logurile proxy-ului și ale firewall-ului și în rapoartele CSP cererile către cdn.debugbear[.]com și data.debugbear[.]com.
2. Fă inventarul scripturilor externe încărcate în producție, începând cu paginile autentificate și cu cele care inițiază tranzacții.
3. Scoate din paginile sensibile scripturile de care nu au nevoie pentru a funcționa: monitorizarea și statisticile trebuie rareori să ruleze acolo unde utilizatorul gestionează bani sau date.
4. Aplică o Content Security Policy cu script-src și connect-src limitate la domeniile necesare și cu raportarea încălcărilor activată.
5. Acolo unde scriptul este static, găzduiește o copie versionată sau folosește Subresource Integrity; pentru scripturile care se schimbă des, urmărește modificările conținutului.
6. Pe server, cere o confirmare separată pentru operațiunile cu risc ridicat (retrageri, transferuri către destinatari noi) și urmărește rafalele anormale de tranzacții din aceeași sesiune: un script care refolosește sesiunea nu trece de un al doilea factor cerut în momentul operațiunii.
7. Dacă lucrezi cu criptomonede, adaugă în listele de blocare adresa semnalată de Hudson Rock: 0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18.

Cum ajută ARXDOME

ARX Horizon îți permite să cauți indicatorii publici ai acestui incident în sursele de threat intelligence, iar evenimentele firewall-urilor colectate de ARX Sentry, îmbogățite cu listele de amenințări, te ajută să afli dacă stațiile de lucru și serverele companiei au contactat domeniile folosite de script.

Ultima actualizare: 30 octombrie 2026