Polymarket Script Hijack Led to $2.7M Loss Across 726 Wallets

En bref

• A third-party page-speed script was compromised on 29 October.
• Attackers sold positions and shifted proceeds from 726 wallet addresses.
• Reported losses reached about $2.7M, with roughly $2.64M tied to affected wallets.
• Refunds followed, but no CVE was assigned, so supply-chain monitoring is essential.

On 29 October, unknown attackers interfered with a page-speed measurement script connected to DebugBear that was running in Polymarket's prediction-market environment. The altered code was used to close out user positions, shift proceeds, and impact 726 wallet addresses. Reported losses reached approximately $2.7 million, with about $2.64 million linked to the affected wallets. Refunds were later issued, but the event still demonstrates how a third-party performance utility can become a path into financial workflows.

Polymarket users were the immediate victims, but the exposure is broader than one platform. Any organization that embeds vendor JavaScript inherits a supply-chain risk: a compromised analytics, speed-testing, or tag-management script can act with the same browser trust as the host site. In this case, the script was associated with DebugBear and loaded in a prediction-market product, where wallet-linked balances and trading positions create high-value targets.

Why it matters: the incident combined script hijacking with direct financial impact. Attackers did not need a software vulnerability with a CVE identifier; no CVE was assigned. Instead, they appear to have abused trust in third-party code to trigger position sales and fund movement. That makes signature-based patching insufficient and puts more weight on integrity checks, change detection, and vendor oversight.

What to watch: whether DebugBear and Polymarket publish a full timeline, whether the same script build appeared on other sites, and whether refunds covered all 726 wallets. IT teams should also watch for repeated wallet-drain patterns, unexpected script updates, and any reappearance of the tampered code. The key lesson is that page-speed and analytics tags deserve the same security scrutiny as payment or authentication components.

À faire maintenant

1. Inventory every third-party script now, especially page-speed, analytics, and tag-manager code; remove anything unused.
2. Pin script versions and enforce Subresource Integrity where possible; require vendors to notify you before changes.
3. Deploy a Content Security Policy with script-src allowlists, starting in report-only mode before enforcement.
4. Monitor script hashes, DOM changes, and outbound requests; alert on unexpected wallet or API activity.
5. For affected users, revoke wallet approvals, review transactions, rotate credentials, and publish clear refund guidance.
6. Ask DebugBear and Polymarket for an incident timeline and confirm whether other customers loaded the same compromised build.
7. Preserve logs and run a supply-chain tabletop exercise covering third-party script compromise and customer notification.

Source originale

The Hacker News