Polymarket’s October 29 breach reached traders through a compromised website supplier. Researchers found code that tried to use logged-in accounts to sell positions and move assets, exposing the trust traders place in the screen they use to manage their money.
Summary
- Polymarket confirmed a compromised provider and restored international trading after a 1-hour halt.
- Researchers linked the incident to a performance-monitoring script loaded by the website.
- The retrieved code sought access to the trading client and signer inside an active session.
- A separate vendor breach in June had already prompted a promise of full refunds.
- The latest reimbursement pledge does not yet explain how sold positions will be valued.
A trader using the name Car said approximately $800,000 had disappeared from his Polymarket account and all his positions had been sold. He said he kept trading on a separate device and avoided unfamiliar links.
Other traders were reporting losses as Polymarket restricted its international exchange on October 29. The company later confirmed that a third-party provider had been compromised and promised to reimburse affected customers.
The emerging technical account points to software loaded inside the genuine trading website. Security researchers found a monitoring script that tried to reach the tools a logged-in trader uses to place orders and authorize wallet actions.
For those users, the danger could arrive through the page they had already opened to trade. The investigation concerns the software operating inside that page and the account permissions it could reach.
Polymarket’s incident notice records a halt from 18:05 to 19:05 UTC. The company said it had fixed the issue and referred the incident to law enforcement, but has not released its full investigation or a final loss total.
The breach came 4 months after another compromised vendor introduced malicious code to the website. Polymarket promised refunds after that incident as well.
Traders reported sold positions before Polymarket stopped trading
A trader using the name Car said his account had been drained of approximately $800,000 and that a friend had lost another $600,000. He said all his positions had been sold.
In posts describing the incident, Car said he separated his personal activity, software development and trading across different devices. He suspected a problem with the platform’s website because other users appeared to have been affected as well.
His account described losses suffered while using the trading service, rather than a transfer he said he had deliberately approved. Polymarket’s subsequent statement confirmed a compromised provider, although it did not publish findings on his individual account.
Another account, StarPlatinum, tracked a suspected recipient wallet and estimated that it had accumulated $2.68 million. The account said the balance had grown during approximately an hour of withdrawals.
The observer’s timeline placed the first receipts at around 17:05 UTC, before the company posted its initial service restriction. It claimed that the wallet held $412,000 by 17:25 UTC and $2.02 million by 17:50 UTC.
As crypto.news previously reported, the initial reports of losses included allegations that funds had passed through Polymarket’s deposit-wallet infrastructure. Those descriptions came from traders and blockchain observers while the company was still investigating.
The company later said it had fixed the issue and would reimburse affected users. It did not confirm the individual loss amounts or adopt the observer’s estimate as its final accounting.
A screenshot circulated during the incident showed a wallet signing request associated with the Polymarket domain. It displayed a DepositWallet data field and Polygon’s chain identifier, but did not show a completed transaction or the full details needed to reconstruct an individual account’s activity.
The user reports included both assets transferred away from accounts and positions sold before their owners intended to close them. Polymarket has not said whether every affected user experienced both.
Polymarket restored service after a one-hour halt
Polymarket initially moved the exchange into cancel-only mode and paused relayer actions while its team investigated. The restriction allowed users to cancel existing orders while new orders and trades stopped processing.
At 18:37 UTC, the company said it had identified and fixed the issue affecting its international platform. It said a third-party provider had been compromised and that trading remained temporarily halted as a precaution.
The status page carried another update at 18:55 UTC saying trading would resume at approximately 3 p.m. Eastern. The incident was marked resolved at 19:05 UTC, or 3:05 p.m. Eastern Daylight Time.
The company’s restoration message repeated its commitment to reimburse affected traders. The notice did not announce that all refunds had already been paid when trading resumed.
Polymarket’s relayer is part of the infrastructure used to submit signed wallet actions to the blockchain. Pausing those actions accompanied the restrictions on its order book during the investigation.
Its trading documentation describes a system in which users create signed orders, an operator matches buyers and sellers, and contracts settle the trades on-chain. The October incident notice identified the Predictions Trading API, commonly called the CLOB, among the affected services.
The company continued posting updates through its public status service as the response progressed. Account access, market data and order execution are listed separately there.
The restriction announced on October 29 concerned the international platform. Polymarket did not name its separate American exchange as an affected venue in the incident notice.
The service resumed while the investigation into unauthorized transactions continued. The public updates did not name an attacker or describe how the provider was first compromised.
Polymarket referred the incident to authorities in the United Kingdom, according to its statement and subsequent reporting. DebugBear is based in the UK.
Investigators linked the breach to a monitoring script
DebugBear’s products help website operators measure loading speed and other aspects of visitor experience. Its real-user monitoring service uses JavaScript embedded in a customer’s website.
The supplier acknowledged an ongoing security incident and advised customers using that product to remove its embed code. Reuters identified DebugBear as the provider involved in the Polymarket incident, citing a person familiar with the matter.
Polymarket’s own status notice referred to a third-party provider without naming it. The company said the issue had been fixed but did not publish a full technical report with that announcement.
Security firm Hudson Rock examined a JavaScript file served from DebugBear infrastructure. In its investigation, the researchers said the file searched Polymarket’s running application for the trading client and signer used by a logged-in account.
The firm said the code inspected balances and positions before attempting to move value to a configured recipient. It found different paths for transferring position tokens and selling positions before attempting to transfer the proceeds.
Hudson Rock said the code sought to reuse access available within an authenticated session. Its review did not identify a routine that sent a seed phrase, password or private key to the script’s reporting endpoint.
The researchers found a reference to removing the DebugBear integration in Polymarket’s production build metadata. They said the entry supported the removal of the integration, while leaving the exact period of user exposure unresolved.
BleepingComputer separately examined a copy of the script and described attempts to use existing trading sessions to place orders and transfer assets. Its blockchain review followed approximately 28.6 million POL from the suspected recipient to three additional wallets.
The publication valued that movement at approximately $2.57 million at the time of its examination. Hudson Rock cited a separate recipient-balance snapshot near $2.19 million, while other observers reported totals close to $2.7 million.
Polymarket has not reconciled those estimates in a company loss statement. The reports used different observations and valuation times during an investigation that was still developing.
None of the company’s public updates identified the person controlling the recipient wallet. The provider compromise, unauthorized trading reports and subsequent transfers remain the subjects of the investigation referred to law enforcement.
The refund promise includes traders whose positions were sold
Polymarket said affected users would be made whole and reiterated that it was fully reimbursing traders after service returned. The statement did not set a deadline for submitting claims or require every customer to withdraw funds within a particular period.
The company has not published a detailed reimbursement policy for the October incident. It has yet to state whether payments will be automatic in every case or whether some users will need to provide information about disputed activity.
Car’s report that his positions were sold raises a question beyond a missing wallet balance. A trader can hold contracts on an event that has not yet occurred, sell them before resolution or retain them until the outcome is determined.
Polymarket’s position documentation describes Yes and No holdings separately from the collateral used to buy them. A complete set is backed by 1 pUSD, while an individual outcome’s final payout depends on the recorded result.
The platform’s rules allow traders to sell positions before resolution. When an unauthorized sale occurs, the account’s trading history can record both the contracts removed and the proceeds received before any later withdrawal.
Polymarket has not said whether it will restore sold contracts, compensate customers using a particular market price or apply another method. Its public promise covers affected traders without specifying how each type of account activity will be handled.
The platform’s order documentation records stages between submitting an order and confirming a settled trade. Orders can remain open, match against another trader, expire or fail to settle.
The company can draw on both trading and blockchain records when reviewing disputed activity. Users’ reports of unwanted sales concern the order history, while transfers out of the wallet leave a separate transaction record.
Its support page provides website chat and the email address [email protected] for the international service. The American app has a separate contact at [email protected].
No company-wide payment schedule appeared in the restoration notice. The company’s statement did not ask customers to pay a recovery charge or disclose wallet recovery credentials to obtain a refund.
June’s breach led to an earlier promise of full refunds
Polymarket acknowledged a separate vendor compromise on June 25 after a malicious script appeared in its website for some users. The company said it had contained the incident, removed the affected dependency and was contacting customers about reimbursement.
The company’s earlier refund pledge followed an estimate from blockchain analyst Specter that at least 11 wallets had lost approximately $2.94 million. The analyst described users holding PUSD whose assets were subsequently converted into ETH.
Specter characterized the incident as phishing through the affected interface. The company’s disclosure identified a compromised vendor as the route through which the script had reached some users.
AMLBot later raised the estimated June losses to $3.1 million. Its June 27 account described PUSD taken on Polygon, converted through Relay, bridged to Ethereum and exchanged for ETH.
Polymarket’s June commitment was to refund affected users in full. The company’s October statement made a new reimbursement promise concerning the latest incident.
The company has not said the two breaches involved the same supplier or attacker. June’s disclosure and the October investigation both concern outside software used by the platform, but they describe separate events four months apart.
The earlier incident took place while Polymarket was expanding the use of PUSD across its trading infrastructure. Its June statement concerned users affected by the malicious script, without announcing a suspension of every market offered under the Polymarket brand.
The October response again included removing or fixing the compromised integration and restricting activity while the team investigated. The technical details and victim totals released in each case have followed different timelines.
The June reports did not provide a transaction-by-transaction account showing completion of every refund. Polymarket’s latest notice likewise does not publish a list of completed October reimbursements.
Researchers examined software running inside the trading page
The investigation has focused on code loaded by a website that users already recognized. Hudson Rock’s account described attempts to locate the trading client within the running application, rather than an instruction for users to visit a separately branded exchange.
Browser documentation maintained by Mozilla explains that JavaScript included directly in a page can access other scripts and data within that page. A monitoring script loaded in that way runs with access that differs from content isolated inside a separate frame.
Website operators use such integrations for analytics, error reporting and performance measurement. DebugBear describes its real-user monitoring product as collecting information about how visitors experience a website.
Polymarket’s trading interface performs a different set of tasks, including displaying positions, preparing orders and interacting with a signer. The researchers said the retrieved file contained logic directed at those trading functions.
Polymarket’s wallet documentation describes several account types, including Deposit Wallets and legacy Proxy and Safe wallets. Its documentation assigns Deposit Wallets to accounts deployed on or after May 4, 2026.
The platform permits a wallet owner to authorize a separate signer for specified trading activity. Its beta session-key documentation says such a key can trade for a Deposit Wallet but cannot withdraw its funds.
The company has not identified session keys as the cause of the October breach. The researchers’ account describes attempts to use the client and signer already available in the application.
Polymarket’s order guide says users sign structured messages containing the trade’s outcome identifier, side, price, size and other terms. The operator validates signatures, balances and allowances before matching an order.
Matched trades then pass to settlement contracts, with the platform recording whether execution was confirmed or failed. The October status notice did not report a failure of Polygon consensus or announce that every settlement contract had been compromised.
The company’s public response has so far identified the provider compromise and promised compensation without releasing a complete account of every signing and transfer path.
Browser protections depend on which code the website trusts
A website can load a supplier’s software without sending the visitor to another address. The browser fetches the file as part of opening the page, alongside the exchange’s own application code.
Mozilla’s browser documentation explains that a script embedded directly in a page can operate with the page’s access. The supplier’s commercial role as a performance monitor does not itself impose a browser restriction that confines its code to measuring loading times.
Content placed in a separately isolated frame has different boundaries. A script included in the trading application does not acquire that isolation simply because another company supplies it.
The October investigation places that distinction inside a financial application. Polymarket’s page displays balances and positions while connecting to services that prepare orders and request signatures.
The company has not published a complete inventory of the outside code permitted to run in that environment. Its incident statement identifies a provider compromise without describing the permissions review that preceded the integration.
Browsers provide controls intended to limit this exposure. Mozilla’s Subresource Integrity documentation describes a method for checking a downloaded script against a cryptographic fingerprint specified by the website.
If the downloaded file differs from the expected fingerprint, the browser refuses to execute it. A supplier changing the file would therefore require the website to approve the new version before it could run under that check.
The protection depends on the website deploying it for the resource concerned. Polymarket’s notice does not say whether the affected integration used such a check or publish findings about why the retrieved code was accepted.
Mozilla’s Content Security Policy guidance describes another set of controls over executable scripts. A policy can restrict sources or authorize particular code using nonces and hashes.
Permission for a supplier’s host does not by itself verify every file that host serves. A host can remain the same while the content delivered from it changes.
Those controls operate before or as code runs in the browser. They serve a different purpose from exchange surveillance that examines orders after a trading client has submitted them.
Trading authority and withdrawal authority have different limits
Polymarket’s own documentation describes efforts to limit what a delegated signer can do. Its beta session-key system lets a wallet owner authorize a separate key for trading within specified limits.
The documentation says a session key cannot withdraw funds. Its permissions can cover the central order book, combination trades or the supported trading venues, and the owner grants the authorization for a defined period.
A trading permission still allows activity that changes a portfolio. The distinction matters for customers reporting positions sold without their consent, even before any proceeds leave the wallet.
Polymarket has not identified the beta session-key system as the entry point in October. Researchers described attempts to locate the live client and signer available to the application, while the company has yet to explain which permissions were successfully used in each affected account.
The platform’s order-lifecycle guide describes orders signed off-chain before an operator validates and matches them. The checks cover the signature, account balances and allowances, among other conditions.
Settlement then occurs through blockchain contracts. The records distinguish a matched order from one whose settlement has been confirmed or has failed.
A valid signature is part of that process, but it does not establish that the person viewing the screen wanted the transaction. The reported attack sought to use authorization available through the application that prepares those requests.
The public findings do not establish that every wallet type allowed silent signing or that every attempted action succeeded. Polymarket supports several wallet arrangements, and its company investigation has not yet mapped the affected accounts to those arrangements.
The company’s June incident had already exposed a similar reliance on outside website code. Its earlier frontend breach involved a malicious script delivered to some visitors through a compromised dependency.
The October response again required action at the platform level: a trading restriction, paused relayer actions and a fix for the affected integration. Customers’ separate trading devices did not give them control over the software the website chose to load.
Refunds must address the trades as well as the missing cash
Polymarket has promised to make affected users whole, but its status notice does not explain how it will value positions closed without their owners’ approval. Restoring a cash balance and restoring an open event position can produce different account holdings.
A trader whose contracts were sold may have intended to hold them until an election result or another event was resolved. The sale records show what the contracts fetched at that moment, while their later market value can change before reimbursement.
The company has not said whether it will replace contracts, use the price immediately before the disputed sale or apply another valuation method. It has not announced that users must wait for the underlying events to resolve.
Polymarket’s trading records and wallet history provide separate parts of that account. The order history records changes in positions, while blockchain records can show subsequent transfers of collateral or tokens.
A recipient wallet’s balance cannot on its own identify every customer’s loss. Individual claims can involve a series of trades, transfers and later movements through other addresses.
The earlier June investigation followed assets from Polygon through a bridge and into ETH on Ethereum. Its revised loss estimate rose after the initial refund announcement as analysts traced more activity.
Polymarket has not published an October claims cutoff or a schedule for payments. Its international support service remains separate from the American exchange, which the incident notice did not identify as affected.
The platform restored trading at 19:05 UTC on October 29. Its public notice records the service incident as resolved while retaining the commitment to compensate affected customers.
What to watch
Technical findings: Which account permissions the script successfully used, and which wallet types were affected.
Supplier controls: The company’s findings on how outside software reached the trading application.
Loss accounting: A company total that reconciles affected accounts and unauthorized transactions.
Refund terms: How Polymarket values sold positions and when customers receive compensation.
FAQ
What happened to Polymarket on October 29?
Polymarket said a third-party provider was compromised and temporarily restricted its international platform. Trading returned after a 1-hour service incident.
How much did traders lose?
An observer estimated $2.68 million, and other tracing reports produced figures near $2.7 million. Polymarket has not announced a final loss total or confirmed the number of affected accounts.
Has Polymarket promised to refund users?
Yes. The company said traders affected by the October 29 incident would be made whole and reiterated its reimbursement commitment when trading resumed.
What did affected traders report?
A trader using the name Car said approximately $800,000 had been taken and all his positions sold. He said a friend had lost another $600,000, although Polymarket has not confirmed those individual claims.
Which supplier was linked to the breach?
Reporting and security researchers linked the incident to DebugBear’s monitoring script. Polymarket’s October 29 status statement confirmed a compromised provider without naming it.
Was this the same breach as the one in June?
No. The June 25 disclosure concerned a separate vendor incident, with losses later estimated at $3.1 million. The company has not announced a common attacker or supplier between the two cases.
Did the notice say Polymarket US was affected?
No. The October 29 incident notice names the international platform, while the American exchange operates separately.
What happens to positions sold without the owner’s approval?
Polymarket has not published a compensation method for sold positions in its October 29 statement. Its pledge is to make affected traders whole. This is educational analysis, not investment advice.
Disclaimer: This article is for information and educational purposes only and does not constitute financial or investment advice. Figures reflect regulatory filings and reporting available at the time of writing and change with each disclosure. Nothing here is a recommendation to buy, sell, or hold any security or asset. Always do your own research. Information is accurate as of October 30, 2026.
