Have you ever sat in front of a trading screen you trust completely, only to wonder later if that trust was misplaced? On October 29 a number of Polymarket users discovered exactly that feeling when their positions started selling and funds began leaving accounts they thought were under their control. The platform itself was not hacked in the classic sense. A third-party website supplier was. That single detail changes how we should think about the safety of every trading interface that loads outside code.
What Actually Happened During the Polymarket Incident
The first reports came from traders themselves. One user who goes by the name Car described waking up to roughly $800,000 gone and every open position closed without permission. A friend of his reported a similar loss near $600,000. Other accounts began tracking a recipient wallet that appeared to collect funds over a short window of time. Estimates from different observers settled somewhere between $2.1 million and $2.7 million, though the company has not released a final figure.
Polymarket reacted by placing its international platform into cancel-only mode and pausing certain relayer actions. The restriction lasted about one hour, from roughly 18:05 to 19:05 UTC. During that window the team identified a compromised third-party provider, removed the problematic integration, and restored normal trading. The company also stated it would reimburse affected users and had referred the matter to law enforcement in the United Kingdom.
I find the timing interesting. The first signs of unusual activity showed up around 17:05 UTC, nearly an hour before the official halt. That gap is the period many traders later described as the window when unwanted sales and transfers took place. In my view this underlines a simple reality: once malicious code is running inside an authenticated session, the damage can move faster than the platform’s ability to respond.
How a Monitoring Script Became the Attack Vector
Security researchers later examined a JavaScript file served from the infrastructure of a performance-monitoring service. The script did not ask users for seed phrases or private keys. Instead it searched the running Polymarket application for the trading client and the signer already present in an active session. Once located, the code checked balances and open positions, then attempted two different paths: transferring position tokens or selling the positions and moving the proceeds.
That design choice is what makes the incident especially unsettling. The attack lived inside the genuine website. Traders were not clicking strange links or approving unexpected wallet prompts in the usual phishing sense. They were simply logged into the official interface, and the page itself contained logic that tried to act on their behalf.
Perhaps the most interesting technical detail is what the script did not do. Researchers found no evidence that it tried to exfiltrate passwords or recovery phrases. It relied entirely on the permissions already granted to the trading client inside the browser. In a way that makes the problem harder, not easier. The code was operating with the same authority a legitimate user session already possessed.
The Role of Third-Party Code on Financial Websites
Modern websites load many external scripts. Performance monitors, analytics tools, error trackers and customer-support widgets all arrive as JavaScript. When that JavaScript is embedded directly in the page rather than isolated inside a frame, it inherits access to the same environment as the site’s own code. Browser documentation has long explained this behavior. A monitoring script can, in principle, reach anything the page can reach.
On a news site or a blog the risk is limited. On a trading platform that prepares signed orders and interacts with wallet signers the risk is far higher. Polymarket’s documentation describes several wallet types, including newer Deposit Wallets and older Proxy or Safe arrangements. It also supports session keys that can trade but cannot withdraw. The October investigation has not yet mapped which wallet types were successfully targeted or whether session-key limits held.
I’ve found that many traders assume the presence of a reputable monitoring vendor automatically equals safety. That assumption needs revision. Reputation does not prevent a vendor’s own systems from being compromised, and once the vendor is compromised the downstream effect lands inside every customer site that still loads the script.
A Familiar Pattern: The June Incident
This was not Polymarket’s first encounter with a compromised vendor. In late June a different third-party dependency introduced malicious code to parts of the website. Blockchain analysts at the time estimated losses near $3 million after funds were converted and bridged. The company promised full refunds then as well.
Four months later the same general pattern reappeared: outside software loaded by the genuine site, users experiencing unauthorized activity, a temporary restriction of trading, and another public commitment to make affected traders whole. The company has not stated that the same supplier or the same attacker was involved. The parallel still matters. It shows how repeatedly the trading screen itself becomes the point of failure when third-party code is trusted too far.
In both cases the platform moved relatively quickly once the problem was detected. That speed is positive. The deeper issue is how the code reached the page in the first place and how long it may have been present before detection.
What Traders Experienced in Real Time
Some users reported only that balances disappeared. Others said every open position was sold first, after which the resulting collateral was moved. The distinction is important for any future reimbursement discussion. A cash balance can be restored in a relatively straightforward way. An open position on an unresolved event is different. Its market value can change between the moment of the forced sale and the moment of compensation.
Polymarket has said affected users will be made whole. It has not yet published the exact method it will use to value sold positions. Will contracts be restored? Will the price immediately before the unauthorized sale be used? Will a later market price or some other formula apply? Those details remain open. In my experience such ambiguities tend to generate the most frustration among users even when the overall refund intention is clear.
The danger arrived through the page traders had already opened to manage their money.
That single sentence captures the core problem. No obvious phishing site, no fake domain, no social-engineering call. Just the ordinary trading screen carrying code that tried to act with the user’s existing authority.
Browser Protections and Why They Matter
Browsers already contain tools that can limit this class of risk. Subresource Integrity lets a website specify a cryptographic fingerprint for an external script. If the downloaded file no longer matches the expected hash, the browser refuses to run it. Content Security Policy can further restrict which sources are allowed to execute code. Neither control is automatic. Both require deliberate configuration by the site operator.
When a monitoring vendor is allowed to serve scripts without integrity checks, any change on the vendor side—whether accidental or malicious—can reach every visitor still loading that resource. The October incident illustrates the consequence of that design choice more clearly than most theoretical discussions ever could.
I keep returning to the same practical question: how many trading platforms currently inventory every third-party script that runs with full page privileges, and how often do they re-verify the integrity of those scripts? The public record so far does not answer that question for Polymarket or for most of its peers.
Trading Authority Versus Withdrawal Authority
Polymarket’s own documentation draws a useful distinction. Session keys can be granted limited trading rights without the ability to withdraw funds. That separation is meant to contain damage. Yet selling positions still changes a portfolio’s risk and expected outcome. Even if the proceeds never leave the wallet, the trader no longer holds the contracts they intended to keep until resolution.
Researchers described attempts to locate the live client and signer rather than to break out of a session-key sandbox. Whether every successful action in the October incident stayed within trading permissions or crossed into withdrawals is still part of the ongoing investigation. The public findings do not yet provide a complete map.
This is one of those areas where technical nuance matters more than headlines. A system can be designed with careful permission boundaries and still fail if the code that prepares the signed messages is itself compromised at the interface level.
How Refunds Will Need to Address Different Types of Loss
Making users whole sounds straightforward until the details appear. Some accounts lost only collateral. Others lost positions that may have appreciated or depreciated after the forced sale. A complete set of Yes and No contracts is backed by a fixed amount of collateral, but an individual outcome token’s final value depends on the eventual result of the market. Compensating the cash proceeds of a sale is not identical to restoring the original exposure.
The company has not published a claims deadline or a detailed valuation policy. Support channels remain open for the international service. The American exchange was not named as affected in the incident notice. Those operational facts are clear. The valuation methodology is not.
In previous cases of this kind the final loss total often rose after the initial announcement as more transactions were traced. Whether the same pattern appears here remains to be seen. The important point for users is that both the trading history and the on-chain transfer record will likely be needed to reconstruct each claim.
Lessons That Extend Beyond One Platform
The Polymarket episode is not an isolated curiosity. Any financial website that embeds third-party scripts for performance, analytics or support faces a version of the same exposure. The more privileges those scripts receive, the greater the potential impact if the supplier is compromised.
Traders can take a few practical steps even while platforms improve their own controls. Separating high-value activity onto dedicated devices, as the user Car described doing, reduces the chance that a single compromised session affects everything. Monitoring wallet activity with external tools can provide an independent signal when unexpected transfers begin. None of these measures is perfect. They do, however, shift some detection capability back toward the user.
From the platform side the path is clearer though harder. Inventory every external script. Apply integrity checks where possible. Isolate monitoring code so that it cannot reach the trading client or signer. Review the permissions granted to any session-level authority. And treat every third-party integration as a potential attack surface rather than a convenience.
- Inventory all third-party scripts that load with full page access
- Apply cryptographic integrity checks to critical external resources
- Isolate performance and analytics code from trading logic where feasible
- Limit the lifetime and scope of any delegated trading keys
- Maintain clear, public processes for valuing and reimbursing forced sales
Those steps will not eliminate every risk. They would have raised the cost and complexity of the kind of attack seen on October 29.
What Remains Unknown
Several questions still lack public answers. Exactly which permissions the malicious script successfully exercised in each affected account. How long the compromised code was present before detection. Whether the same supplier had been vetted with integrity controls. How Polymarket will ultimately value positions that were sold without consent. And whether the final loss figure will match, exceed or fall short of the early observer estimates.
The company has referred the matter to authorities and restored service. Those are necessary first steps. A fuller technical report and a transparent reimbursement framework would strengthen confidence further. Until then the trading screen remains both the place where users manage their money and the place where a compromised supplier can reach that money.
I’ve watched enough of these incidents to know that the next one will probably look different in the details and similar in the underlying pattern. Outside code running with inside privileges is a recurring theme. The platforms that treat that pattern as a design problem rather than a one-off misfortune will be the ones traders can rely on more comfortably.
Looking Ahead
Prediction markets live or die on the credibility of their settlement and the safety of the interface that connects users to those markets. When the interface itself becomes the vector, the damage is both financial and psychological. Users who keep their funds on a platform do so because they believe the screen in front of them is under trustworthy control. That belief is harder to maintain after two vendor-related incidents in four months.
Polymarket’s rapid response and repeated commitment to full reimbursement are positive signals. The longer-term test will be whether the technical architecture around third-party scripts and session authority receives the same level of attention. Traders, for their part, would do well to treat every trading screen as a potential surface rather than a sealed environment. The code that appears under the official domain is not always written exclusively by the platform that owns the domain.
In the end the question is not whether any single platform can achieve perfect safety. It is whether the industry as a whole begins to treat the composition of the trading page with the same seriousness it already applies to smart-contract audits and custody practices. The October 29 events offer a concrete case study. How the lessons are absorbed will determine how many similar stories need to be written in the future.
The trading screen will always be the place where users meet the market. Making that meeting safer requires attention to every line of code that is allowed to run there, including the lines that arrive from somewhere else. That is the practical takeaway from a day when positions vanished while the official site was still open.
