# A compromised monitoring script drained $2.7m from Polymarket — $3.9m in refunds follows Polymarket's October 29 breach came through a third-party performance-monitoring script, not a smart-contract flaw. Its October 30 postmortem confirms $2.7 million drained and another $1.2 million in pause-related compensation; Reuters identified DebugBear as the vendor. A third-party analytics-style script used active Polymarket sessions to move funds; the platform reports $3.9m in total reimbursements. - Status: Active - Published: 2026-10-31T21:58:58+13:00 - Updated: 2026-10-31T21:58:58+13:00 - Categories: Web Development, Cloud & Infrastructure, Marketing & Distribution, Deployment & DevOps, Conversion & Analytics - Tags: DebugBear, JavaScript supply chain, Polymarket, security incident, third-party scripts - Canonical HTML: https://beyondthe.news/dossiers/polymarket-debugbear-third-party-script-27m-wallet-drain-39m-refunds ## What changed On October 29, 2026, Polymarket's international website loaded a malicious replacement for a third-party performance-monitoring script. The injected code targeted users with active sessions, sold positions and moved funds from their wallets. Polymarket paused trading, removed the script, cleared caches, reset sessions and restored operations. Its October 30 postmortem reports $2.7 million in drained funds and an additional $1.2 million to compensate losses linked to the trading pause, for $3.9 million total reimbursement. It said 95% of affected wallets had already been refunded in full at the time of the update. Reuters independently identified performance-monitoring vendor DebugBear, which told its Real User Monitoring customers to remove the embed code while investigating a compromise. ## Why it matters A third-party JavaScript file included for performance telemetry can execute in the same page context as sensitive application code. When the vendor or its delivery pipeline is compromised, an attacker may exploit existing user sessions without stealing credentials or compromising the application's backend or smart contracts. The incident demonstrates that externally hosted analytics and monitoring scripts are part of the production trust boundary, especially in financial applications. Polymarket's postmortem supplies confirmed losses and operational changes rather than only speculative blockchain estimates. ## How the browser supply chain was used Polymarket says attackers replaced a vendor-hosted performance-monitoring script with code designed for its users. During a limited window, the malicious code used logged-in sessions to sell positions and transfer assets. The platform does not attribute the intrusion to a smart-contract vulnerability. Reuters identified DebugBear as the vendor, and the vendor separately advised RUM customers to remove its embedded script. The precise path by which the vendor's script was altered remains under investigation. ## The verified financial and operational impact The October 30 Polymarket status postmortem separates $2.7 million taken through the hack from $1.2 million in additional compensation for positions affected by the trading pause. It says the platform will return $3.9 million overall, and 95% of affected wallets had been refunded in full at the time of posting. The October 29 incident was marked resolved after the web app and account access experienced a major outage; the published 37-minute incident window should not be conflated with the complete period of malicious activity. ## What the response changes Polymarket removed the compromised script, cleared caches, paused trading and relayer actions, reset active login sessions and notified law enforcement. It says third-party scripts are being redeployed with stronger integrity controls, continuous verification, content security policy, explicit version pinning and sandboxing. These are planned or ongoing controls, not independently audited guarantees. Other site operators should inventory externally loaded scripts, restrict unnecessary third-party execution and monitor script changes. ## Distinguish this from expired-domain script hijacking This incident involved a currently used vendor's performance-monitoring script being replaced with malicious content. It is distinct from the DeadTag campaign in which attackers acquired expired domains still referenced by old script tags. Both show why scripts loaded from outside an application's own codebase deserve explicit trust and integrity review, but the entry paths and observed outcomes differ. ## Key details - Incident: October 29, 2026, Polymarket international web app. - Postmortem: October 30, 2026 at 20:07 UTC. - $2.7m drained; $1.2m additional pause-related compensation; $3.9m total reimbursement announced. - 95% of affected wallets reportedly fully refunded at the postmortem's publication. - Attackers replaced a third-party performance-monitoring JavaScript script and used active sessions. - Reuters identified the vendor as DebugBear; it advised RUM customers to remove the embed. - Polymarket removed script, cleared caches, reset sessions, paused and restored trading. - The precise upstream compromise mechanism has not been established. ## Builder takeaways - Inventory all third-party JavaScript, including performance monitoring, analytics, chat widgets and tag managers, on pages with sensitive actions. - Where supported, use pinned immutable script versions, Subresource Integrity and a restrictive Content Security Policy; assess sandboxing or self-hosting options. - Monitor unexpected changes to third-party scripts and retain an emergency disable mechanism. - Treat active browser sessions as high-value credentials; an injected script may use existing permissions without knowing a password. - Do not confuse an incident's trading-pause duration with the full malicious-script exposure window. ## What to watch - DebugBear's technical postmortem and the root cause of the script replacement. - Polymarket's final reimbursement completion and independently audited security controls. - Whether other RUM customers were served malicious code and whether additional incidents are confirmed. ## Uncertainties - The initial intrusion path into DebugBear's script delivery system is not established. - The confirmed $3.9m reimbursement total includes $1.2m pause-related losses, not only stolen assets. - The exact count of affected wallets and the malicious-script exposure window are not specified in the primary postmortem. - No independent audit of Polymarket's planned integrity controls was available. ## Sources - [Security incident — third-party vendor compromised (postmortem)](https://status.polymarket.com/cmvvek1i90eme14ruga1z6tuj) — Polymarket Status · primary_incident_postmortem · 2026-10-30T00:00:00+13:00. Confirmed attack mechanism, incident response, $2.7m drained, $1.2m compensation and 95% refund progress. - [Polymarket resumes trading after third-party security breach](https://www.reuters.com/business/polymarket-reports-major-outage-suspends-trading-actions-2026-10-29/) — Reuters · independent_reporting · 2026-10-29T00:00:00+13:00. Independent identification of DebugBear and vendor warning to RUM customers. - [How we secure our analytics script](https://usefathom.com/blog/how-we-secure-our-analytics-script/) — Fathom Analytics · independent_vendor_analysis · 2026-10-30T00:00:00+13:00. Security-practitioner discussion of the vendor-script risk and mitigations; vendor's own claims not independently audited.