DebugBear DNS Breach: Remove Real User Monitoring Script Now

DebugBear has told customers to remove its Real User Monitoring script after attackers compromised the company's DNS records through its domain registrar, according to an October 30 update from the performance-monitoring vendor. The confirmed incident — not tool-signal speculation — is a supply-chain-style attack that turned a Core Web Vitals (Google's page-speed and stability metrics) tracking tag into a delivery vehicle for malicious JavaScript.

The most concrete damage so far is documented at Polymarket. Cybersecurity firm Hudson Rock found malicious JavaScript at a DebugBear script URL used by the prediction-market site on October 29. The code searched for the trading client already available in a logged-in visitor's browser. Polymarket's own October 30 incident report confirmed the script sold positions and moved funds out of some users' wallets. It needed no password — it simply used the permissions of a signed-in session.

What does DebugBear say happened?

In its October 30 update, DebugBear stated that attackers altered its DNS records (the system that maps a domain to its servers) via its registrar. The company's initial investigation indicated the attack targeted one customer's website, and DebugBear reported no indication its internal systems were compromised. Both statements are vendor assertions; independent verification is not yet public.

The same update noted DebugBear could not receive email sent to its domain. Customers are being directed to the company's X account for updates.

Why should site owners beyond Polymarket care?

The core question for every DebugBear customer: what could malicious code do with the permissions of a visitor already signed in to your site? The retrieved payload targeted Polymarket's trading accounts specifically, but other high-value websites may have been targeted. It is not yet clear whether other DebugBear customers received malicious code. Removing the monitoring tag stops new loads — it does not reverse unauthorized actions or remove anything an attacker may already have planted.

What should SEO and dev teams do right now?

• Remove the embed immediately. Check templates, plugins and tag managers, clear cached pages, and verify the script no longer loads.
• Invalidate sessions and reset passwords. Start with administrators and privileged users who loaded affected pages. Revoke potentially exposed API credentials. If you can't determine which accounts were exposed, widen the reset — and confirm old sessions are rejected, because a password change alone may not kill existing sessions.
• Check for unauthorized changes and persistence. Review account creation, permission changes, tag-manager history, templates, plugins and injected scripts against a known clean version. Investigate whether attackers planted a backdoor for later access.
• Find affected accounts and undo malicious changes. Review logs for unusual logins, new accounts, changed files and unexpected transactions while the script was live. Use the indicators in The Layman Security's analysis to guide the search.
• Put a confirmed-compromised site into maintenance mode. Isolate it, serve a static page with an HTTP 503 response, have security clean the site or restore a known clean backup, and verify no malicious code or backdoors remain before going back online.

These are precautionary checks, DebugBear has not confirmed findings at other customers.

Which sites face the most exposure?

High-value targets are the obvious profile: fintech, trading platforms, commerce and any site where a signed-in session can move money or data. But any DebugBear RUM customer should treat the window while the script was live as an audit boundary, because session-hijacking code inherits whatever the visitor could do.

Watch DebugBear's X account for the vendor's next update, and monitor Hudson Rock's and The Layman Security's analyses for additional indicators of compromise — the question of whether other customers received malicious payloads remains open.