DebugBear Tells Customers to Remove Its Script After DNS Hack

DebugBear has ordered customers to remove its Real User Monitoring script after attackers hijacked the company's DNS records and pushed malicious JavaScript that drained funds from Polymarket users' wallets.

In an October 30 update, DebugBear said attackers compromised its DNS records through its domain registrar. The company's initial investigation showed the attack targeted one customer's website, and it found no indication that its internal systems had been compromised. DebugBear also said it could not receive email sent to its domain and directed customers to follow updates on its X account.

The clearest picture of the damage comes from two third parties. Cybersecurity firm Hudson Rock found malicious JavaScript at a DebugBear script URL used by Polymarket on October 29. Polymarket's own October 30 incident report confirmed the script sold positions and moved funds from some users' wallets. The code exploited the access a signed-in visitor already had in the browser's trading client; it did not need the user's password.

That mechanism defines the risk for every other site running the script. The question practitioners should ask is: what could malicious code do with the permissions of a visitor who is already signed in? On a high-value site, that can mean transactions, fund transfers or administrative actions performed silently under a legitimate session.

What should site owners do now?

SEO teams should flag the incident to their development and security teams immediately. The concrete steps:

• Remove the DebugBear Real User Monitoring embed. Check templates, plugins and tag managers, clear cached pages, and verify the script no longer loads.
• Invalidate exposed sessions and reset passwords. Start with administrators and privileged users who loaded affected pages, and revoke potentially exposed API credentials. Widen the reset if exposure cannot be established. Confirm old sessions are rejected, because changing a password may not invalidate 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 changes. Review logs for unusual logins, new accounts, changed files and unexpected transactions while the script was active. Use the indicators in The Layman Security's analysis to guide the search.
• Put a confirmed-compromised site into maintenance mode. Isolate the site, serve a static page with an HTTP 503 response, clean up or restore a known clean backup, and verify backdoors are gone before going back online.

These are checks to perform, not confirmed findings at other customers, the source stresses.

Does removing the tag fix the problem?

No. Removing the monitoring tag prevents new loads of the script. It does not reverse unauthorized actions already taken, and it does not remove anything an attacker may have planted on a site while the code was active. Log review and session invalidation remain necessary.

It is not yet clear whether other DebugBear customers received malicious code. The retrieved payload targeted Polymarket's trading accounts specifically, but attackers used the compromised script to reach that high-value target — and other high-value websites may have been targeted as well. Until DebugBear publishes more findings, every site that ran the script should treat its authenticated visitors' sessions as the perimeter that was exposed.

By Priya Raman