Polymarket's Second Vendor Compromise of 2026: How a Third-Party Provider Breach Drained $2.65M From User Wallets

On October 29, 2026, Polymarket halted trading on its international platform after a security incident drained funds from users' wallets. Through its status account, the company placed the exchange in cancel-only mode and paused relayer actions. Users could cancel existing orders, but no new orders or trades would process. "Out of an abundance of caution, we have temporarily halted trading & are working to bring the platform back online," Polymarket said.

Later updates confirmed the cause in general terms: "One of our 3rd party providers was compromised, and we have referred this to relevant law enforcement." Polymarket said it had identified and fixed the issue affecting Polymarket.com, and trading resumed at approximately 3 p.m. ET, after an interruption of nearly an hour. According to NBC News, Polymarket said the attack appeared to originate in the United Kingdom and referred the matter to British law enforcement. Its U.S. platform did not appear to be affected.

The Block, citing Arkham data, estimated that approximately $2.65 million in cryptocurrency was siphoned from user wallets. Polymarket declined to comment on that figure or on the precise nature of the attack, but committed to reimbursement: "We'll make this right and are fully reimbursing all affected traders."

NBC News, citing a person familiar with the details, identified DebugBear, a website performance and analytics provider, as the suspected entry point. DebugBear acknowledged an "ongoing security incident" on X at around 2 p.m. ET. Polymarket's own statements confirm only that a third-party provider was compromised. They do not name the provider or explain how wallets were drained.

This was Polymarket's second vendor-related incident of the year. On June 25, 2026, users lost approximately $2.97 million after an attacker used a compromised third-party vendor to inject a malicious script into Polymarket's website frontend. Polymarket promised refunds then as well.

The confirmed root cause is a compromised third-party provider. Beyond that, the details are not public. Neither Polymarket nor DebugBear has explained what the attacker did with the provider's access, and no source has yet shown how funds moved from user wallets to the attacker.

Why an analytics vendor can reach user funds

Website performance and analytics tools typically work by loading a JavaScript snippet into every page of the customer's site. That script runs with the same privileges as the site's own code. It can read the page, change what users see, and call the same wallet and signing interfaces the application uses. If an attacker gains control of the script the vendor serves, every visitor to the customer's site runs the attacker's code instead.

That is precisely the mechanism behind Polymarket's June incident, where a compromised vendor was used to inject a malicious script into the frontend. Whether the October incident followed the same path has not been confirmed, and the sources do not establish that the two incidents involved the same provider or vulnerability. The sequence below is an illustrative reconstruction of how a compromised third-party script could drain wallets, not a description of the attacker's confirmed method.

<!-- The site loads a vendor's monitoring script on every page -->
<script src="https://cdn.vendor.example/monitor.js" async></script>

// 1. Attacker compromises the vendor and replaces monitor.js.
//    No change is made to the site's own code or contracts.

// 2. The script now runs inside the site's origin for every visitor.
//    It can intercept the app's own signing flow:
const original = app.requestSignature;
app.requestSignature = async (request) => {
    // Swap the user's intended action for a transfer
    // or approval that benefits the attacker.
    request = buildAttackerTransfer(request.user);
    return original(request);
};

// 3. The user sees the familiar site and approves as usual.
//    The signed request is valid, so downstream systems execute it.

// Result: funds leave user wallets without any smart contract bug.

Why the relayer was paused

Polymarket's decision to pause relayer actions alongside order matching is consistent with this kind of attack. A relayer submits transactions on users' behalf once they have signed them. If an attacker can influence what users sign, pausing the relayer is one of the fastest ways to stop malicious requests from reaching the chain while the source of the compromise is removed. This is an inference from the response, not something Polymarket has stated.

• Keep third-party scripts off pages that handle signing. Analytics and performance monitoring rarely need to run on the exact pages where users sign transactions. Removing them from trading and wallet flows, or isolating them in a sandboxed iframe on a separate origin, means a compromised vendor cannot reach the signing interface.
• Self-host and pin vendor code. Serving a reviewed, versioned copy of a vendor's script from your own infrastructure, protected with Subresource Integrity hashes, prevents a vendor-side compromise from silently changing what runs on your site. Updates then go through your own review instead of arriving live.
• Enforce a strict Content Security Policy. A tight CSP limits which origins can serve scripts and where page data can be sent. It will not stop an allowed script that has been altered, but combined with self-hosting and SRI it sharply narrows what an injected script can load or exfiltrate.
• Validate signed intents server-side before relaying. A relayer that executes whatever users sign inherits every frontend compromise. Checks on destination addresses, unusual transfer patterns, and requests that do not match a user's normal trading activity can stop malicious signatures before they reach the chain.
• Treat a repeat vendor incident as a structural signal. Two vendor-related compromises in four months suggest the problem is the number and privilege of third-party integrations, not a single bad supplier. A full inventory of every external script, what it can access, and whether it is truly needed on sensitive pages is the appropriate response.
• Show users clear, independent transaction details. Wallets and signing prompts that display the real destination and amount, decoded independently of the website, give users a chance to notice when what they are signing does not match what they intended.