DebugBear RUM Script Hijacked on Polymarket: Check Your Site

Polymarket switched its exchange to cancel-only mode on Thursday, October 29, then halted trading for about an hour, after attackers used a compromised DebugBear RUM script to serve crypto-draining code on Polymarket.com. If your site loads a monitoring or analytics tag from an outside vendor, you depend on the same kind of trust.

What happened at Polymarket, and what did the company confirm?

Polymarket confirmed that “one of our third party providers was compromised” and used to serve malicious JavaScript to visitors of Polymarket.com, its international platform. The company referred the case to law enforcement.

Blockchain records show a suspect wallet making repeated transactions against Polymarket’s prediction-market token contract between 1:50 and 1:56 p.m. ET. At 2:05 p.m. the exchange went cancel-only and paused relayer actions. At 2:37 p.m. Polymarket said the issue was fixed and halted trading as a precaution. Trading resumed at 3:05 p.m.

Polymarket says it is “fully reimbursing all affected traders” but has not said how many users were hit, how much was taken, or how payouts will work.

Hudson Rock, which found the suspected attacker wallet embedded in the script, put its holdings at about $2.19 million. BleepingComputer traced roughly 28.6 million POL, worth about $2.57 million, from it to three other wallets.

How did a DebugBear RUM script act like a logged-in user?

It ran inside Polymarket’s pages, so the browser treated it as Polymarket’s own code. DebugBear’s Real User Monitoring uses a small JavaScript embed, loaded from DebugBear’s servers on every page view, that reports load times from real visitors. One change at the source reaches every customer site.

A script loaded this way can read the page and browser storage and send requests that carry the visitor’s session. HttpOnly cookies stop a script from copying the session cookie, not from using it.

According to BleepingComputer’s analysis of a copy, the script:

• checked whether the visitor was logged in, then read balances and open positions to estimate the account’s value;
• depending on how the user authenticated, sold positions automatically or transferred the position tokens to the attacker wallet;
• converted other crypto holdings through Polymarket’s own transaction functions for withdrawal;
• contacted a DebugBear-associated server for instructions and to report targeted accounts, wallet addresses, balances and transaction results.

Hudson Rock also found Polymarket build metadata with the commit message chore(polymarket): remove debugbear rum script (#15337), stamped 1:59 p.m. ET, six minutes before the cancel-only switch.

Is the DebugBear RUM script on your site right now?

Check today. DebugBear posted on X that it was “impacted by an ongoing security incident” and told customers: “If you use our RUM product, please remove the embed code from your website.” Its own website then went down behind a Cloudflare error.

Search for the string “debugbear” in:

• WordPress: header and footer injection plugins, theme header files and page-builder code fields.
• Joomla: the template’s index.php, custom HTML modules and system plugins that add head scripts.
• Tag managers: Google Tag Manager or similar, including old container versions someone may republish.
• Hardcoded includes in static sites, landing-page builders or headless frontends.

Then open the live site in a private window, filter the browser’s Network tab for “debugbear” and check several page types, including login and checkout, since tags are often scoped to specific templates.

How do you remove a vendor embed without breaking the site?

Delete it where it is injected, purge every cache, then confirm the vendor host no longer loads. A RUM tag does not power site features, so removal is low risk.

1. Save evidence first. Copy the served script, page HTML, response headers and a HAR file. Once the vendor fixes its file, the version that ran on your site is gone.
2. Remove the snippet at its source: plugin, theme, module or tag manager. In a tag manager, publish the change, don’t just save it.
3. Purge caches: page cache plugin, server cache and CDN edge. Cached HTML can keep pulling the script.
4. Retest: reload uncached pages, confirm no vendor requests, and check login, forms and checkout.

In cleanups we often find a “removed” tag still live because it existed in two places, typically a plugin and a tag manager added years apart.

Don’t reinstall the embed until DebugBear publishes what changed and how it was fixed.

What if your own users may have been affected?

If your site ran the embed and handles logins, payments or account changes, assume the script could act as any visitor who loaded a page while it was live. Server logs won’t single it out: actions inside a session look like the user’s own clicks.

• Force-expire active sessions.
• Review orders, transfers, payout details and account settings changed while the embed was live, and match them against customer complaints.
• Check whether privacy law, card-scheme rules or customer contracts require notification, and by when.

What should owners decide about third-party scripts?

Most business sites carry several tags with the same browser power as their own code: analytics, RUM, chat, A/B testing, heatmaps, ad pixels and review badges. Our write-up of the Convertr checkout skimmer shows the same mechanics in e-commerce: one shared analytics file, edited once, ran on every merchant’s checkout.

Decide this week:

• Inventory every third-party script, assign an owner and remove tags nobody can justify.
• Keep non-essential scripts off login, account and payment pages.
• Use Subresource Integrity for scripts that rarely change, so the browser rejects a modified file. It suits frequently updated RUM tags poorly and needs CORS headers.
• A Content Security Policy host allowlist still trusts an approved vendor domain after that vendor is compromised.
• Continuous website malware monitoring checks your pages for new or changed scripts.

What is still unknown?

DebugBear has not explained how its infrastructure was compromised or how long the malicious file was served. Its warning to every RUM customer suggests exposure beyond Polymarket, but no other affected sites have been named and no threat actor has been identified. Neither company had answered BleepingComputer’s questions at the time of its report.

FAQ

What happened to Polymarket on October 29?

A compromised DebugBear monitoring script served malicious JavaScript on Polymarket.com that targeted logged-in users' crypto and positions. The exchange went cancel-only, halted trading and resumed about an hour later.

Should I remove the DebugBear RUM script from my website?

Yes. DebugBear told RUM customers to remove the embed and has not issued an all-clear.

Can a performance or analytics script steal from site visitors?

Yes. An embedded script runs with your site's privileges and can send requests using the visitor's session.

Did Polymarket reimburse affected users?

It says it is fully reimbursing all affected traders but has not disclosed how many were affected, the total loss or the process.

If you’re not sure which third-party scripts your pages load, or suspect one has been tampered with, a SiteGuarding website protection package covers script monitoring, cleanup and firewall rules.