Hackers Steal About $2.7 Million From Polymarket Traders via Hijacked DebugBear Script

A third-party script on Polymarket was swapped for malicious code, and signed-in traders paid the price. About 726 wallets were affected, with Polymarket saying it will refund roughly $2.7 million.

Borrowing a trusted house key is fine until the locksmith gets robbed.

That is basically the risk with third-party scripts on a website. If a site loads code from another company, it is not just borrowing a tool. It is inviting that outside code to run inside the same page as the bank account, the shopping cart, or in this case, a trading session.

On October 29, that risk appears to have turned into real losses for some Polymarket traders.

A performance tool turned into a theft tool

Polymarket said malicious code on its website sold some signed-in traders' positions and moved funds to the attackers. The bad code had replaced a page-speed script that the site loaded from an outside company, DebugBear.

Polymarket says about 726 wallets were affected and that it is refunding about $2.7 million.

Blockchain records reportedly show crypto worth about $2.64 million reached attacker-controlled addresses. The exact flow and final loss number can vary a bit in crypto cases because on-chain tracking depends on timing, valuation, and whether some funds move again.

The core issue is straightforward. A user went to the real site, signed in as usual, and the page itself served hostile JavaScript. That code then acted inside the user session.

No fake login page needed.

No typo-squatted domain needed.

If you are not used to how browser code works, think of it like this: if you let a contractor into your office to fix the air conditioning, and they also get access to every unlocked desk drawer, the problem is not only the contractor. It is the level of trust they were given.

Why third-party scripts are such a sharp edge

Websites often pull in outside code for analytics, ads, chat widgets, performance monitoring, video players, and other routine features. It is common practice, and sometimes it is hard to avoid.

But from a security angle, every one of those scripts can become a bridge into the site.

If the outside provider is compromised, or if the script delivery path is tampered with, the attacker may gain the same browser-level access that the site itself has on that page. In a logged-in financial session, that is a dangerous place to be.

The browser does not care whether code came from your main site team or from a vendor you embedded. Once it runs in the page with the right permissions, it can read data on the page, trigger actions, change what the user sees, and send information elsewhere.

That is why this kind of attack gets described as a supply-chain problem. The direct victim may be the website and its users, but the entry point sits upstream in a dependency.

And this is the part regular users cannot really see.

A padlock in the browser bar only tells you the connection is encrypted. It does not tell you every script on the page is safe.

The notable part is how little the victim needed to do

A lot of online theft still depends on getting people to click a bad link, install a fake app, or hand over a code. This case is different in a way that is worth understanding.

Some affected users appear to have been signed in to the legitimate site when the malicious code ran. That means the attack likely piggybacked on trust that already existed: the user trusted the site, the browser trusted the session, and the site trusted the outside script enough to load it.

When all three line up, damage can happen fast.

For crypto platforms especially, browser-side actions can be enough to do real harm. If a page can trigger sales, transfers, or approval flows inside an already active session, even a short-lived script compromise can be expensive.

That does not mean every third-party script is reckless, or that every web app should ban them outright. It does mean sites handling money need to treat browser dependencies like privileged code, because that is exactly what they are.

What users and site operators should do next

If you use trading, banking, or wallet-connected sites:

• Be extra cautious with long-lived signed-in sessions. Sign out when you are done.
• Avoid keeping more funds on a platform than you need for active use.
• Review recent account activity after any reported incident and follow platform guidance on affected transactions.
• Treat unusual prompts, unexpected trades, or odd page behavior as a reason to stop immediately.

If you run a site that handles accounts or money:

• Cut back on third-party scripts, especially on authenticated and transaction pages.
• Use integrity checks and tight allowlists where they fit, so outside code changes are harder to slip in silently.
• Separate sensitive actions from pages loaded with marketing or analytics tooling.
• Plan for rapid script disablement and incident messaging before you need it.

The practical lesson is simple: if outside code can run on a sensitive page, that code is part of your security boundary whether you like it or not.

In this case, a page-speed script apparently became the attack path, and hundreds of wallets were caught in the blast radius. That is a hard reminder that on the web, convenience dependencies can turn into money-moving dependencies very quickly.