A hijacked DebugBear RUM script drained Polymarket traders; here's how to find and remove third-party scripts on your clients' websites.
A script whose only job was to time how fast Polymarket's pages loaded spent 52 minutes on October 29 selling traders' positions and sending the money to an attacker. Nobody broke into Polymarket's servers. The attacker changed one file that Polymarket's site trusted, and every logged-in trader's browser did the rest.
Attackers replaced the DebugBear script that Polymarket loaded on its trading pages with a wallet drainer, and it ran inside traders' open sessions. DebugBear sells RUM, a small piece of JavaScript that measures page speed for real visitors. Polymarket loaded it from cdn.debugbear.com.
The Hacker News reported that the attacker wallet received its first funds at 17:10 UTC and its last at 18:02 UTC. According to The Hacker News, DebugBear said on X that its DNS records were compromised through its domain registrar, and that early findings point at one customer's website. Its own site returned errors when we tried to fetch it, so that account comes second-hand.
Ohey found that "a different server was answering for both DebugBear hostnames" during the attack. DefiPrime notes that the drainer file's CDN timestamp reads October 27, which may mean the code was ready two days early.
The script used the access a signed-in trader already had. Hudson Rock's analysis shows it read three keys Polymarket keeps in the browser's local storage, including poly_clob_api_key_map. It then searched the page for Polymarket's own order-placing code and its signer, the component that approves transactions.
data.debugbear.com, per BleepingComputer.Think of it as a cleaner with a master key. The building checked the cleaner's badge at the door, not what they did inside. Hudson Rock puts it plainly: "simply allowing a trusted CDN does not verify the bytes it serves."
Nobody has published evidence that other sites received a malicious file. Ohey found that the drainer targets Polymarket alone and was served for Polymarket's snippet key, C7xcKKrjUnXK. But DebugBear told every RUM customer, per BleepingComputer: "If you use our RUM product, please remove the embed code from your website."
For an MSP, that makes this a fleet job. RUM and page-speed tools are exactly what agencies and IT providers add to client sites, and nobody remembers them once they are in.
Put every client URL in client-urls.txt, one per line, including login and checkout pages. Then work through this list in order.
D="$HOME/evidence/debugbear-$(date +%F)"; mkdir -p "$D"
while read -r url; do
curl -sL --max-time 20 "$url" -o "$D/$(printf '%s' "$url" | tr -c 'A-Za-z0-9' '_').html"
done < client-urls.txt
sudo find "$D" -type f -exec sha256sum {} + | sudo tee "$D.sha256"
while read -r url; do
page=$(curl -sL --max-time 20 "$url")
hits=$(printf '%s' "$page" | grep -oiE '[a-z0-9.-]*debugbear\.com[^"'"'"' ]*' | sort -u | tr '\n' ' ')
for gtm in $(printf '%s' "$page" | grep -oE 'GTM-[A-Z0-9]+' | sort -u); do
curl -s "https://www.googletagmanager.com/gtm.js?id=$gtm" | grep -qi debugbear && hits="$hits GTM:$gtm"
done
[ -n "$hits" ] && echo "$url $hits"
done < client-urls.txt
db search against every WordPress install it finds, where header-injection plugins store snippets:sudo grep -rIil 'debugbear' /var/www /srv /home 2>/dev/null
sudo find /var/www /srv /home -name wp-config.php -printf '%h\n' 2>/dev/null |
while read -r wp; do echo "== $wp"; sudo wp db search debugbear --all-tables --path="$wp" --allow-root; done
debugbear.com from each Content Security Policy. Delete the snippet from the template, plugin setting or GTM tag that steps 2 and 3 found. Then rerun steps 2 and 3, run this header check, and confirm all three print nothing:while read -r url; do
curl -sIL --max-time 20 "$url" | grep -i '^content-security-policy' | grep -qi debugbear && echo "$url CSP"
done < client-urls.txt
integrity="sha384-<output>" and crossorigin="anonymous" to its script tag. Confirm it with the second line, which must print the tag:cat vendor.js | openssl dgst -sha384 -binary | openssl base64 -A
curl -sL "https://client.example/login" | grep -oiE '<script[^>]+integrity="sha384-[^"]+"'
Scripts that change without notice, like most RUM snippets, can't be pinned. Keep those off pages where people log in, pay or sign.
while read -r url; do
curl -sL --max-time 20 "$url" | grep -oiE '<script[^>]+src="https?://[^/"]+' \
| sed -E 's#.*src="https?://##' | sort -u | sed "s|^|$url |"
done < client-urls.txt
This sees only the HTML the server sends. For scripts a tag manager adds or that load after login, open Chrome DevTools > Network, filter by JS while logged in, and check the domain column.
A pentest can't see inside a vendor's registrar account, and we won't pretend it can. What it can find are the weaknesses that turned one bad file into theft: session tokens any script can read, a missing or loose Content Security Policy, and injection flaws that let attacker JavaScript run on a client's page without hijacking anyone.
KinoSec runs autonomous pentests of your clients' web apps on demand: reconnaissance, finding vulnerabilities, chaining them as an attacker would, and writing up each finding with remediation. You can run it across every client you manage, before an attacker finds the soft spot, and hand each client a report they can act on.
On October 29, 2026, attackers swapped the DebugBear real user monitoring script on Polymarket's site for a wallet drainer. According to The Hacker News, the attacker wallet received funds between 17:10 UTC and 18:02 UTC, and Polymarket is refunding about $2.7 million to 726 wallets. Polymarket says it returned $3.9M in total, including $1.2M for losses during the trading pause.
Nobody has published evidence that other sites received a malicious file. Ohey found that the drainer targets Polymarket alone and was served for Polymarket's snippet key. DebugBear still told every RUM customer, per BleepingComputer: "If you use our RUM product, please remove the embed code from your website."
First, search the web roots you host with sudo grep -rIil 'debugbear' /var/www /srv /home. Second, run the body's step 3 loop, which runs wp db search debugbear --all-tables on every WordPress install it finds. Third, run the body's step 2 loop over client-urls.txt; it prints every URL that references DebugBear, including inside Google Tag Manager containers.
Only for a file that can be pinned. Hudson Rock recommends SRI where a file can be pinned, so the browser rejects changed content, and notes that "simply allowing a trusted CDN does not verify the bytes it serves." Scripts that change without notice, like most RUM snippets, should stay off pages where people log in, pay or sign.