DebugBear DNS Hijacked by Hackers

Website owners using DebugBear’s Real User Monitoring (RUM) script have been warned to remove it following a security breach that exposed websites to malicious JavaScript.

The incident was reported on 29 October 2026, when harmful code was discovered within DebugBear’s monitoring script. The company later confirmed that attackers had gained control of its DNS records through its domain registrar.

DebugBear advised customers to remove its RUM script from their websites while investigations continued. SEO teams should also alert their development and security departments to check for suspicious activity, unauthorised access and any changes made to their websites.

What happened to DebugBear?

DebugBear is a monitoring platform commonly used by SEO professionals to track real user performance and Core Web Vitals. Its security warning affects website owners who have installed the company’s RUM script.

On 29 October, DebugBear instructed customers to remove the monitoring script after identifying a security issue involving its infrastructure.

The company later provided further details, confirming that attackers had compromised its DNS records through its domain registrar. According to its initial investigation, the incident appeared to have targeted one customer’s website. DebugBear also said there was no evidence that its internal systems had been breached.

The company reported another issue during the incident, explaining that it was unable to receive emails sent to its domain. Customers were advised to follow its official channels for further updates.

Cybersecurity researchers at Hudson Rock identified malicious JavaScript being served through a DebugBear script URL used by Polymarket on 29 October.

The code was designed to interact with the trading platform through a visitor’s existing logged-in browser session. Polymarket later confirmed that the incident allowed attackers to sell positions and transfer funds from some users’ wallets.

Importantly, the malicious code did not need to obtain users’ passwords. Instead, it took advantage of the access already available through their active sessions.

This raises concerns for other website owners, as malicious third-party scripts could potentially misuse the permissions of visitors who are already signed in.

What should website owners using DebugBear do?

Website owners should involve their development and security teams immediately to remove the affected script and investigate any possible exposure.

The following actions should be considered:

Remove the DebugBear monitoring script. Find and delete the RUM code from website templates, plugins and tag managers. Clear cached pages and check that the script is no longer loading on the website.
Review passwords and active sessions. Reset passwords for potentially affected accounts, particularly administrators and users with higher-level permissions. Revoke exposed API credentials and invalidate existing sessions where necessary. Changing a password alone may not automatically end active sessions.
Look for unauthorised changes or backdoors. Check user accounts, permissions, website files, plugins, templates and tag-manager activity for anything unusual. Compare current files with clean versions where possible to identify unexpected changes. These checks are precautionary and do not mean that other DebugBear customers have been confirmed as compromised.
Investigate suspicious account activity. Review security logs for unusual sign-ins, newly created accounts, altered files and unexpected transactions during the period when the script was active. Security teams can also use indicators identified in published analyses of the incident to help with their investigation. Remove unauthorised access and reverse any confirmed malicious changes.
Take a compromised website offline if necessary. If an investigation confirms that a website has been affected, the development team should consider isolating it and displaying a temporary maintenance page with an HTTP 503 response. The site should be cleaned or restored from a known safe backup, with malicious code and any backdoors removed before it goes live again.

Could other websites be at risk?

The malicious script identified in the investigation targeted Polymarket’s trading accounts, allowing attackers to access existing sessions and move funds. However, it remains unclear whether other DebugBear customers were also exposed to the malicious code.

Removing the monitoring script is an important first step, as it prevents the affected code from loading again. However, this does not undo any actions attackers may have already taken or remove malicious changes that could have been left behind.

Website owners should therefore treat the incident as a security issue rather than simply removing a third-party script. Working with development and security teams to review accounts, website files and activity logs can help identify any further problems.