Events Secure.com at Black Hat USA 2026

Nobody Broke Into Polymarket. They Just Swapped a Script.

A Polymarket supply chain attack turned a trusted vendor script into a wallet drainer and moved $2.5M out before trading stopped.

$2.5M Gone in 55 Minutes: Inside the Polymarket Supply Chain Attack

Polymarket was not breached. Its own code held up fine. A performance monitoring script loaded from somebody else’s CDN did the stealing, and about $2.5 million walked out the door before anyone hit the brakes.

What Happened?

On 29 October, a web performance monitoring file served from a vendor CDN was quietly swapped for a wallet drainer.

It only woke up inside logged-in sessions. It checked the visitor’s geoblock status, read saved login and trading credentials out of browser storage, then reached into the page and borrowed the trading client that already held the user’s signing key. No wallet popup. No approval prompt. The script swapped cash into POL and sent it to a hard-coded address, then moved open positions out in batches. Trading went cancel-only at 18:05 UTC.

Attack chain · 29 October 2026 · UTC

Nobody broke in. A trusted script was swapped.

The platform’s own code was never touched. A performance monitoring file loaded from a vendor CDN was replaced with a wallet drainer, and it ran with every permission the page already had.

16:54Vendor origin starts failingThe CDN edge returns errors for the vendor origin. The first public signal that something is wrong.
17:10First funds reach the attacker walletCash is swapped into POL and sent to a recipient address hard coded in the swapped file.
17:27Drainer caches at a CDN edgeThe malicious file spreads through the content delivery network to more visitors.
17:45Open positions batch transferred25 position transfers in roughly ten minutes, signed through the platform’s own relayer.
17:59Vendor script removed from the buildA release commit strips the monitoring embed, one minute before the vendor goes public.
18:05Exchange moves to cancel onlyTrading is halted and the relayer is paused while the incident is investigated.
19:00Trading fully restoredRoughly 70 minutes from first theft to resumed service. Reimbursement promised.
From first drained wallet to halted trading: about 55 minutes. The detection signal did not come from a security tool. It came from users reporting that their balances had moved.

Why Nothing Blocked It

Here is the uncomfortable part. Every host that script touched was already approved on the site’s content security policy.

The browser did exactly what it was told. It loaded code from a trusted vendor, let that code talk back to the same trusted vendor, and flagged nothing. The drainer even reported each theft to the vendor’s own data endpoint, dressed up as performance metrics. No integrity check was pinned to the file, so swapping its contents cost the attacker nothing.

What’s the Impact?

Roughly 28.6 million POL, about $2.5 million, landed in one wallet and was split across three more within ten minutes. Some publicly reported individual losses run into the hundreds of thousands. The platform promised full reimbursement. The vendor still has not explained how it was breached.

The Part That Should Worry Everyone Else

This was never really a crypto story. It was a tag manager story.

Most commercial sites load somebody else’s JavaScript on pages where users log in: analytics, session replay, chat widgets, performance monitors, ad pixels. Each one runs with the same access as your own code, which makes dependency risk management a frontline control rather than a procurement checkbox. This is the same shape as a hijacked update mechanism, only delivered through a CDN instead of an installer.

The vendor told customers to rip out the embed. Fair as an emergency move, useless as a plan. You cannot remove what you never wrote down, which is why continuous attack surface management has to cover the browser, not just your edge.

Pulling the script and halting trading was the right call, and it looks a lot like what the first hour after a breach should look like.

Indicators of Compromise

Polymarket supply chain attack: published IOCs

Indicators reported by external researchers for the 29 October 2026 vendor script compromise. Hosts are defanged. Both vendor domains stopped resolving the same evening, so hunt retrospectively in archived logs rather than expecting live hits.

Network indicators
Drainerhxxps://cdn.debugbear[.]com/C7xcKKrjUnXK.jsServed in place of the legitimate monitoring script
Confighxxps://data.debugbear[.]com/metrics/init
Exfilhxxps://data.debugbear[.]com/metrics/submit
Exfilhxxps://data.debugbear[.]com/metrics/update
Exfilhxxps://data.debugbear[.]com/metrics/handle
Tracking ID4c6b64a0-a7ef-4c0f-9c70-3a4e6f89065c
File hashes (SHA 256)
Malicious0755e767504d8103f6c27b9e765a1026507a17c04513242adb503df7777879e515,187 bytes. ETag 6ae09e23-3b53
Clean0525f046c83daa429e0f676d36650d51d9e283ba5cacfa56097c80bad586128b60,493 bytes. Legitimate file served until 29 October
Polygon addresses
Recipient0x3F99139F1C5854bb628c2e576Aaf638e99dFfc18Hard coded in the script
Positions0x5a2764fbbe5d139ef0ed988ec5f95320ce730c0b
Onward0xe4c4c39c1733e1c7c06b79f97ed442b68df41ec618,613,584 POL
Onward0x5392587814ce8c6af6789764f88e5e9ab0b9962c4,295,442 POL
Onward0xc91ee0574a14446de200923729c349b9cae19b605,727,258.45 POL
Host and behavioural artifacts
Storage keyspolymarket.auth.params · polymarket.auth.proxyWallet · poly_clob_api_key_mapRead from browser local storage to recover session and trading credentials
Strings__reactFiber$ · startdebugger · safeBatchTransferFrom · DepositWallet
BehaviourWalks the React component tree to reach the live order clientHolds no keys of its own. It reuses the signer already in the page, so there is no wallet prompt to notice.
Hunting note. The drainer only fired inside logged in sessions, and every host it touched was already on the site’s content security policy allowlist. Look for requests to the vendor data host carrying payload sizes far larger than normal performance beacons, and for batch transfer activity in the hour before the vendor published its incident notice.

How to Avoid This

  • Inventory every external script running on authenticated pages
  • Pin versions with Subresource Integrity wherever the vendor allows it
  • Treat your CSP allowlist as attack surface, not as protection
  • Keep vendor code off pages that touch funds, keys, or credentials
  • Alert on payload size and shape changes to vendor endpoints

Your Attack Surface Includes Code You Did Not Write

The vendor was approved years ago, and nobody looked again. That gap is not a tooling failure; it is a capacity failure, and it is exactly the kind of grunt work that never reaches the top of anyone’s queue.

  • Red Teammate maps the external scripts loading on your authenticated pages and validates what an attacker could actually reach through them
  • AppSec Teammate watches third-party code in the delivery path, not only the dependencies sitting in your repo
  • SOC Teammate pulls odd vendor callbacks and scattered user reports into one case instead of five dashboards
  • Consequential moves, like cutting off a vendor domain, stop at your approval gate with a record of who decided what
  • Every fix gets retested, so you hold before-and-after evidence instead of a closed ticket