If your site loads DebugBear’s Real User Monitoring script to track Core Web Vitals, remove it now. DebugBear issued that instruction on October 29 after attackers compromised its DNS records through the domain registrar.
This is a classic supply-chain problem, not a flaw in your own code. A third-party tag you trusted suddenly acts with the permissions of every signed-in visitor on your domain.
What happened
DebugBear’s initial investigation indicated the attack targeted one customer’s website, and the company reported no sign that its internal systems were compromised. In a follow-up update, DebugBear also said it could not receive email sent to its domain while it worked on the incident.
Cybersecurity firm Hudson Rock found malicious JavaScript at a DebugBear script URL used by Polymarket on October 29. The code looked for the trading client already available in a logged-in browser. Polymarket’s October 30 incident report confirmed that the script sold positions and moved funds from some users’ wallets. It did not need passwords; it simply used the access a signed-in visitor already had.
Why this matters for every site owner
Monitoring tags, analytics pixels and consent scripts all execute in your visitors’ sessions. When one is hijacked, the attacker inherits whatever that session can do. The Polymarket case shows the worst version: high-value accounts, no credentials required, and financial impact before a site owner notices.
Removing the tag stops new loads. It does not reverse unauthorized actions, and it does not remove anything an attacker may already have planted while the script was active.
What SEO and site owners should do now
Have development and security teams run this sequence. The first step is urgent even if you only suspect exposure.
- Remove the DebugBear RUM embed immediately. Check templates, plugins, tag managers and cached pages, then verify the script no longer loads.
- Reset privileged access. Invalidate exposed sessions and reset passwords, starting with administrators. Revoke potentially exposed API credentials and confirm old sessions are rejected.
- Audit for unauthorized changes and persistence. Review account creation, permission changes, tag-manager history, templates, plugins and injected scripts against a clean version.
- Investigate suspicious activity. Look for unusual logins, new accounts, changed files and unexpected transactions while the script was active.
- Isolate a confirmed compromise. Put the site in maintenance mode with a static page and HTTP 503, clean up or restore a known-good backup, and verify no backdoors remain before relaunching.
SEO teams are often the ones who installed the monitoring tag, so they should flag this to developers and security immediately. It is not yet clear whether other DebugBear customers also received malicious code, but the cost of waiting is far higher than the cost of removal.
Source: Search Engine Journal
