Polymarket halted trading on its international site for about an hour on 29 October 2026. The company said one of its third-party providers was compromised, referred the case to law enforcement and promised to make every affected user whole. Traders had reported unauthorized withdrawals on social media, CNBC reported. Polymarket has not named the provider or published a loss figure.
On what is known so far, the Polymarket hack fits the pattern of a front-end supply chain attack. In that pattern, code a vendor supplies runs on the trading page with each user’s own session. This post explains how that works, what is confirmed, and which controls limit the damage.
What Polymarket Has Confirmed So Far
The Polymarket status page logs the incident in UTC. At 18:05 the exchange went into cancel-only mode and relayer actions paused. At 18:37 the company said it had identified and fixed the issue on Polymarket.com. The record marks a one-hour major outage for its trading API.
Trading came back at about 19:00 UTC, or 3 p.m. Eastern. In a post on X, Polymarket said it is “fully reimbursing all affected traders.” The status page marked the incident resolved at 19:05 UTC.
Some details come only from press reports. CNBC reported that analytics firms counted at least $2.7 million withdrawn across 710 wallets. NBC News reported that Polymarket said the attack appeared to come from the United Kingdom. It also reported a referral to British authorities. Polymarket’s own posts say only “relevant law enforcement.”
What a Front-End Supply Chain Attack Is
Most websites load code they did not write: analytics tags, chat widgets, performance monitors. Each tag runs in the visitor’s browser with the same rights as the site’s own code. The OWASP cheat sheet on third-party JavaScript calls a compromise of the vendor’s script server “the single greatest risk” of these tags.
When that happens, the attacker does not need to break into the site. They change the file the site already trusts, and every visitor runs the new version. This is a supply chain attack aimed at the browser. In MITRE terms it is a compromise of the software supply chain, listed in ATT&CK as T1195.002.
- Vendor script hostVendorserves a changed file
- Trading page loads the tagWebsiteruns in the user’s session
- Logged-in traderBrowseris asked to sign
- Wallet transferBlockchain
On a trading or crypto site, the user’s session is worth money. Code with access to the page can see balances, place orders or ask the wallet to sign a transfer. A signed transfer on a public blockchain cannot be reversed by the site. Drainer kits are built around this step: our Angel Drainer report describes a malicious JavaScript file that links the victim’s wallet and moves assets out.
Why the June Incident Matters
This is not the first time for Polymarket. On 25 June 2026 the company said a third-party vendor had been compromised, “injecting a malicious script into our frontend for some users.” It removed the affected dependency and promised full refunds. The October statements do not say what the provider supplied, so the two cases cannot yet be compared in detail.
Press reports on 29 October tied the theft to a monitoring script loaded on the trading site. Polymarket has not confirmed that detail. Still, two vendor compromises in four months show where the exposure sits: in code that runs next to the trading and signing flow.
Crypto has seen the pattern before at a far larger scale. In the Bybit theft of February 2025, Bybit says attackers reached its wallet provider’s infrastructure and tricked signers into approving a malicious transaction.
What the Early Warning Signs Looked Like
Traders saw the problem before the status page did. Brandefense Blackhole, our cybercrime database, logged the first Telegram reports of a possible front-end compromise at 17:49 UTC, 16 minutes before Polymarket’s first status update. At 18:02 a Russian-language channel told users not to visit the site because a transaction prompt would drain their funds.
- Polymarket status pageYesCancel-only mode at 18:05 UTC, one-hour trading API outage, resolved 19:05 UTC.2026-10-29
- Provider named by PolymarketUnknownPolymarket says only that a third-party provider was compromised.2026-10-29
- Total loss from PolymarketUnknownNo figure published. Press reports cite on-chain estimates of about $2.65 million to at least $2.7 million.2026-10-30
- Brandefense BlackholeYesAbout 60 incident posts in more than 50 Telegram channels from 17:49 UTC on 29 October to 10:30 UTC on 30 October, most of them in Russian. Mostly relayed news and warnings, not verified.2026-10-30
- X discussionYes152 posts in nine languages in a capped sample from 07:00 to 10:59 UTC on 30 October.2026-10-30
The chatter mostly repeated warnings and news. Several channels told users not to connect wallets or sign anything on the site. These are user reports, and we have not verified them. They match the pattern above, where the danger sits in a prompt the user approves.
Which Controls Limit a Tampered Script
No single control stops this attack, but four ideas cover most of the gap. They work best together.
- Subresource IntegrityThe browser checks a file’s hash and refuses to run it if the contents changed.
- Content Security PolicyA header that limits which sources may load scripts and where pages may send data.
- Third-party riskThe exposure a company inherits from vendors that can reach its users, data or systems.
- Supply chain attackAn attack that tampers with software or services before the victim uses them.
Subresource Integrity is the direct answer to a changed file. MDN warns that an attacker who controls a third-party host can “inject arbitrary malicious content into its files.” With an integrity hash in place, the browser will “refuse to load the resource” when the bytes differ.
The catch is that many vendor tags change often by design, so a fixed hash breaks them. OWASP suggests mirroring the script in-house and reviewing each update before it ships. Where that is not possible, keep the tag off pages that handle logins, orders or wallet signatures.
A Content Security Policy narrows which hosts can run code and receive data. It trusts a host, though, not a file. If the approved vendor host is the one compromised, the policy lets the bad script through. Pair it with integrity checks and with a newer Integrity-Policy header, which MDN describes as blocking scripts loaded without integrity metadata.
Questions to Ask Before the Next Vendor Breach
Treat front-end tags as part of your supply chain and vendor risk program, not as a marketing detail. Start with these questions:
- Which third-party scripts load on pages where users log in, trade, pay or sign?
- Who can change each script, and would you notice a change within minutes?
- Can each tag be pinned with a hash or served from your own servers?
- Can you remove a tag from production in one step during an incident?
- Does each vendor’s contract require fast breach notice?
For traders, the advice is simpler. Approve only transactions you started, and read what a wallet prompt asks you to sign. Polymarket says affected users will be refunded, so watch its official channels and ignore “recovery” offers from strangers.