What happened
The incident described in the supplied material is a client-side supply-chain attack against a prediction-market frontend. Polymarket loaded a page-speed script from an outside company identified in the headline and summary as DebugBear. That script was replaced with malicious code, which then ran on Polymarket's website in the browsers of some signed-in traders. The reported effect was that positions were sold and funds were transferred to the attackers (The Hacker News).
The activity is dated October 29. The supplied material does not establish a time of day, an end time, or whether the malicious script was served once or repeatedly during the exposure window (The Hacker News). The compromise of the third-party script and its substitution with malicious code necessarily preceded that activity, but no date is given for either event (The Hacker News).
Two financial figures are reported. Polymarket says it is refunding approximately $2.7 million to 726 affected wallets. Separately, blockchain records show cryptocurrency worth approximately $2.64 million reaching the attackers (The Hacker News). These figures measure different things: the first describes the company's stated remediation scope, while the second describes observed attacker receipts. The supplied material does not explain the difference between them, and it should not be characterized as either a rounding difference or a shortfall without further evidence (The Hacker News).
The claims can be separated by evidentiary status.
Confirmed by the supplied material: malicious code ran on Polymarket's website; it replaced a third-party page-speed script; it sold positions belonging to some signed-in traders and moved their funds to the attackers; the activity occurred on October 29; Polymarket stated that it is refunding about $2.7 million across 726 wallets; and blockchain records showed about $2.64 million in cryptocurrency reaching the attackers (The Hacker News).
Reported but not independently verifiable from the supplied material: the attribution of the script hijack to DebugBear. That attribution appears in the headline and summary rather than in a quoted technical finding, forensic report, or vendor statement included in the material (The Hacker News).
Unconfirmed or not established: the initial access vector into DebugBear's infrastructure, the identity of the operators, the exact payload behavior, the number of victims beyond the 726-wallet refund cohort, whether any funds were laundered or recovered, and whether the compromise persists (The Hacker News).
The supplied material does not describe Polymarket's specific remediation beyond the stated refund. It does not report when the malicious script was removed, whether sessions were invalidated, or whether any law-enforcement or recovery action followed (The Hacker News).
Technical analysis
The affected component was not described as Polymarket's on-chain contracts or as a private-key store. It was the browser-side execution environment of the trading frontend, reached through a third-party JavaScript dependency (The Hacker News). That distinction is central to the incident's mechanism.
In a conventional web application, the origin server is the natural trust boundary: code served from the application's own origin is treated as first-party. A third-party script breaks that assumption. Once a browser loads a script from an external host, that script executes with the ambient authority of the embedding page. It can read and modify the DOM, call application interfaces, and act on the authenticated session without crossing a separate permission prompt. The supplied material describes exactly this outcome: code delivered through a page-speed script slot sold positions and moved funds for signed-in traders (The Hacker News).
The word "signed-in" is the operative detail in the reported behavior. It indicates that the payload's capability was conditioned on an authenticated session rather than on a compromised credential store or a separately phished secret. In a web-wallet or exchange-frontend architecture, an authenticated session typically exposes the ability to construct, sign, and broadcast transactions. A script running in that context can therefore act as the trader without presenting a phishing page or requesting a seed phrase. The supplied material does not state that private keys or seed material were exposed, and it does not describe a key-extraction step (The Hacker News).
The control that failed was therefore not a cryptographic control. It was the assumption that a script trusted for performance measurement could be treated as non-transactional. Performance tooling is loaded broadly, executes early, and is expected by site operators to observe rather than act. That combination makes it a structurally attractive insertion point: it is present in authenticated sessions, and a compromise of it does not appear in the site's own code review. The supplied material does not describe the script's load position, its permissions, or whether it ran before or after the trading application initialized, and those details would materially affect feasibility (The Hacker News).
The payload's implementation is not disclosed. The supplied material contains no payload source code, hash, script URL, filename, command-and-control endpoint, or description of the API calls used. What the reported outcome does constrain is the design space: to sell a position and move funds, the payload needed to identify the victim's open positions, invoke the interfaces the legitimate frontend uses, and cause the resulting transactions to be signed and broadcast. Reusing the application's own authenticated API and signing flow would be the most economical implementation, because key exfiltration would require a separate extraction step that the supplied material does not mention. That is an inference about design constraints, not a reported finding (The Hacker News).
The supply-chain pivot is equally under-specified. The headline attributes the hijack to DebugBear, the outside company whose page-speed script Polymarket loaded (The Hacker News). The supplied material does not state how DebugBear was compromised. A compromised vendor account, a build or distribution pipeline compromise, a CDN or hosting-layer compromise, and a malicious update are all consistent with the reported facts, and none can be selected from the available material. The distinction matters operationally: vendor account takeover and build pipeline compromise imply different detection coverage and different blast-radius estimates for other customers of the same vendor.
The attacker gains described in the material are financial: the sale of traders' positions and the transfer of their funds to attacker-controlled destinations (The Hacker News). The supplied material does not establish that session tokens, wallet addresses, position histories, or other user data were collected. It also does not establish whether the 726-wallet cohort is the complete victim set or only the set eligible for refund. Both points are material to downstream risk: harvested session material would make credential rotation and token revocation part of the response, while an incomplete cohort would mean additional victims may remain undisclosed (The Hacker News).
Forced liquidation also has consequences beyond the individual wallet. Selling positions creates directional pressure on the affected markets at the moment of execution and can move prices against other holders. The supplied material provides no price data, list of affected markets, or volume figures, so the market-integrity impact cannot be quantified from it (The Hacker News).
Exploitation path
The path described by the supplied material has four stages.
First, an attacker obtained the ability to serve malicious content in place of the legitimate third-party page-speed script. The mechanism is unknown. The supplied material does not indicate whether this involved a vendor account, a build system, a distribution host, or another route, and it does not date the compromise (The Hacker News).
Second, the malicious script was delivered to browsers loading Polymarket's site. Because the script occupied a legitimate slot in the page, the substitution was not visible in Polymarket's own codebase. The supplied material does not state whether the malicious version was served to all visitors or only to a targeted subset, and it does not describe any filtering by geography, user agent, session, or wallet (The Hacker News).
Third, the payload executed inside the origin context of Polymarket's site. At this point the attacker inherited the page's authority. The relevant input or state was the victim's authenticated session and the positions and funds reachable through it. The supplied material does not disclose whether the payload read state directly from the page, queried an authenticated API, or interacted with a wallet provider interface (The Hacker News).
Fourth, the payload caused position sales and fund transfers to the attackers on October 29. The reported outcome implies that the transaction path was reachable without a separate user confirmation step, or that any confirmation mechanism was bypassed or suppressed. The supplied material does not describe the signing flow, whether hardware wallets were in use, or whether user confirmation prompts appeared. It also does not state whether the payload operated purely from injected logic or communicated with an attacker-controlled server (The Hacker News).
The blast radius described is bounded by which wallets were signed in during the exposure window and which assets those wallets could move. The supplied material does not state whether all 726 affected wallets were signed in during that window or were identified by another method, and it does not indicate whether any wallet was compromised through a second, independent vector (The Hacker News).
Evidence
The evidentiary base for this article is narrow. It consists of the headline, summary, and metadata of a single The Hacker News article by Swati Khandelwal, published on November 1, 2026 under the Cryptocurrency and Web Security categories, together with the supplied operator research report built from that material (The Hacker News). The supplied excerpt contains the article's title, byline, date, category, and site navigation, but not the article body.
What the evidence supports directly is the sequence of events as summarized: malicious code on Polymarket's website, substitution of a third-party page-speed script, sale of some signed-in traders' positions, transfer of funds to the attackers on October 29, a stated refund of about $2.7 million across 726 wallets, and an on-chain observation of roughly $2.64 million reaching the attackers (The Hacker News).
What the evidence does not include is any forensic artifact: no payload sample, no script hash, no malicious URL, no transaction hashes, no attacker wallet addresses, no count of distinct attacker addresses, no vendor statement, no Polymarket technical postmortem, and no law-enforcement or recovery report (The Hacker News).
The two financial figures should be read as separate measurements. Dividing the reported refund total by the reported wallet count yields a derived average of roughly $3,700 per affected wallet; dividing the attacker-receipt total by the same count yields roughly $3,640 (The Hacker News). These are arithmetic derivations, not reported per-victim losses. The distribution is unknown: a small number of high-value wallets could account for most of the total, or losses could be broadly spread. The averages should not be used as planning figures for expected loss per compromised session.
The DebugBear attribution is weaker than the core incident description. It appears in the headline and summary rather than in a quoted technical finding within the supplied material, and it has not been independently verified here (The Hacker News).
Detection and mitigation
Detection should be built around the three surfaces this incident pattern exposes: the third-party script inventory, the browser-side transaction path, and on-chain outflow.
Third-party script inventory and pinning. Enumerate every script loaded by trading frontends, record origin and version, and alert on changes to content hash, filename, or delivery host. The core failure was that a legitimate script slot carried illegitimate code; content pinning would have surfaced the substitution directly (The Hacker News).
Subresource integrity and CSP. Enforce integrity attributes on externally hosted scripts and restrict script-src to an explicit allowlist. These controls do not stop a compromised allowed origin, but they prevent an attacker from silently adding a new script host (The Hacker News).
Transaction-intent telemetry. Log and alert on position sales and outbound transfers initiated from a browser session, particularly bulk or near-simultaneous activity across many accounts. The described attack required the payload to invoke the application's own transaction path, and that path is observable if instrumented (The Hacker News).
On-chain monitoring. Track flows from Polymarket-related wallets to addresses not previously associated with the user, and flag sudden liquidation patterns. The reported $2.64 million reaching the attackers was visible in blockchain records, which demonstrates that the outbound leg is observable (The Hacker News).
Vendor-side controls. For any organization operating a script CDN, treat the distribution path as a production system: require signed artifacts, immutable versioning, and out-of-band verification of releases. The supplied material does not state which of these DebugBear had or lacked, so this is a general control recommendation rather than a finding about the vendor (The Hacker News).
For operators, the practical controls are to minimize third-party script count on transaction-critical pages, isolate signing and transaction construction from general page scripts, require explicit user confirmation for position liquidation and bulk transfers, and maintain a kill switch for individual script origins. The incident supports treating any script loaded on a financial frontend as part of that application's trusted computing base (The Hacker News).
What remains unproven
The public record available for this article is thin and has not been independently verified. It consists of a single secondary report and the operator analysis derived from it; no primary technical disclosure, forensic report, vendor statement, or on-chain investigation was supplied (The Hacker News).
Specifically unknown: when the third-party script was first compromised; how long the malicious version was live before October 29; when Polymarket detected it; when the malicious script was removed; when the refund program began or ended; and whether the refund was completed, partial, or still in progress as of the article date (The Hacker News). The pre-October 29 window should therefore be treated as an unbounded dwell-time problem rather than a known interval.
Also unknown: the initial access vector; the operators' identity; the payload's exact behavior and any command-and-control infrastructure; whether private keys or session tokens were exposed; the specific contracts and exchange interfaces invoked; the transaction hashes and attacker addresses; whether funds were laundered or recovered; whether the compromise persists; and whether the 726-wallet cohort is complete (The Hacker News).
The supplied material also does not support claims that Polymarket's contracts were compromised, that cryptography was broken, that a seed phrase was phished, or that the incident was fully resolved. The refund statement is a company statement about remediation scope, not evidence that the underlying vendor compromise was eradicated.
Sources
- Swati Khandelwal, "Hackers Steal About $2.7 Million From Polymarket Traders via Hijacked DebugBear Script," The Hacker News, November 1, 2026: https://thehackernews.com/2026/11/hackers-steal-about-27-million-from.html
- Riftweld Offensive Security Research Desk, "Polymarket DebugBear Supply-Chain Script Hijack: Operator Research Report," built exclusively from the supplied headline, summary, and metadata of the source above: https://thehackernews.com/2026/11/hackers-steal-about-27-million-from.html