Polymarket Hit Again: Source Defense Once Again Uncovers Malware Beyond the Intended Target
Source Defense Research found the malicious script used in the latest Polymarket attack executing on another company’s website—a large global optical services provider. It echoes our investigation of an earlier Polymarket attack: code designed to drain Polymarket wallets also reached unrelated websites through a shared supplier. The latest incident turned a performance-monitoring integration into an attack channel, showing how trusted website tools can expose businesses well beyond an attacker’s intended target.
Attack details
On October 29, 2026, attackers delivered malicious JavaScript through DebugBear, a website performance-monitoring service integrated into Polymarket. According to Polymarket’s incident report, the replacement script used some visitors’ active sessions to sell positions and move funds out of their wallets. Polymarket removed the script, cleared caches, reset active sessions, and temporarily paused trading and its transaction relayer, the service that submits transactions.
DebugBear subsequently reported that its DNS records—the records directing browsers to its services—had been compromised through its domain registrar. Its initial investigation found no indication that its internal systems had been compromised. The distinction matters: attackers can hijack the delivery of a trusted script without compromising the supplier’s application itself.
From performance monitoring to wallet operations
In the sample Source Defense Research analyzed, the malicious code started automatically. It attempted to read authentication-related values from browser storage, locate trading functions inside the running application, and reuse the application’s signing functionality to authorize transactions. Users did not need to click a malicious button to start this workflow.
A script’s intended purpose does not automatically limit its capabilities. JavaScript embedded directly into a page can generally interact with that page’s content, accessible browser storage, and application functions. A tool installed to measure performance can therefore become dangerous when attackers replace its code.
The same payload, on an unrelated website
Source Defense Research also identified the infected file in a captured session on the optical services provider’s website. It arrived through DebugBear under a different filename, but its SHA-256 hash—a fingerprint of the file’s contents—matched the Polymarket payload exactly.
The capture showed the script executing and making Polymarket-specific requests. Early requests failed because of browser cross-origin restrictions, and the workflow stopped before reaching wallet operations. We found no evidence of successful theft in that session.
That outcome does not erase the exposure: the website had loaded and executed attacker-controlled code. This payload depended on Polymarket’s services and application state. A version adapted to another business could instead attempt to collect sensitive form data, alter page content, or redirect visitors.
A recurring pattern
In the earlier incident disclosed on June 25, Source Defense Research traced a Polymarket wallet-draining attack through a marketing integration to a compromised external identity library. The same malicious code also reached unrelated websites, where its Polymarket-specific workflow failed. The latest finding reinforces the distinction between whom attackers target and how far their code travels.
How Source Defense protects you
Source Defense evaluates what scripts are doing in the browser and applies protection policies accordingly. Its policy isolation controls script access to browser resources and sensitive functionality, protecting against the abuse of access that enabled this attack.
This protection addresses the behavior of the code as it runs. A familiar supplier, an approved integration, or a performance-monitoring label does not establish that a script’s current actions are safe.
How Source Defense alerts you
Source Defense would flag the script’s “using browser storage” behavior and surface its “data-sending” activity, giving security teams visibility into actions relevant to this attack.
These signals provide a starting point for investigation. Storage access and data sending can be legitimate, but their context matters: which script performed them, what changed, and whether those actions fit its expected role.
Relevant findings are available through the bell notification center, dashboard summaries, and Script behaviors, with email and webhook notifications keeping teams informed.
Key takeaways
Polymarket was the target. The exposure extended beyond it. Source Defense Research found the same attack code executing on an unrelated website through a shared integration. The absence of observed theft there reflected this payload’s dependence on Polymarket, rather than a safe delivery chain.
CSP can restrict permitted script sources and connections, while SRI can reject a changed script when an expected integrity hash is enforced. Both are browser-enforced controls, but neither replaces ongoing visibility into script behavior. WAFs and server-side monitoring operate outside the visitor’s browser, where this malicious code executed.
Continuous monitoring reveals when a trusted integration starts behaving differently. Runtime protection adds control over what that code can access and do. Together, they help prevent a supplier’s compromise from becoming an attack on your customers.
