Malicious code on the website of prediction market Polymarket sold some signed-in traders' positions and moved their funds to the hackers on October 29. Polymarket says it is refunding about $2.7 million to 726 affected wallets. The code was delivered through a script from monitoring vendor DebugBear, whose DNS records were compromised through its domain registrar, the company said on X.
What happened
The affected users were already signed in, so the code acted with the trust the site had already established in the browser. It sold positions and sent the proceeds to a wallet controlled by the attackers. Polymarket is also paying $1.19 million to about 5,500 wallets that lost money during the trading pause or had positions taken.
The wallet written into the code received its first funds at 17:10 UTC and its last at 18:02 UTC, according to Ohey's blockchain trace. In that time, it collected 28.6 million POL tokens and positions from 33 wallets.
How it was done
DebugBear's DNS records were compromised through its domain registrar, the company said on X. Control of the records is enough to point a script hostname at infrastructure the attackers run. Any site loading that script then fetches attacker-supplied code from what looks like the normal vendor domain, with no change to the first party's own deployment.
The wallet address was written into the code, and the collection window was short. That pattern puts the exposure window on the vendor's side of the boundary, not on the release that a product team shipped.
What to check
If your front end loads vendor scripts on pages where users are signed in or sign transactions, work through the following.
Inventory every third-party script on authenticated pages
Open a signed-in page in a browser and read the network panel, filtered to scripts, then compare that list to what your repository declares. Anything loaded by another vendor's tag, rather than by your own HTML, is the part most teams miss. A hostname nobody on the team can name is a bad result.
Pin third-party code with subresource integrity
Add integrity and crossorigin attributes to every external script tag you control, and fail the build if a tag lacks them. Generate the hash with openssl dgst -sha384 -binary file.js | openssl base64 -A. If a vendor refuses to serve versioned, immutable files, treat that as a gap to document.
Lock registrar and DNS for your own domains
In your registrar console, confirm the transfer lock and registrar lock are on, that DNSSEC is enabled, and that the account uses phishing-resistant multi-factor authentication. Check who holds the login and whether a shared mailbox can reset it. A single shared password with SMS recovery is the result to fix first.
Alert on DNS record changes for vendor and self hostnames
Run scheduled resolution of each script hostname with dig +short and diff the answer against a stored baseline, alerting on any change to A, AAAA, CNAME or NS. Include vendor hostnames, not just your own. An unannounced change in name servers or hosting provider warrants a hold on the script.
Restrict script sources with a content security policy
Deploy a Content-Security-Policy header with an explicit script-src allowlist and no wildcard, then review report-uri output for blocked loads. Run it in report-only mode first to find what breaks. Reports for domains you never approved are the signal to act on.
Review what a compromised front end could sign for a user
Trace the flow from a signed-in session to a value-moving action and note every step that happens without a fresh, explicit user confirmation. Check session lifetimes and whether approvals are scoped and bounded. Any path where page code alone can move funds is worth a second control.