If your site loads a script from DebugBear, a Core Web Vitals monitoring service, remove it today. On October 29, 2026, a DebugBear script URL used by the prediction market Polymarket served malicious JavaScript, and DebugBear told customers to take its real user monitoring (RUM) script off their sites.
What changed
Polymarket's status page says a third-party vendor whose performance-monitoring script loaded on polymarket.com was compromised, and that the attacker replaced the script with one built to target Polymarket users. For some people who had the site open during a short window, it used their active session to sell positions and move funds out of their wallets. Polymarket reported on October 30 that 95% of affected wallets had been refunded.
Security firm Hudson Rock retrieved the file from a DebugBear URL on October 29 and described code that looks for a logged-in user's trading client and tries to sell or transfer assets. That logic was specific to Polymarket.
According to Search Engine Journal's account of DebugBear's updates, attackers got in by changing DNS records through the company's domain registrar. DebugBear said its first look showed the attack targeted one customer's website and that it saw no sign its internal systems were breached. We could not open DebugBear's own posts, so treat those details as reported, not confirmed. It is also not yet clear whether other customers received malicious code.
What it means for your business
A monitoring script is not harmless decoration. It runs inside your pages with the same access as your own code. If it is swapped for something hostile, it can read what a logged-in visitor can see and act as that visitor. The Polymarket code targeted one company, but nothing about the method is limited to one site.
Removing the tag stops new page loads from fetching the script. It does not undo anything that already happened, and it does not log out visitors whose sessions were exposed.
What to do now
- Search your templates, plugins and tag manager for any
cdn.debugbear.comscript and remove it. Clear page caches and confirm the script no longer loads in your browser's network tab. - If you run a login, checkout or admin area, reset sessions and passwords for admins first, then customers if you can. A password change alone may not end old sessions.
- Review logs and settings for the period the script was live: new user accounts, permission changes, edited templates or plugins, tag manager history, and unexpected orders or payouts.
- If you find real signs of tampering, take the site offline behind a static maintenance page, restore from a known clean backup, and re-check before reopening.
- List every other third-party script on your key pages. Remove what you do not need, and ask your developer about a Content Security Policy that limits where scripts can load from. Shopify store owners with third-party apps should also read our note on the Shopify token deadline.
The details
Polymarket said its fixes include removing the vendor script, clearing caches, resetting all active login sessions, and adding integrity controls such as a stronger Content Security Policy and explicit version pinning for third-party scripts.
If you want a second pair of eyes on what loads on your pages, our free SEO audit lists the scripts it finds, and our web development team can help you clean up the rest.