Polymarket Suffers Second Security Breach in Four Months

Prediction Market Hit by Third Breach

Polymarket restored trading operations at 19:05 UTC on Oct. 29 following an emergency halt triggered by a compromised third-party monitoring script. Blockchain analytics firm Bubblemaps reported that over 700 user accounts were drained during the security incident. Total losses reached $3.46M in digital assets across the affected wallets. Attackers rapidly converted roughly $2.70M of the stolen funds into POL tokens and routed them out of the protocol. Another $750K remained stranded on Polymarket order books at the time of the initial assessment.

The latest breach follows a similar website script attack on June 25 that drained approximately $3.00M from high-value accounts. Source Defense investigations into the June incident revealed that malicious actors replaced a legitimate marketing tag with a custom drainer script. That earlier payload targeted wallets holding over $100,000 and repeatedly prompted victims for digital signatures. Once approved, those malicious requests executed directly through Polymarket proprietary relayer infrastructure. The recurrence places intense pressure on protocol developers to audit external integrations.

Hudson Rock Uncovers DebugBear Script Threat

Hudson Rock security analysts traced the Oct. 29 attack vector to a malicious script retrieved from a DebugBear-associated URL. The injected code actively scanned logged-in user sessions for live trading clients and cryptographic signers. Depending on the targeted account type, the script executed instructions to either transfer position tokens or drain sale proceeds. Production-build metadata confirmed that engineers removed the DebugBear monitoring script immediately after discovering the breach. Static code reviews left the exact mechanics of silent signature execution unverified by external researchers.

Polymarket management stated that the vulnerability had been patched and referred the incident to law enforcement authorities. Executives promised to make all affected users whole through direct compensation. However, public incident records left the exact exposure window and the final count of compromised accounts unresolved. The breach demonstrates how easily third-party vendors can bypass standard browser security boundaries. Attackers continue to weaponize external dependencies to reach inside authenticated user sessions.

Defense Mechanisms and Browser Vulnerabilities

MDN browser documentation highlights that third-party scripts loaded directly into a web page share the same DOM access as native code. Hosting vendor files on separate domains fails to isolate sensitive data if scripts execute within the primary context. Implementing Subresource Integrity allows modern browsers to verify downloaded files against expected cryptographic hashes. This cryptographic check rejects modified scripts even if the primary hosting domain remains trusted by the application. Protocol engineers must reduce external code dependencies on pages handling private key signatures.

Limiting signer access and enforcing mandatory user confirmations for every state change restricts what injected payloads can achieve. A detailed postmortem explaining the precise authorization paths would help traders assess remaining platform risk. The unresolved question is whether another compromised vendor could transform interface access into automated financial theft. Traders withdrew capital as uncertainty mounted across order books.