DebugBear Script Compromised: What Site Owners Should Do

DebugBear, a tool that measures site speed and Core Web Vitals, told customers of its RUM product on October 29, 2026 to remove its script from their websites. Attackers had taken over its DNS records and served malicious code to Polymarket, which lost user funds. If that script is on your site, act now.

What we know

  • The warning: on October 29, DebugBear posted on its official X account that it was affected by "an ongoing security incident" and asked anyone using its RUM product (real-user monitoring) to remove the embed code.
  • The cause, according to DebugBear: on October 30 it said its DNS records were compromised through its domain registrar. Its initial investigation found the attack targeted one specific customer's website, and it has seen no sign that its internal systems were breached. It also said it cannot receive email sent to its domain.
  • The victim, according to Polymarket: its status page says that on October 29, between 17:38 and 18:15 UTC, a performance-monitoring vendor's script was replaced with one built to target its users. For people who had the site open in that window, it used their sessions to sell positions and move funds. Polymarket does not name the vendor.
  • Polymarket's response: it removed the script, cleared caches, paused trading, reset all sessions and redeployed its third-party scripts with extra controls. It says it is returning $3.9 million ($2.7 million in drained funds plus $1.2 million for the trading pause) and had fully refunded 95% of affected wallets by October 30.
  • The file: security firm Hudson Rock analyzed a file served from cdn.debugbear.com on October 29. According to its report, the code looked for Polymarket's trading client in the browser to sell positions. Hudson Rock adds that its evidence does not show other DebugBear customers received malicious code.

What changes and what doesn't

  • Unknown so far: whether any other site was served altered code. DebugBear describes a single target; the investigation is ongoing.
  • Removing the script won't touch your Search Console data. The Core Web Vitals report in Search Console comes from Chrome field data (CrUX), not from RUM tools. You lose your own monitoring for a while, not your rankings.
  • This isn't only about DebugBear. Any script loaded from someone else's domain runs on your site with the same power as your own code. Whoever controls that domain controls what runs on your pages.

How to tell if you're affected

If you used DebugBear RUM:

  1. Remove the snippet from templates, plugins and your tag manager, then purge your site and CDN caches.
  2. Confirm it's gone: open your site with the browser's developer tools (Network tab) and search for "debugbear".
  3. If your site has logins, payments or a customer area, end active sessions and check logs for unusual changes or access since October 29.

For any site that loads third-party scripts:

  1. List every external domain you load code from, and drop the ones you no longer use.
  2. Keep non-essential scripts off sensitive pages such as login, checkout and dashboards. Monitoring can run everywhere else.
  3. Set a Content Security Policy that only allows the domains on your list. It would not have stopped this attack, but it limits where an altered script can send data.
  4. Lock down your own domain: two-factor authentication on your registrar account, transfer lock on, and alerts for DNS changes. DebugBear's problem started at the registrar.

Related: ccTLD Hijacks Led to Rogue Google Certificates: What to Check

Sources

Updates: if DebugBear publishes a final report or confirms other affected sites, it will be added here with a link.