As reported by The Hacker News, attackers hijacked a DebugBear Real User Monitoring (RUM) script loaded by Polymarket on October 29, 2026, using it to liquidate and drain roughly $2.7 million from 726 signed-in trader wallets. The compromise traces back to DebugBear's domain registrar, not to DebugBear's own infrastructure — a critical distinction that every organization loading third-party JavaScript should internalize immediately.
Why This Attack Pattern Is Dangerous
This incident is a textbook example of a third-party script supply chain compromise executed with unusual operational discipline. The attacker didn't need to breach Polymarket at all. They didn't need to phish users or exploit a smart contract. They simply needed to control a DNS record at a registrar — often the weakest link in any SaaS vendor's security posture — and serve a modified JavaScript file from a URL Polymarket already trusted.
What makes the payload particularly notable is its design restraint. Hudson Rock's analysis confirms the code did not exfiltrate API keys, passwords, seed phrases, or private keys. Instead, it operated entirely within the victim's existing authenticated browser session, invoking Polymarket's own signer and relayer to place and submit orders. This approach minimizes detection surface — there's no suspicious outbound beacon with credentials — while maximizing impact by abusing the legitimate transaction signing flow.
Who Is at Risk
The Defensive Gap That Made This Possible
The single most important technical point: Polymarket was loading an external script without Subresource Integrity (SRI). Had an integrity attribute with a valid hash been present on the <script> tag, the browser would have refused to execute the tampered file and the attack would have failed silently. SRI is not optional for any script tag loading from a third-party CDN or domain — it is a baseline control, and its absence here is the root cause from the defender's perspective.
Additionally, a properly configured Content Security Policy with restrictive script-src and connect-src directives could have blocked either the malicious script's execution or its outbound communication to the attacker's endpoint. RUM scripts legitimately phone home, so CSP tuning must account for that — but the attacker's infrastructure would not have matched any legitimate allowlist.
Broader Implications
This attack validates a growing trend: adversaries are targeting the soft edges of the supply chain — registrars, CDN configurations, build pipelines, and package registries — rather than hardened core infrastructure. Every organization should be asking its third-party script vendors pointed questions: Do you enforce registry lock? Do you rotate DNS API credentials? Do you monitor for unauthorized DNS changes? Do you publish SRI hashes for every shipped script version?
The fact that Polymarket is refunding all affected wallets is commendable but should not obscure the structural lesson: trust in a third-party script is trust in that vendor's entire upstream security stack, including their registrar account. That trust should be minimized, monitored, and structurally bounded wherever possible.
Shield53 Recommendations — What You Should Do
Immediate Actions
- Audit every third-party script tag on all production properties. Identify which lack
integrity(SRI) hashes. Remediate all of them within 72 hours. - Review and tighten Content Security Policy headers. Ensure
script-srcandconnect-srcare explicitly allowlisted. Move from wildcard domain policies to exact-path or hash-based allowlists where feasible. - Contact third-party vendors whose scripts run in authenticated sessions. Require them to confirm registrar lock is enabled, DNS change monitoring is active, and SRI hashes are published for all script versions.
Strategic Hardening
- Implement self-hosting or proxying for critical third-party scripts where the vendor supports it. Serving analytics JavaScript from your own origin removes the DNS compromise vector entirely.
- Deploy runtime script monitoring — tools that alert on unexpected changes to third-party script content, hash mismatches, or new outbound network destinations from loaded scripts.
- Segment sensitive sessions: high-value Web3 and financial operations should not share an authenticated browser context with marketing/analytics/RUM scripts. Architectural separation beats bolted-on controls.
- Require vendor security attestations covering DNS hygiene, registrar account security (MFA, lock, change alerts), and incident notification SLAs in all future procurement and renewal contracts.
The Polymarket attack wasn't a failure of smart contract security or user authentication — it was a failure of script supply chain hygiene. SRI would have stopped it. If your production pages still load third-party scripts without integrity hashes, you are one compromised registrar account away from the same headline.
