Polymarket Theft Shows How a Hijacked Third‑Party Script Can Drain Wallets

What happened

On 29 October, malicious code running on the website of prediction market Polymarket sold the positions of some signed-in traders and sent the proceeds to the attackers. The code had taken the place of a page-speed script that the site loaded from DebugBear, a company whose real user monitoring tool measures how quickly pages load for actual visitors. Polymarket says it is refunding about $2.7 million to 726 affected wallets. Blockchain tracing put roughly $2.64 million in POL tokens into the attackers' wallet in under an hour, and that figure excludes the positions that were also taken.

DebugBear said its DNS records were compromised through its domain registrar, and its early findings suggest the attack targeted a single customer. It has seen no sign of a break-in to its own systems, though it is still investigating. Researchers who reviewed the file without running it found that it reused the access of a trader already signed in to an open page. The code did not appear to send passwords, seed phrases or private keys anywhere. Instead, it located the part of the site that places orders and the signer that approves transactions, then asked that signer to approve requests passed to Polymarket's relayer. Accounts using their own crypto wallet had positions moved directly to the attackers, while email-based accounts had positions sold at progressively worse prices before the money was moved out. Researchers cautioned that a signing request alone does not show a trader approved it without a prompt, because wallet providers may still ask, refuse or apply their own rules.

Polymarket posted its first status update at 17:38 UTC, put its exchange into cancel-only mode and paused relayer actions. It removed the script, cleared every cache, reset all active login sessions and paused trading until the site was clean. It has referred the case to law enforcement. By 30 October, 689 of the 726 wallets had been refunded in full, with the remaining 37 being paid as they were checked. A further $1.19 million is going to about 5,500 wallets that lost money during the pause or had positions taken, bringing the total returned to $3.9 million. DebugBear has told customers to remove its embed code, and Polymarket is restoring third-party scripts with a stronger Content Security Policy, pinned versions and sandboxing.

Why it matters for organisations in Africa, the Gulf and beyond

The weakest point in this incident was not Polymarket's own infrastructure. It was a trusted supplier's domain, reached through a registrar account, serving code that ran with the full privileges of a signed-in user. Any organisation that loads analytics, monitoring, chat, tag-management or payment scripts onto authenticated pages carries the same exposure. In that position, a supplier's DNS configuration becomes part of your own attack surface, whatever your contracts say.

For organisations in Africa, the Gulf and beyond, the lesson applies well outside crypto. Banks, fintechs, e-commerce operators, telecoms and government portals are all building digital channels quickly, and these channels typically lean on outside services for speed, measurement and customer experience. Each of those services is a place where code you did not write runs inside your customers' sessions. Where regional teams are lean and growth is fast, script inventories and supplier reviews are often the first controls to slip.

The incident also shows why response speed and rehearsal matter. Polymarket could remove the script, clear caches, reset sessions and pause trading, and it could refund affected users quickly. Not every organisation can do that, and fewer have decided in advance who may pause a service, who speaks to customers and how losses are assessed. Supplier compromise tends to be fast, quiet and indirect, so the response plan has to assume your own monitoring may not be the first to notice.

What leaders should do now

Leaders can reduce this exposure with a short set of decisions that do not depend on any single technology.

• Inventory every third-party script on pages where users sign in or transact, and name an owner for each one.
• Remove outside scripts from the most sensitive pages unless there is a clear business case, and apply a strict Content Security Policy, pinned versions and sandboxing to those that stay.
• Ask suppliers how they protect their domain registrar and DNS accounts, and make this part of supplier due diligence and renewal.
• Require explicit, clearly worded user confirmation for high-value actions, and tell customers to reject signing or approval requests they did not expect.
• Rehearse the response: who can pull a script, clear caches, reset sessions, pause transactions and speak to customers and regulators.
• Track changes to the scripts and endpoints your pages load, so an unexpected swap is noticed by you and not by a researcher.

How DAAKYI can help

DAAKYI's GUIDE services help leaders see which suppliers and scripts sit inside their most sensitive customer journeys. Third-Party Risk Management gives structure to supplier questions, including how a supplier secures the accounts that control its domains. Our SECURE team's Application & API Security work looks at what runs in the browser and how it is constrained.

Response readiness is the other half. DAAKYI's capability approach includes executive briefings and tabletop exercises on realistic scenarios, so leaders have already rehearsed decisions like pausing a service or resetting sessions. Our Cyber Incident Readiness & Recovery solution brings those elements together for organisations that want to be able to act within the first hour.

• Third-Party Risk Management
• Application & API Security
• Cyber Incident Readiness & Recovery

Sources

• Hackers Steal About $2.7 Million From Polymarket Traders via Hijacked DebugBear Script (The Hacker News)