Security notice
Does your site load DebugBear's monitoring script? DebugBear says remove it now.
On October 29, 2026, a script served from DebugBear's network was used to hijack logged-in sessions on Polymarket, a prediction market, and move traders' assets to an attacker's wallet, according to BleepingComputer, SecurityWeek and security firm Hudson Rock. DebugBear makes website speed monitoring tools, and Polymarket's site loaded its real user monitoring (RUM) script. DebugBear says it is "impacted by an ongoing security incident" and tells RUM customers: "please remove the embed code from your website." Polymarket halted trading for about an hour and says it is reimbursing affected traders. Estimates of the loss run from about $2.19 million to about $2.71 million depending on who is counting. Hudson Rock has not found that other DebugBear customers were targeted, and how the script was tampered with is not known. If your site loads DebugBear's RUM script, remove it until DebugBear says it is safe, and review the outside scripts on your login and checkout pages.
What happened
- What DebugBear does. DebugBear is a website performance monitoring service. Its real user monitoring (RUM) product is a snippet of JavaScript that customers add to their websites to measure how fast pages load for visitors. A site that uses it loads that script from DebugBear's servers every time a page opens, so whoever controls that script controls code running in every visitor's browser. (BleepingComputer)
- What the script did. According to BleepingComputer and SecurityWeek, Hudson Rock obtained a copy of a malicious script served from DebugBear's content network, at an address Polymarket's site used (cdn.debugbear[.]com). BleepingComputer's analysis found that it checks whether the visitor is logged in to Polymarket and, if so, tries to use that logged-in session and Polymarket's own trading features to sell positions or move tokens and other assets to an attacker-controlled wallet. It exchanged data with another DebugBear address (data.debugbear[.]com) to receive instructions and report on targeted accounts. (BleepingComputer, SecurityWeek)
- It did not need to steal a password. Hudson Rock says the sample reads credential-related material, "but our review did not identify a routine that sends the credential map, a password, a seed phrase, or a private key to its reporting endpoint. Its central approach is to reuse authority already available in the authenticated application." In plain terms, it acted as the logged-in user. (Hudson Rock, SecurityWeek)
- Polymarket's response. Polymarket said: "One of our third party providers was compromised, and we have referred this to relevant law enforcement. Anyone who has been impacted will be made whole." BleepingComputer reports that trading was paused on October 29 and was fully back about an hour later, with Polymarket saying it is "fully reimbursing all affected traders." Polymarket has not named the provider or said how many users were affected or how much was lost. SecurityWeek reports that Polymarket's US platform was reportedly unaffected. (BleepingComputer, SecurityWeek)
- How big the loss was: estimates differ. Hudson Rock saw about $2.19 million at the address hard-coded in the script, and says that is not a verified total. BleepingComputer traced about 28.6 million POL, which it values at about $2.57 million, moving out of that address. SecurityWeek reports that Arkham data showed about $2.65 million in the suspected attacker wallet and that the blockchain security firm GoPlus puts losses at about $2.71 million. That is a range of about $2.19 million to $2.71 million. Nobody has published a confirmed figure. (Hudson Rock, BleepingComputer, SecurityWeek)
- What DebugBear says. At about 2:00 PM ET on October 29, DebugBear posted: "We're impacted by an ongoing security incident. If you use our RUM product, please remove the embed code from your website." At about 6:16 PM ET it posted: "We are aware of a security incident affecting DebugBear and are treating it as a top priority. We have engaged specialist cyber incident response support and will work with affected customers directly. We will share further updates here as appropriate." Neither post names Polymarket. The link to Polymarket comes from Hudson Rock's analysis and the reports above, and from a Polymarket code change titled "remove debugbear rum script" that Hudson Rock found, according to BleepingComputer. When we checked on the morning of October 30, DebugBear's website was returning an error, so we could not read anything there. (DebugBear on X, 2:00 PM ET, DebugBear on X, 6:16 PM ET, BleepingComputer)
- What is not known. Hudson Rock has not determined how the script was tampered with or how many users were hit, and its findings do not show that other DebugBear customers were targeted. We found no report that any company other than Polymarket received the malicious script, but DebugBear has not said who else was exposed, how the attackers got in or when this began. (SecurityWeek, Hudson Rock, DebugBear on X, 2:00 PM ET, DebugBear on X, 6:16 PM ET)
Who should worry
This is about websites that load DebugBear's monitoring script. If you have never heard of DebugBear, you almost certainly do not use it. Ask your developer or agency if you are not sure. Ask about this if any of these are true:
- Your site, or your developer, uses DebugBear for page speed or "real user monitoring."
- Your site's page source or tag manager mentions debugbear.
- Your site has logged-in accounts, a shop, payments or an admin area, and loads outside scripts on those pages.
- You run a web agency or host and look after client sites that might use DebugBear.
If your site does not load anything from DebugBear, this notice does not apply to you, though the lesson about outside scripts does.
What to do now
Do these today.
- Check if you use it. Ask your developer to search your site's templates, plugins and tag manager for "debugbear." A site loads the script with a line that points to cdn.debugbear[.]com.
- Remove the DebugBear RUM embed code. DebugBear asked its RUM customers to do this. Take it out of every page and out of any tag manager. Our advice is to leave it out until DebugBear says it is safe. DebugBear has not said when that will be. (DebugBear on X, 2:00 PM ET)
- Review the outside scripts on your login, account and checkout pages. Ask your developer for a list of every script those pages load, including ones that other scripts load. For each, ask who runs it, why it is there and whether you still need it. Remove what you do not need. A performance monitor does not need to act on behalf of a logged-in user. This is our advice, not DebugBear's.
- If those pages loaded DebugBear's script, ask your developer to look at account and payment activity from October 29 and talk to your payment provider about anything unusual. We have no report that your site was affected. This is our advice.
- Watch for DebugBear's updates. It said it will post them on X. Do not add the script back until it says it is safe. (DebugBear on X, 6:16 PM ET)
What to send your developer or agency
DebugBear says it is impacted by an ongoing security incident and has asked customers of its real user monitoring (RUM) product to remove the embed code from their websites. On October 29, 2026, a malicious script served from DebugBear's network was used against logged-in Polymarket sessions, according to BleepingComputer, SecurityWeek and Hudson Rock. Please tell us whether any of our sites load DebugBear (cdn.debugbear[.]com or data.debugbear[.]com), and remove the embed code from every page and tag manager until DebugBear says it is safe. Please also list every third-party script on our login, account and checkout pages, remove any we do not need, and check account and payment activity from October 29 if those pages loaded DebugBear. Sources: BleepingComputer, SecurityWeek.
Common questions
Has my site been hacked?
This notice does not mean your site has been hacked. It means a script supplier had a security incident. Polymarket is the only company reported as affected, and we do not claim any other business was. If your site never loaded DebugBear's script, it did not receive this code.
Can EverThread tell me if I am affected?
No. EverThread has no check for this incident and does not claim to detect it. Here is what we do look at. Our free scan opens your home page the way a browser does and runs a checklist for common problems. On Starter, Pro and Agency plans we open more pages, up to 50, 100 or 500 depending on the plan, and record the scripts and forms they load. We never log in, so we do not check pages behind a login, and this attack targeted logged-in sessions. A script that loads only on your account or checkout pages may be invisible to us. A clean EverThread result does not mean your login or checkout pages are clean.
Is there a patch?
No. This is not a flaw in your website's software and it has no CVE number that we know of. The problem was in the script DebugBear served, so the only step for customers is the one DebugBear gave: remove the embed code.
Is this like the Convertr notice?
The lesson is the same: a script from outside your own site can run in your visitors' browsers, so you have to trust whoever controls it. In our Convertr notice, security firm Sansec reported card-stealing code hidden in an analytics script on a checkout platform. These are different companies and different incidents.
Where can I follow official updates?
DebugBear said it will post updates on its X account. All current notices are on our notices page.
Security alerts by email
Hear about the next one first.
When a flaw puts websites at risk, we send one plain-English email: what happened, who it affects and what to do. It's free, whether or not you use EverThread.
Sources
- BleepingComputer: Polymarket halts trading after crypto-draining script breach, $2.5M traced, October 29, 2026
- SecurityWeek: $2 Million+ Drained From Polymarket Traders in New Supply Chain Attack, October 30, 2026
- Hudson Rock: Polymarket Breach Alert: Wallet-Draining Code Found in a Third-Party Script, October 29, 2026
- DebugBear: post on X, October 29, 2026, about 2:00 PM ET
- DebugBear: post on X, October 29, 2026, about 6:16 PM ET
All sources checked October 30, 2026. DebugBear's own website was not reachable when we checked.