Hijacked DebugBear Script Drained About $2.7 Million From Polymarket Traders
Malicious code that replaced a third-party page-speed script on Polymarket sold some signed-in traders' positions on October 29 and sent the funds to the hackers. Polymarket says it is refunding about $2.7 million to 726 affected wallets.
Key points
- Malicious code on Polymarket’s website replaced a page-speed script the site loaded from the outside company DebugBear.
- On October 29, the code sold some signed-in traders’ positions and moved their funds to the hackers.
- Polymarket says it is refunding about $2.7 million to 726 affected wallets. Blockchain records show crypto worth about $2.64 million reached the hackers.
Malicious code running on the website of the prediction market Polymarket sold some signed-in traders’ positions on October 29 and moved their funds to the hackers. The code had replaced a page-speed script that Polymarket loaded from an outside company, DebugBear. Polymarket says it is refunding about $2.7 million to the 726 wallets affected by the incident.
Details
The attack hijacked a third-party script. Polymarket’s site loaded code from DebugBear, whose script measures page speed. Instead of the legitimate script, malicious code ran on the page. The affected users were signed in, so the code could act on their accounts. It sold some of their positions and moved the funds to the hackers.
The theft is visible on-chain. Blockchain records show crypto worth about $2.64 million reached the hackers. Polymarket says it is refunding about $2.7 million across the 726 affected wallets.
Background
The attackers did not break into Polymarket directly. They hijacked a script the site loaded from a third party: in this case, DebugBear’s page-speed script. Once the script was hijacked, the attackers’ code ran on Polymarket’s site.
Why it matters
For engineers, the lesson is concrete: any third-party script on your site runs with the trust of your signed-in users. A performance script from an outside vendor can be turned into a drainer overnight, and compromising a signed-in session on the client side is enough to move real funds.
What to do
- Audit which third-party scripts your site loads, and treat each one as code with full access to your users’ sessions.
- Consider subresource integrity (SRI) or version pinning so that a changed script fails to load instead of executing.
- If you run a crypto or trading product, watch for anomalous position closures and transfers in signed-in sessions, and be ready to freeze and refund quickly.