---
title: "DebugBear Tells Customers to Remove Its Core Web Vitals Script After a DNS Hijack"
description: "DebugBear says attackers took over its DNS and told customers to remove its real user monitoring script. Here is what to remove and what to check."
tldr: "DebugBear, a website performance monitoring company, told customers on 29 October 2026 to remove its Real User Monitoring script, which collects Core Web Vitals, after attackers took over its DNS through its domain registrar. DebugBear says the attack appears to have targeted one customer, but it had not said by 2 November that the script is safe to put back. Removing it stops new loads and undoes nothing the code already did."
publishDate: 2026-11-02
author: "Liam Hayward"
---
DebugBear, which sells website performance monitoring, posted this instruction on 29 October 2026 about its Real User Monitoring (RUM) product, the script sites load to collect Core Web Vitals from real visitors:

> If you use our RUM product, please remove the embed code from your website.

In a follow-up on 30 October, DebugBear said attackers had compromised its DNS records through its domain registrar, so requests for its script address could be answered by a server the attackers controlled. It said its initial investigation showed the attack targeted one customer's website and found no sign that its internal systems were compromised. Search Engine Journal reports that the security firm Hudson Rock found malicious JavaScript at a DebugBear script URL used by Polymarket, and that Polymarket's own incident report confirmed the code sold positions and moved funds from some signed-in users' wallets. Whether any other customer was served malicious code is not known.

## What should sites using DebugBear do now?

Remove the script wherever it is added: page templates, plugins and tag managers. Search Engine Journal gives this example of the embed code, in which the script ID varies by site:

```html
<script
  async
  src="https://cdn.debugbear.com/YOUR_SCRIPT_ID.js"
></script>
```

Sites may carry it in a different form: DebugBear's setup documentation says the code can be installed through a tag manager, and that it changes when sampling is set below 1% of visits. Searching your site's code, and the custom HTML tags in your tag manager, for `debugbear` finds it whatever the form. Then clear cached pages and confirm the script no longer loads. DebugBear had not said by 2 November that it is safe to add back, so leave it out until it does.

Removing it stops new loads and undoes nothing, so on any site where signed-in users or administrators loaded pages carrying the script, ask the development or security team to check for new accounts, permission changes, edited tags or templates and unusual logins, and to end active sessions for privileged accounts. Losing the RUM data does not change what Google measures: Search Console's Core Web Vitals report is built from the Chrome UX Report, data Chrome collects from its own users, so expect a gap in your own dashboards and none in Google's.

## Sources

- [DebugBear on X: "We're impacted by an ongoing security incident"](https://x.com/DebugBear/status/2115866496643535293)
- [DebugBear on LinkedIn: follow-up on the investigation](https://www.linkedin.com/posts/debugbear_were-continuing-to-investigate-the-security-activity-7522072665495588865-NsiJ)
- [Hackers Hijacked DebugBear's DNS To Serve Malicious JavaScript, Search Engine Journal](https://www.searchenginejournal.com/debugbear-rum-attack-seo-site-owner-actions/595412/)
- [Set Up Real User Monitoring, DebugBear documentation](https://www.debugbear.com/docs/rum/setup)
- [Core Web Vitals report, Search Console Help](https://support.google.com/webmasters/answer/9205520)