CybersecurityWebsites

How to Check the Third-Party Scripts Running on Your Business Website

A swapped page-speed script drained about $2.7 million from Polymarket users on Oct. 29. How a small business lists, trims and locks outside code on its site.

By Cybercave Technologies, LLC · Nov 1, 2026

Close-up of a computer monitor showing colorful lines of program code on a dark background — Program code on a monitor. Illustration only, not code from any company named here. Credit: Photo by Nemuel Sereti via Pexels (Pexels License).

Short answer: Make a list of every piece of outside code your website loads, remove what you no longer use, and keep the rest off your login, checkout and payment pages. On Oct. 29, 2026, a page-speed script that Polymarket loaded from another company was swapped for code that drained about $2.7 million from users who were signed in.

Key points

On Oct. 29, a performance-monitoring script that the prediction market Polymarket loaded from an outside vendor was replaced with code that used visitors' open sessions to sell their positions and move their funds, Polymarket said in its incident report.
The script came from DebugBear, a website speed-monitoring service, according to BleepingComputer and The Hacker News, both citing researchers at Hudson Rock. DebugBear told customers of its monitoring product to remove its code from their websites.
As of Oct. 30, Polymarket said it was returning $3.9 million to traders: $2.7 million taken in the attack plus $1.2 million for losses during its trading pause. CNBC reported that two analytics firms counted at least $2.7 million withdrawn.
DebugBear said its DNS records were changed through its domain registrar and that the attack targeted one customer's site, Search Engine Journal and The Hacker News reported. As of Nov. 1, 2026, DebugBear hadn't said how the change was made.

What to do this week: open your website's main pages and your checkout or contact form, write down every outside service whose code loads there, and delete anything nobody at your business can explain.

What happened in the Oct. 29 script swap?

Polymarket's website loaded a small file from DebugBear that measured how fast pages loaded for real visitors. On Oct. 29 that file was replaced. The new code looked for visitors who were already signed in, then used the access their open browser session already had to sell positions and send money to the attacker, Polymarket and BleepingComputer said. It didn't need anyone's password.

A blockchain trace by the research site Ohey found the swapped file ran from about 12:54 p.m. to 1:59 p.m. Eastern, when Polymarket shipped a version of its site without the script. Polymarket said it paused trading, cleared its caches, reset every active login session and referred the case to law enforcement. CNBC reported that Polymarket's U.S. platform wasn't affected.

Polymarket put the number of affected wallets at 726, The Hacker News reported, and said on Oct. 30 that 95% of them had been refunded in full. We're reporting what each company has said; how the attacker changed DebugBear's DNS settings hadn't been made public as of Nov. 1.

Why should a small business website care?

Because much of what a typical small business website does comes from code the business didn't write. Analytics tags, chat bubbles, booking calendars, review carousels and ad pixels each load a file from another company's server. As the Polymarket case showed, that code runs inside your page with the same access a signed-in visitor has.

Mozilla's developer documentation describes the risk plainly: if an attacker gains control of the outside server, it can change the file or replace it, and every site that loads it gets the new version. That's called a supply chain attack.

Our example (hypothetical): a Kalamazoo boutique's online store loads a chat widget, a review carousel and two analytics tags on every page, including checkout. If any one of those vendors were taken over, the swapped code would run on the checkout page too, where customers type card numbers and sign-in details.

How do I check the scripts on my website?

Start with a list, then cut, then protect what's left. Most of it can be done in an afternoon with whoever manages your site.

List every outside script. Check your site builder's "custom code" or "tracking" settings, your plugins and any tag manager account, as Search Engine Journal advised DebugBear customers. Next to each one, write which company it comes from, what it does and who at your business asked for it.
Remove what you don't use. Old trial tools, a chat service you cancelled and duplicate analytics tags are all code that can still run. Hudson Rock's advice, as reported by The Hacker News, is to keep unneeded third-party code off the pages where users make transactions.
Keep sensitive pages clean. Your login, checkout, payment and account pages should load as little outside code as possible. If your card payments run in your processor's hosted page or payment window, keep it that way.
Lock files you can pin. Subresource Integrity lets your page carry a fingerprint (a "hash") of the exact file it expects; if the file changes, the browser refuses to run it, MDN explains. It only fits files that stay the same, such as a specific version of a library, so ask the vendor whether it offers versioned files.
Don't rely on an allow-list alone. A Content Security Policy tells browsers which outside servers your pages may load code from. It helps, but Ohey found every server the swapped code contacted, other than DebugBear's own, was already on Polymarket's list, and Hudson Rock noted that allowing a trusted server doesn't check the files it sends.
Know your vendors' alert channel. DebugBear's warning went out on its X account. Make sure someone at your business gets security notices from each script vendor, and write down how to remove each script quickly.

What if a vendor tells me to remove its code?

Take it out everywhere it loads: templates, plugins and tag managers. Then clear your site's cache and confirm it's gone, Search Engine Journal advised. If the script ran on pages where people sign in, reset those sessions and passwords, starting with administrator accounts, as Polymarket did. Removing the code stops new damage but doesn't undo anything that already happened, so review recent logins, new accounts and site changes from the time it was active.

Does this matter if I take credit cards online?

Yes. Since March 31, 2025, the card industry's security standard, PCI DSS 4.0.1, requires that every script on a payment page be approved, verified as unaltered and watched for tampering, the PCI Security Standards Council said. The Council removed those two requirements from its shortest self-assessment form (SAQ A, for merchants that fully outsource card handling), but those merchants must confirm their site isn't open to script attacks. The Council says they can get that confirmation from the PCI-compliant provider of their embedded payment form.

What should you tell your IT provider?

Ask for four things in writing: a list of every third-party script on your site with the page it loads on and the reason it's there; confirmation that login, checkout and payment pages load only what they must; which scripts use Subresource Integrity or pinned versions; and the steps and contact to remove any one script within the hour if its vendor reports a problem.

What should you do this week?

Make the list. Open your site's settings and tag manager, write down every outside script, and delete the ones nobody can explain. If you take payments on your own pages, ask your payment processor what it needs from you on scripts.

For more, see our guides to locking down your business domain, what to ask when an analytics vendor is breached, and checking the tools your IT helper relies on.

FAQ

What is a third-party script? It's code your website loads from another company's server, such as an analytics tag, chat widget or booking calendar. Visitors' browsers run it as part of your page.

Was DebugBear hacked? DebugBear said someone altered its DNS records by way of its domain registrar and that it had seen no sign its internal systems were breached, though it was still investigating as of Nov. 1, 2026.

Does an analytics tag really need to be on my checkout page? Often not. Ask whoever set it up what it measures there; if the answer isn't worth the risk, take it off that page.

Will a security plugin catch a swapped script? Not necessarily. The file lives on the vendor's server, not yours, so a scan of your own site files may not see it change. Integrity checks and tamper monitoring, the controls the PCI Council describes for payment pages, are what catch it.

Disclosure: No company named in this article paid for it, reviewed it or saw it before publication. Hudson Rock is a security research company and Ohey publishes security research. Details are as published by each source and were checked on Nov. 1, 2026. Not sponsored.