Polymarket Third-Party Script Compromise: A Vendor Script Drained About $2.6 Million From Logged-In Users

Polymarket said on October 29, 2026 that one of its third-party providers was compromised, and BleepingComputer reports that crypto-draining JavaScript then ran for logged-in users on polymarket.com. About $2.5 to $2.7 million was traced to attacker wallets. Polymarket put its exchange in cancel-only mode, fixed the issue, resumed trading about an hour later, and says it is reimbursing affected traders.

Researchers and BleepingComputer tie the script to DebugBear, a website performance-monitoring vendor. Polymarket has not named its vendor and DebugBear has not confirmed it was the source. This post keeps what Polymarket said apart from what researchers found.

TL;DR

Timeline (ET, per BleepingComputer and Polymarket)

In cancel-only mode users could cancel orders but no new orders or trades went through. The commit message is notable: it suggests Polymarket removed the vendor script as part of the fix, though Polymarket has not said so.

How the attack worked

According to BleepingComputer's analysis of a copy of the script, which was hosted at a cdn.debugbear[.]com address identified by Hudson Rock:

• It checked whether the visitor was logged in to Polymarket.
• It used the existing session to liquidate prediction-market positions or transfer prediction tokens.
• It converted holdings into transferable assets using Polymarket's own transaction functions.
• It talked to a data.debugbear[.]com endpoint to receive instructions and send back account, wallet, balance and transaction data.

This is the classic third-party script risk: a script loaded on a trusted page runs with the same powers as the site's own code. If the vendor's file changes, every site that loads it changes with it, without a deploy on the customer side.

Polymarket's statement, as quoted by BleepingComputer: "One of our third party providers was compromised, and we have referred this to relevant law enforcement." It also said "Anyone who has been impacted will be made whole."

Confirmed vs claimed

Reports describe the attack as a browser-side drain using logged-in sessions rather than a break of the exchange's contracts. We did not find an official statement that spells this out, so we treat it as the likely mechanism and not a verified fact.

What Polymarket users should do

1. Review your account and wallet for trades, transfers and approvals you did not make since October 29.
2. Trust only official channels. Polymarket's status page and its verified X accounts. Anyone who messages you offering recovery is a scammer.
3. Revoke token approvals you do not need and avoid keeping long-term holdings in a hot trading wallet.
4. Keep records of balances and transactions before the incident for your reimbursement claim.

What website owners should do

If any page that handles logins or payments loads a vendor script, this is the lesson to apply today.

1. Inventory every third-party script on authenticated and checkout-like pages. Remove analytics and session-replay tags from pages that can move money.
2. Use a Content Security Policy that allows only the script origins you need, and restrict where scripts can send data (connect-src). Note that a CSP is weaker if you allow the vendor's own domain.
3. Pin what you can. Subresource Integrity works for files that do not change. For vendor tags that must update, monitor them (hash the file, alert on change).
4. Isolate sensitive actions. Require a fresh confirmation, such as a wallet signature or step-up auth, for actions that move funds, so a script riding a session is not enough.
5. If you use DebugBear, follow its instruction to remove the RUM embed code until it says otherwise.
6. Prepare a kill switch that can remove third-party tags in minutes. Polymarket's reported timeline, from first activity to cancel-only mode, was a matter of minutes, and that speed limited the damage.

For the wider playbook, see your first 24 hours after a vendor breach.

The agent angle

Front-end code that includes a vendor tag is often written or edited with a coding agent today. A script tag added in a pull request looks harmless in review. If your team uses agents on web code, make "adds a third-party script" a review item, and keep credentials out of the files an agent can read. See the October 2026 software supply chain incidents tracker for the month's other cases.

How Beam handles this

Beam is a local-first monitor for AI coding agents. It cannot see a live website, a vendor's CDN or a user's browser, and it would not have stopped this attack. For teams that use agents on front-end code, it can flag when an agent adds new external script sources, reads credential files or runs unexpected commands on a developer machine, so a person can review them.

What we do not know

• Whether DebugBear was breached first, or whether an attacker changed a copy served only to Polymarket.
• How long the malicious script was live before the first transaction.
• How many users were affected and the final loss figure.
• Whether other DebugBear customers were served the same script.
• How reimbursement will work.

We read BleepingComputer and The Block. We did not open the Hudson Rock write-up, Polymarket's status page or DebugBear's post ourselves, and the quoted statements come through BleepingComputer's reporting. Figures and attribution are preliminary.

Related reading

• Binance security incident: compromised DevOps laptop, withdrawals suspended
• Zeabur second breach and shutdown: rotate every secret
• Warp vendor breach: agent traces and telemetry, claimed vs verified
• October 2026 software supply chain incidents tracker
• Your first 24 hours after a vendor breach: a rotation and monitoring runbook
• October 2026 attacks timeline

Primary sources: Polymarket on X · Polymarket status post · DebugBear on X · Reporting: BleepingComputer · The Block

Accurate as of October 30, 2026. This is a developing incident; attribution and loss figures are preliminary.