A script on your website was hacked. Here's how to check, and what to do.
On 29 October 2026, DebugBear, a company that measures how fast websites load, said it had a security incident and asked everyone using its RUM script to remove the embed code from their websites. Polymarket, a prediction market, paused trading the same day after users reported losing funds, and researchers link that to the DebugBear script. If you ever pasted a DebugBear code into your site, check today. The same steps work for any outside script you've added.
What we know, and what we don't.
Many websites load small pieces of code from other companies: a speed monitor, a chat box, reviews, analytics, a popup. You paste an embed code once, and from then on every visitor's browser fetches the script from that company's server. If the company is breached, the code your visitors get can change, even though nobody touched your website.
That is what happened here. What is known so far:
- Confirmed: DebugBear said on 29 October 2026, at 18:00 UTC, that it was hit by a security incident, and told everyone using its RUM script to remove the embed code from their websites.
- Confirmed: Polymarket, a prediction market, said a third-party provider was compromised and paused trading. Users reported funds leaving their accounts.
- Confirmed: trading on Polymarket came back about an hour after the halt, and Polymarket says affected traders will be fully repaid. This is reported by CNBC and Reuters.
- Confirmed: the case has been referred to UK law enforcement, according to CNBC and Reuters. DebugBear is based in the UK.
- Likely, reported by researchers and the press: the compromised provider was DebugBear's script, and code in it sold users' open positions and sent the money to the attacker. This comes from Hudson Rock (quoted by Decrypt and BleepingComputer), BNO News, and a person familiar with the matter quoted by CNBC and Reuters. Neither company has officially named the other.
- Likely, one data source: at least $2.7 million was withdrawn across 710 wallets, based on Betting Intelligence and Polysights data given to CNBC. Separately, a wallet linked to the attacker held about $2.65 million, based on Arkham data cited by Decrypt and The Block. Polymarket has not published an official loss figure or a count of affected traders, and reports differ.
- Likely, one source: repayments under $10,000 were due to be restored by 30 October, and larger amounts need a release form. This comes from Polymarket's Discord, as reported by CNBC.
- Unknown: how DebugBear was breached, and whether the script did harm on any other website. Nobody has published either yet.
We'll update this page the same day DebugBear publishes its own write-up.
Three checks, about five minutes.
These work on any platform. Do them on a computer, in Chrome or Edge.
Search the page source
Open your homepage. Press Ctrl+U (Cmd+Option+U on a Mac) to see the page source, then Ctrl+F (Cmd+F) and search for debugbear. Do the same on your checkout or booking page if you have one.
Search what actually loads
Some scripts are added later by a tag manager, so they don't show in the source. Press F12, open the Network tab, reload the page and type debugbear in the filter box. Nothing listed means nothing loaded.
Check your tag manager
If you use Google Tag Manager, open your container and look through the tags for DebugBear or any custom HTML tag you don't recognise. Ask whoever set it up if you're unsure.
If none of the three finds it, this incident didn't run on your site. Keep reading anyway: the same checks work for every outside script you've added.
Where to look on your platform.
Found it in the source but don't know where it was added? These are the usual places. Menu names change over time, so look for the nearest match.
| Platform | Where pasted code usually lives |
|---|---|
| WordPress | A "header and footer code" plugin, your theme's settings, or the theme's header file. Some plugins add scripts on their own, so check your plugin list too. |
| Shopify | Your theme's code (usually the theme.liquid file), custom pixels under customer events in Settings, and installed apps. |
| Wix | Custom code in your site settings, and any embed or HTML element on a page. |
| Squarespace | Code injection (site-wide or per page), and any code block on a page. |
| Webflow | Custom code in site settings, custom code in each page's settings, and embed elements. |
| GoDaddy website builder | Any HTML section added in the page editor. |
| Joomla | Your template's files, custom HTML modules, and extensions that add code to every page. |
| Drupal | Your theme's template files, custom blocks, and modules that add code to every page. |
What to do today.
Do these in order. The first one matters most.
Remove the embed code
Delete the DebugBear code from wherever it was added, as DebugBear has asked. Your website works without it: a speed monitor only measures your pages.
Clear your caches
If you use a cache plugin or a CDN such as Cloudflare, clear it, so old copies of your pages stop loading the script. Then run the three checks again.
Write down the dates
Note when the script was on your site and which pages loaded it. If visitors paid, logged in or connected a wallet on those pages, talk to your payment provider about what to do next.
What the harmful code did on other websites isn't known yet. Don't assume it was harmless, and don't assume the worst. Remove it, keep your notes, and watch for DebugBear's write-up.
Every other script on your site
This won't be the last time a script company is breached. Each outside script is a company you trust with every visitor.
- Make a list of every outside script your site loads, using the checks above.
- Remove what you don't use. Old trials, tools from a past agency, a chat box you replaced.
- Keep scripts off payment and login pages unless they're needed there.
- Know who added each one, so you know who to ask when a company reports a problem.
If your website itself was hacked
A hijacked outside script is different from a hacked website. If you see changes you didn't make, new admin users, or your visitors are sent to other sites, see what to do when your website is hacked. For keeping your site safe week to week, see website security.
If you'd rather someone else kept an eye on this, we look after small business websites in the US, UK, Canada and Australia, including the scripts they load. Your first fix is free. Then from $100 a month. Start a chat or message us on WhatsApp +92 326 2326191.
Is my website affected by the DebugBear incident?
Only if your website loads DebugBear's RUM script. Open your site in Chrome, view the page source and search for 'debugbear', then check your tag manager too. If it isn't there, this incident didn't run on your site. If it is, remove it today, as DebugBear has asked.
My website wasn't hacked. How could a script on it be?
A pasted embed code doesn't copy the script onto your site. It tells every visitor's browser to fetch the script from the other company's server, on every visit. If that company is breached, the code your visitors get can change without anyone touching your website.
Is removing the script enough?
It stops the script loading on new visits. Also clear any cache plugin or CDN, so old copies of your pages stop serving it, and note the dates it was on your site. If visitors paid or logged in on those pages, talk to your payment provider about what to do next.
How did DebugBear get breached, and how many sites were hit?
Neither is known yet. DebugBear has not said how it was breached, and nobody has published a count of affected websites. We will update this page when DebugBear publishes its own write-up.
Can I put the DebugBear script back?
Not until DebugBear says it is safe. As of 30 October 2026, its advice is to remove the embed code. Your website works without it: a speed monitor only measures your pages, it doesn't run them.
Related pages.
Sources for this page
- DebugBear on X: security incident notice, 29 October 2026
- Decrypt: Polymarket pauses trading after security incident
- CoinDesk: Polymarket suspends trading after third-party breach leads to user losses
- The Block: Polymarket exploit, cancel-only mode
- BNO News: some Polymarket users report losing funds after security breach
- BeInCrypto: Polymarket halts trading after users drained
- CNBC: Polymarket reports outage on international exchange, halts trading
- Reuters report (via Financial Newsletter): Polymarket resumes trading
- BleepingComputer: Polymarket halts trading after crypto-draining script breach