Polymarket hack: how a vendor script drained logged-in traders

What happened in the Polymarket hack?

The Polymarket hack of 29 October 2026 was an attack on the website's front end through a third-party script. Polymarket, a prediction market, said "one of our 3rd party providers was compromised" (Decrypt). It halted trading on its international platform for about an hour, then said it had fixed the issue and was "fully reimbursing all affected traders" (BleepingComputer).

Reuters reports that a source identified the provider as DebugBear, a website performance monitoring and debugging platform. DebugBear, a UK company, said on X: "We're impacted by an ongoing security incident," and asked customers using its real user monitoring (RUM) product to remove the embed code from their websites. It has brought in specialist incident responders, SecurityWeek reports. RUM means a script on your pages that measures how real visitors experience them.

This article is for security and leadership teams, not traders. The point is general: a third-party script is code from another company that runs inside your page, with the access of whoever is logged in. Short on time? Go to the checklist.

The Polymarket hack at a glance

Timeline of the Polymarket hack

Times are UTC. Where a source gave Eastern time, we converted it (Eastern Daylight Time is UTC minus four hours on this date). Time stamps from social media posts are not used.

• Earlier in 2026. Decrypt reports a private key compromise in May that drained roughly $700,000 from an internal wallet, and about a month later a compromised third-party vendor that let attackers inject malicious front-end code, with about $3 million taken from fewer than 15 accounts. Hudson Rock dates the second incident to 25 June and calls it separate from this one.
• 29 October, 17:50 to 17:56. The attacker wallet makes numerous transactions with Polymarket's prediction market token contract (BleepingComputer).
• 29 October, 17:59. Hudson Rock found a build timestamp on Polymarket's production code for a change titled "remove debugbear rum script". It notes that a build timestamp does not prove when the change reached users.
• 29 October, about 18:00. DebugBear reports an "ongoing security incident" (about 2 p.m. Eastern, per NBC News).
• 29 October, 18:05. Polymarket puts its exchange in cancel-only mode and pauses relayer actions (BleepingComputer).
• 29 October, 18:12. Hudson Rock's first snapshot of the Polymarket homepage no longer references the script. It retrieved the 15,187-byte script file twice, a minute apart, with identical contents.
• 29 October, 18:33 to 18:37. Polymarket says on X and on its status page that one of its third-party providers was compromised, that the issue is fixed and that impacted users will be made whole.
• 29 October, 19:05. Trading resumes and Polymarket marks the incident resolved (BleepingComputer).
• 30 October. Neither Polymarket nor DebugBear has published a post-mortem.

How could a monitoring script sell a user's positions?

A script loaded from a vendor runs in the visitor's browser with the same rights as the site's own code. According to the Hudson Rock analysis, the code on Polymarket looked for a logged-in trading session and then tried to sell positions and transfer assets.

In plain words, as Hudson Rock describes it ("Its central approach is to reuse authority already available in the authenticated application", quoted by SecurityWeek), and as BleepingComputer summarizes it:

1. The script read login-related data from the browser's local storage and found the page's live trading client in its own memory.
2. It reused the signing ability of that already-logged-in session. Hudson Rock found no code that sends passwords, seed phrases or private keys to an outside server, so nothing had to be stolen first.
3. It listed the account's positions and balances and, for one account type, placed sell orders at steep discounts. For the other, it moved position tokens directly. Proceeds went to a hard-coded fallback address that remote configuration could change. BleepingComputer reports that the script also talked to a DebugBear data address, used for instructions and to send data out.

Hudson Rock's analysis was static: the researchers read the code and did not run it. They say success on each victim's account cannot be proved from the code alone. This is also why the usual crypto advice does not fit well here. The script acted through the user's session, so revoking token approvals would not have stopped it.

The reach of this attack is the reach of any vendor script. Session cookies, form fields and page contents are all within the script's view on a normal page, and session cookie theft by injected JavaScript is a known route to taking over accounts. OWASP's cheat sheet says it plainly: "The single greatest risk is a compromise of the third party JavaScript server" (OWASP).

Polymarket hack myths and open questions

• "Polymarket's smart contracts were hacked." No source we reviewed says so. Polymarket and Decrypt describe a compromised third-party provider, and Hudson Rock describes front-end code.
• "It was a DNS or BGP hijack." This was early speculation on social media. No report we reviewed supports it.
• "DebugBear attacked Polymarket." Not established. Hudson Rock states that DebugBear is a legitimate vendor and that the name is not evidence of wrongdoing. DebugBear says it is itself affected by an incident, and how its script was changed is not public.
• "The loss is $2.65 million." That is the balance of one wallet that Arkham links to the attacker. GoPlus counts about $2.71 million, and Hudson Rock treats a screenshot showing about $2.19 million as unverified. Polymarket has not published a total, so treat all figures as preliminary.
• "One user lost $800,000." A claim like this circulated on X and was disputed there as possibly fake. No news source we reviewed confirms it.
• "It is the same as the June incident." Polymarket disclosed a separate third-party compromise in June. SecurityWeek and Hudson Rock treat them as different incidents.
• "Only careless users were hit." The reports describe a script that ran for logged-in sessions. Nothing in them points to user error.

What should companies check after the Polymarket hack?

After the Polymarket hack, every company that loads vendor JavaScript should check three things: which third-party scripts run on its logged-in and payment pages, who at each vendor can change them, and how fast the company can remove one. The steps below cover the detail.

Most sites load scripts from outside companies: analytics, RUM, chat widgets, tag managers, A/B testing and ad pixels. Each one can run anything the page can. This list follows OWASP, MDN and the PCI DSS script requirements. It is general information, not a substitute for your own risk review.

