TL;DR
- DebugBear told customers on LinkedIn on 29 October 2026 to remove its Real User Monitoring embed, Search Engine Journal reported on 31 October 2026.
- DebugBear said attackers compromised its DNS records through its domain registrar, that the attack targeted one customer's website, and that it saw no sign of internal compromise.
- Hudson Rock found malicious JavaScript at a DebugBear script URL used by Polymarket; Polymarket's 30 October report said it sold positions and moved funds from some wallets.
- Exposure duration, number of affected customers and losses were not stated in the coverage.
Attackers hijacked the DNS records of DebugBear, a Real User Monitoring (RUM) tool that many SEO teams use to track Core Web Vitals, and used the company's script address to serve malicious JavaScript, according to Search Engine Journal on 31 October 2026. DebugBear told customers on 29 October to remove its Real User Monitoring embed. Malicious code found at a DebugBear script URL used by the prediction market Polymarket sold positions and moved funds from some users' wallets by riding on the sessions of visitors who were already signed in. Any site that still loads the DebugBear RUM script should remove it and check for unauthorised access. Every site that loads third-party scripts should treat this as a reason to review them.
What happened to DebugBear's monitoring script
As reported by Search Engine Journal, DebugBear published an instruction to customers on LinkedIn on 29 October 2026: remove the DebugBear Real User Monitoring embed. The embed is a single asynchronous script tag that loads a file from cdn.debugbear.com, with a script ID that differs for each site.
In a follow-up update, also on LinkedIn and quoted by SEJ, DebugBear said attackers had compromised its DNS records through its domain registrar. DebugBear said its initial investigation showed that the attack targeted one customer's website, and that it had found no indication its internal systems had been compromised. It also said it could not receive email sent to its own domain. SEJ said customers can follow updates on DebugBear's X account. The registrar was not named in the coverage.
SEJ reported that cybersecurity firm Hudson Rock found malicious JavaScript at a DebugBear script URL used by Polymarket on 29 October. The code looked for the trading client that was already available in a logged-in visitor's browser. According to SEJ, Polymarket's incident report of 30 October confirmed that the script sold positions and moved funds from some users' wallets, using the access a signed-in visitor already had, without needing the user's password.
The incident at a glance
The table below sets out what was reported, by whom and when, as described in SEJ's article.
| Date (2026) | What was reported | Source as cited by SEJ |
|---|---|---|
| 29 October | Customers told to remove the DebugBear RUM embed | DebugBear on LinkedIn |
| 29 October | Malicious JavaScript found at a DebugBear script URL used by Polymarket | Hudson Rock analysis |
| 30 October | Script sold positions and moved funds from some users' wallets | Polymarket incident report |
| Follow-up | DNS records compromised via the registrar; one customer site targeted; no sign of internal compromise | DebugBear on LinkedIn |
What is still unknown
Several important details were not stated in the coverage, and none of them should be assumed:
- How long the malicious code was served.
- How many DebugBear customers loaded the script during that window.
- Whether any site other than Polymarket received malicious code. SEJ said it is not yet clear whether other DebugBear customers did, and that other high-value sites may have been targeted.
- Which DNS records were changed, and how.
- The amount of money lost.
DebugBear's own statement, as quoted by SEJ, is that the attack targeted one customer's website. That is consistent with the Polymarket finding, but it is an initial investigation result, and the full scope was still open when SEJ published.
Why a monitoring tag can do this much damage
A script tag that loads JavaScript from another domain runs with the same power as the site's own code. Once the browser executes it, the script can read and change the page, watch what the visitor types, and send requests to the site's own servers. Those requests carry the visitor's cookies and session automatically, so the server treats them as actions by the logged-in user.
That is the mechanism SEJ describes. The attacker needed their code to run inside a page where a visitor was already signed in, and the trusted monitoring script delivered it.
DNS is the weak link in this chain. A site that includes a script from cdn.example.com trusts whatever server that hostname points to. If an attacker can change where the hostname points, by taking over the registrar account or the DNS records, browsers will fetch the attacker's file from the "correct" address. Nothing about the script tag on the customer's site changes, so nothing looks wrong from the site owner's side.
What sites using DebugBear should do now
SEJ's article lists the steps site owners using DebugBear should take. In summary:
- Remove the embed. Check templates, plugins and tag managers, clear cached pages, and confirm the script no longer loads.
- Invalidate sessions and reset passwords. Start with administrators and privileged users who loaded affected pages, revoke potentially exposed API credentials, and widen the reset if exposure cannot be established. Confirm old sessions are rejected, because changing a password may not end existing sessions.
- Check for unauthorised changes and persistence. Compare account creation, permission changes, tag manager history, templates, plugins and injected scripts against a known clean version, and look for backdoors.
- Review logs. Look for unusual logins, new accounts, changed files and unexpected transactions while the script was active, and reverse confirmed malicious changes.
- Use maintenance mode if compromised. If a compromise is confirmed, isolate the site behind a static maintenance page that returns HTTP 503, clean it or restore a known clean backup, and verify it before relaunching.
SEJ also made a point worth repeating: removing the monitoring tag prevents new loads, but it does not reverse unauthorised actions or remove anything an attacker may already have planted.
Auditing third-party scripts on any site
The general lessons below are standard web security practice. They are not claims about how DebugBear or any other vendor works.
Build an inventory first
List every script that loads from a domain the business does not control, where it is injected (theme file, plugin, tag manager), which pages it runs on, who owns it internally, and whether it is still needed. A crawl or a browser's network panel will find scripts that nobody remembers adding. Tags for tools that were trialled and abandoned are pure risk with no benefit, and an audit is the way to find them.
Limit where scripts run
A performance or behaviour tool rarely needs to run on admin screens, account settings or payment steps. Excluding those templates reduces what a compromised tag could reach. Sampling a measurement tool on public pages often gives the data an SEO team needs without placing it next to logged-in actions.
Subresource Integrity: useful, with a clear limit
Subresource Integrity (SRI) lets a site add an integrity attribute containing a cryptographic hash to a script tag. The browser downloads the file, hashes it, and refuses to run it if the hash does not match. For cross-origin scripts it also needs the crossorigin attribute and a server that sends the right CORS headers.
SRI would block a hijacked file only if the site had pinned the hash of the exact file it expected. The limit is that many vendor scripts, especially per-site embeds loaded from an unversioned URL, are updated in place by the vendor. Each legitimate update changes the hash, and SRI will then block the real script too. In practice SRI fits versioned, immutable files (for example a library at a fixed version number) or a copy the site hosts and reviews itself. It is a poor fit for a tag the vendor expects to change without notice, unless the vendor publishes versioned files and hashes.
A Content Security Policy (CSP) header tells the browser which origins may supply scripts (script-src) and which origins a page may connect to (connect-src). A strict policy stops a site from loading scripts from domains nobody approved, and can limit where injected code is able to send data.
CSP cannot tell a legitimate file from a malicious one if both come from an allowed hostname. In a DNS hijack, the malicious file arrives from the same domain the policy allows. And if malicious code uses the trading client already in the page, as SEJ describes in the Polymarket case, its requests go to endpoints the site itself relies on, which the policy must allow. CSP narrows the attack surface; it does not close this one.
Tag manager governance
Tag managers make it easy to add a script without a code review, which is the point and also the risk. Restrict publish rights to a small group, review custom HTML tags in particular, keep a change log, and check version history regularly for tags nobody recognises. Treat a new third-party tag the way a developer would treat a new code dependency: someone should approve it, and someone should own it.
Protect your own domains the same way
DebugBear said its DNS records were compromised through its domain registrar. Registrar accounts for a company's own domains deserve strong, unique credentials, multi-factor authentication, transfer or registry locks where available, and alerts on DNS changes. DNSSEC protects against forged DNS answers in transit, but it does not protect against someone who has taken over the registrar account itself.
What this means for Thai marketers and site owners
Marketing and measurement tags, such as LINE and social pixels, chat widgets, heatmaps and Core Web Vitals tools for SEO, are code that runs with full access to the page. Teams running SEO audits should add a third-party script inventory to the checklist, with the same weight as crawl errors or page speed, and pass the findings to whoever owns security.
Where personal data or customer accounts are involved, a suspected script compromise is also a data protection question, and the business should follow its own incident process and legal advice. For SEO work more broadly, the lesson is that performance monitoring is still worth doing, but each tool's tag should be scoped to the pages it needs, owned by a named person, and reviewed when it is no longer used. A broader SEO programme can include that review as routine hygiene rather than a one-off reaction.
Frequently asked questions
Should I remove the DebugBear RUM script from my site?
Yes, DebugBear told customers on 29 October 2026 to remove its Real User Monitoring embed, and SEJ repeated that advice. After removing it, follow SEJ's steps: reset sessions and credentials, check for unauthorised changes and review logs.
Was DebugBear itself hacked?
DebugBear said attackers compromised its DNS records through its domain registrar and that it saw no indication its internal systems were compromised, according to its LinkedIn update as quoted by SEJ. The registrar was not named.
How many websites were affected?
That has not been stated. DebugBear's initial investigation said the attack targeted one customer's website, and SEJ said it is not yet clear whether other customers received malicious code.
Would Subresource Integrity have stopped this attack?
Only if the site had pinned the hash of an exact, unchanging file. Many vendor embeds are updated in place at an unversioned URL, so a pinned hash would also block legitimate updates; SRI works best for versioned or self-hosted files.
Does this affect my SEO rankings?
The source did not report any search ranking impact. The risk is to users, accounts and site integrity; removing the script means losing that RUM data until a replacement is in place, and lab tools or field data from other sources can cover the gap.
A third-party script review is a short exercise compared with cleaning up after a compromise. If you want help building a script inventory into your next technical audit, the Relevant Audience team can walk through it with you.
