Search

Search PublishMyBlog

Website Tools

DebugBear Tells Sites to Remove Its RUM Script After DNS Hijack

The drainer hit Polymarket, and nobody can yet say whether other sites loading the Core Web Vitals script got bad code too.

By , Editor

4 min read

A closed laptop with a DebugBear bear sticker on a dark desk at night, beside an open padlock and a blue network cable

DebugBear says attackers took over its DNS through its domain registrar and swapped the DebugBear RUM script for malicious code. Remove the DebugBear RUM script from your site now.

Then check your site.

Not sure your site loads the DebugBear RUM script? Search your templates and tag manager for cdn.debugbear.com.

DebugBear first told customers to remove the script on October 29. Its follow-up, reported by Search Engine Journal on October 31, gives the cause.

It says the attack aimed at one customer’s website. No sign its own systems were breached.

DebugBear can’t receive email sent to its domain right now, so you’ll have to follow its updates on X if you want to know what it finds next.

What the hijacked script did

The one customer was Polymarket. The script sold positions and moved funds out of some signed-in users’ wallets, using access they already had.

No password needed.

BleepingComputer traced about $2.5 million to the attacker’s wallet. Polymarket paused trading for about an hour and said anyone affected will be made whole.

Researchers at Ohey put the window at roughly an hour on October 29, between 16:54 and 17:59 UTC. They listed three details:

  • The clean file still came from Google Cloud Storage that morning, but by the time the malicious file was live, a different server was answering for both of DebugBear’s hostnames.
  • The code went after Polymarket alone, reading its storage keys and calling its APIs.
  • Every other server the code called was already on the list allowed by Polymarket’s own Content Security Policy, so the policy meant to block strange requests let all of them through.

So is your site safe because you don’t run a crypto exchange? SEJ says it isn’t yet clear whether other DebugBear customers got the malicious code.

What to do if your site loads the DebugBear RUM script

SEJ’s checklist is thorough, and this is the order I’d follow on your site:

  1. Remove the DebugBear RUM script from your templates, plugins and tag manager, clear caches, and confirm it no longer loads.
  2. End sessions and reset passwords, starting with your admins and anyone else with high privileges who loaded affected pages, then revoke any API keys the script could have reached.
  3. Compare your accounts, permissions, plugins and injected scripts against a known clean version.
  4. If you find a compromise, put your site into maintenance mode, clean it up or restore a known clean backup, and check that any backdoor is gone before you bring it back.

Removing the DebugBear RUM script stops new loads. It doesn’t undo anything the code already did on your site.

Our guide to WordPress backups and test restores covers that last step.

Why it matters

My read: this is the UpdraftPlus breach and the Rank Math PRO backdoor again. A tool you trust becomes the attack.

Every third-party script on your site runs with your visitors’ access. A speed monitor on your checkout page can do whatever a signed-in buyer can do.

Few owners think about that.

So open your tag manager this week and list every third-party script on your site. Do you still use each one?

Then ask whether each script you keep needs to run on your login, account and checkout pages, where a swapped file can do the most damage to you and your visitors.

Still, don’t panic about every tag. Cut the scripts you forgot about.

For the ones you keep, pin files that rarely change with a Subresource Integrity hash, or host them yourself. A swapped file then fails to load.

Lock your own domain too

DebugBear was hit through its registrar. And your own domain?

  • Turn on two-factor login at your registrar.
  • Turn on a registrar lock.
  • Check who else has access.

Our WordPress security checklist has the rest of the basics.

Common Questions

Should I remove the DebugBear RUM script from my site?

Yes. DebugBear told customers on October 29 to remove the DebugBear RUM script from their site, and its October 31 update didn’t say the script was safe to use again.

Did the DebugBear attack affect sites other than Polymarket?

DebugBear says the attack aimed at one customer’s website, Polymarket. It isn’t yet clear whether other DebugBear customers got the malicious code, so check your site if it loaded the script.

Does removing the DebugBear RUM script fix a compromised site?

No. Removing the DebugBear RUM script stops new loads, but it doesn’t undo anything the code already did on your site, like changed accounts or planted files.

All Website Tools news