Attackers Used DebugBear’s DNS to Replace a Website Monitoring Script

On October 29, DebugBear asked customers to remove its Real User Monitoring script following an attack on its infrastructure. As Search Engine Journal reports, attackers changed the company’s DNS records through its domain registrar, making malicious JavaScript available at the monitoring script’s URL. The warning applies to site owners who use DebugBear to track Core Web Vitals.

How the monitoring script became an attack vector

Real User Monitoring works through JavaScript that a site owner adds to a page. In the example cited by Search Engine Journal, the script loads from cdn.debugbear.com; the file identifier varies by site. As long as the tag remains in a template, plugin, or tag manager, a visitor’s browser may request the script. That is why the company recommends removing the tag, not simply stopping checking the reports.

After its initial investigation, DebugBear said the attack had targeted one customer’s website. The company found no evidence that its internal systems had been compromised. In the same message, it warned that it was not receiving emails sent to its domain and suggested following the DebugBear account on X for updates.

More is known about what happened on one site. Hudson Rock found malicious JavaScript at the DebugBear script URL that Polymarket used on October 29. The code looked for a trading client already available in the browser of a visitor logged into their account. According to Polymarket’s October 30 report, the script sold positions and transferred funds from some users’ wallets. It did not need a password: it used the access the logged-in user already had.

That does not mean every site using DebugBear received the same code or suffered the same consequences. It remains unclear whether the malicious JavaScript was served to other customers. The variant found targeted Polymarket trading accounts. But site owners still face a question: what could a replaced script do if a visitor with an active session loads it?

What site owners and teams should check

The first step for sites using DebugBear Real User Monitoring is to remove the tag. Developers should check not just page code but also templates, plugins, and tag managers, then clear cached pages and confirm that browsers no longer load the script. Marketing and SEO teams tracking speed metrics should pass the warning to those responsible for the site and its security: simply disabling a report in their workflow is not enough.

Removing the tag stops new loads, but it does not undo anything that may have happened earlier. The next task is to determine whose accounts may have been at risk while the script was active. Start by checking administrators and other privileged users who visited affected pages, terminating potentially exposed sessions, changing passwords, and revoking API credentials that may have been compromised. If it is not possible to identify all affected users, broaden the reset. Check separately that old sessions have actually stopped working: changing a password alone may not close them.

Next, look for unauthorized changes. Teams are advised to compare account creation, permission changes, tag manager history, templates, plugins, and added scripts against a known-clean version. Logs should be checked for unusual logins, new accounts, file changes, and unexpected transactions during the period when the script was installed. Indicators of malicious code from The Layman Security’s analysis may help with the search. Suspicious activity should be investigated, unauthorized access shut down, and confirmed unauthorized changes reversed. These checks do not mean backdoors have already been found on other sites; the aim is not to miss a possible continuation of the attack.

If a compromise is confirmed, the source advises isolating the site and serving a static maintenance page with an HTTP 503 response. Then remove the malicious code or restore a clean backup, check that no access has been left behind, and only then bring the site back online. Briefly disabling the tag is no substitute for an investigation if the logs already show suspicious activity.

My take: a speed-monitoring script needs scrutiny too

I’m used to thinking of monitoring as a way to see where a page slows down for real people. But this story is a reminder that code used to measure speed still runs in a visitor’s browser. If that code is replaced, a tidy layout and a good Core Web Vitals score will not help someone who is already logged into an account. That is a rather bitter irony for a tool meant to make a site better.

I would not take this to mean that every site should abandon third-party scripts. But the next time I add a tag, I want a clearer idea of where it lives and how to remove it quickly from everywhere, including the cache. And if there are signs of unauthorized activity, stopping at “we removed the script” is a bit like mopping up water without checking whether the tap is off.

Sources

Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.

1. Hackers Hijacked DebugBear’s DNS To Serve Malicious JavaScript via @sejournal, @vahandev www.searchenginejournal.com

About the author

Nikos P. Georgiou

aspiring UI designer

I build interfaces for practice projects and take on small freelance tasks. Right now I’m learning to make a neat responsive grid instead of just shrinking the layout.

All posts by the author