1. Inventory every script. List each third-party script on each page template, who owns it, why it is there and what data it can see. Include scripts that other scripts load, and tags added through a tag manager. A script nobody can justify is a script to remove.
2. Keep third-party scripts off sensitive pages. Login, account, checkout and admin pages should load as few outside scripts as possible, ideally none. Run monitoring there from your own servers or collect data through your own backend. OWASP notes that moving eligible vendors server-side reduces browser code.
3. Self-host or pin versions where the vendor allows it. A file you serve yourself changes only when you change it. A vendor URL that always serves "the latest" can change without you knowing, which OWASP lists among the main risks.
4. Use Subresource Integrity (SRI) for static files. MDN describes it as a way to let browsers verify that fetched resources "are delivered without unexpected manipulation": you put a hash in the integrity attribute, and the browser refuses to load a file that does not match (MDN). The vendor's server must support CORS, and you need the crossorigin attribute. The limit: any legitimate update changes the hash and breaks the page, so SRI suits versioned, static files. It does not fit a vendor script that is meant to change often, and OWASP says to plan for hash changes.
5. Set a Content Security Policy (CSP). The script-src directive sets which sources may run JavaScript, and the connect-src directive restricts where scripts may send data. Start with the Content-Security-Policy-Report-Only header, which reports violations without blocking, then enforce (MDN). MDN warns that 'unsafe-inline' "defeats much of the purpose of having a CSP". A CSP also cannot tell a good version of an allowed script from a swapped one, so use it together with SRI or self-hosting.
6. Review who can change the code you load. For each vendor: who can publish to the path your page loads, with which authentication, and how would you learn of a change. Ask for their incident contact. Restrict who can publish tag changes in your tag manager and review them like application code.
7. Monitor for changes. Check the scripts and headers that browsers receive, not only your source code. If you take card payments, PCI DSS v4.x requirements 6.4.3 and 11.6.1 already demand this for payment pages: the PCI Security Standards Council sums them up as "ensuring that payment page scripts are properly authorized, checked for integrity, and monitored for tampering", along with security-impacting HTTP headers. Read the standard itself for the exact wording. Even if you are out of scope, the same discipline applies.
8. Isolate what you cannot remove. OWASP describes loading vendor code in a sandboxed iframe so that it cannot reach the host page's DOM and cookies.
9. Plan the removal. Decide today who can pull a tag, how long it takes and who tells customers. Polymarket's own removal commit is a reminder that the fix is a one-line change if you can ship it quickly. Test the drill before an incident, not during.

What should Polymarket users do now?

Polymarket users should check their positions and history for trades they did not make, wait for Polymarket's official reimbursement process and treat every unsolicited "refund" message as a scam. This is general information, not financial or legal advice.

• Check your positions and history on Polymarket.com for sales or transfers you did not make, and take screenshots.
• Wait for official guidance. Polymarket says affected users will be made whole. Use only its official channels to find out how.
• Expect scams. Every incident brings fake "reimbursement" pages, "support" direct messages and phishing emails. Do not connect your wallet or enter a seed phrase for anyone who contacts you first.
• Revoking token approvals is not the core fix here. The reported attack used the logged-in session, not a standing approval. Revoking is harmless hygiene, but it does not explain or stop this attack.
• Protect the rest. Use unique passwords, a hardware security key where offered, and check whether your email address appears in stealer logs with our guide on what to do when a password is in a stealer log.

What does the Polymarket hack mean for leadership teams?

The Polymarket hack shows that a vendor with a script on your logged-in pages holds the same access as your own code, so vendor trust is a security decision for leadership, not only for engineering. Polymarket is a trading site, but the pattern is old. Vendor trust is a supply chain: our article on the ConnectWise breach shows the same shape, where a compromise at a supplier opened the way to customers. Here the supplier was a performance tool, a category few teams rate as high risk. It is also the pattern of Black October, where LiteLLM and OpenCode showed trusted suppliers turned into the route in. The same evening, the Binance hack began at an employee's computer rather than at a vendor.

Three questions for the next board or risk meeting. Which third-party scripts run on our logged-in pages today? Who at each vendor can change them? How fast can we remove one?

The incident also draws attackers' attention to the people behind affected sites. Impersonation and phishing waves tend to follow high-profile incidents, and stolen sessions and credentials from infostealer logs are one of the ways accounts are taken over without a password. That is a separate risk from the script attack, and the two should not be mixed up in reports. For the people side, CEM checks your executives' current and past email addresses against breach corpora and leak databases, and EDG3 shows what has been posted about your authorized domain on dark web forums, marketplaces and channels.

How WebThreat can help

WebThreat does not monitor websites' JavaScript, audit CSP or inspect third-party scripts. Those checks belong to your web and security engineering teams. Our part is the exposure around your people and data once something has gone wrong.

• EDG3 is WebThreat's threat intelligence for leaked data. It watches the places where stolen company data, credentials and stealer logs are posted and sold, from dark web forums and marketplaces to Telegram channels and leak databases. For a domain you have authorized, it shows what has been posted about your company, where and by whom.
• CEM finds your executives from your company name and checks their current and past email addresses against breach corpora and leak databases, ranked by what to fix first. See the methodology for how.
• Information Removal takes executives' personal data out of public view, which limits the material that follow-up phishing and impersonation are built from.

To talk through what your leadership team has exposed today, contact us.

This article reflects the sources linked above as of 30 October 2026, 17:00 UTC. Figures are preliminary, the cause of the vendor compromise has not been published, and we will update this article as Polymarket, DebugBear and researchers publish more.