Polymarket Hacked Via Third Party Script: How It Works and How to Prevent It

The October 29, 2026 Polymarket incident was a JavaScript supply chain attack: a third-party vendor's performance monitoring script was compromised, then used to drain the wallets of logged-in users. The Polymarket site itself was not hacked. That's what makes it important for every developer who installs analytics tags on their site.

The case is buzzing because it comes just hours after the $6.3 billion Binance hack, and because the cause is so mundane: a single <script src> line that was simply believed. This article explains what happens, how the attack works, myths circulating, and technical steps to prevent it on your site.

What really happened?

On Thursday, 29 October 2026 afternoon US time (early morning 30 October WIB), Polymarket users reported funds moving without permission. Polymarket then suspended trading on its international platform, Polymarket.com, and stated that "one of our third-party providers was compromised".

Polymarket did not name the vendor. However, sources cited by Yahoo News and Reuters, as well as security researchers' analysis, point to DebugBear, a British site performance monitoring company. DebugBear itself announced on

Some key facts:

• Only Polymarket.com (international) is affected. Polymarket US, a CFTC regulated platform, was not affected.
• Polymarket promised to fully compensate all affected traders for their losses and report the case to British law enforcement officials.
• Polymarket has not officially released loss figures or the number of affected accounts.

How much is the loss, and why are the numbers different?

The circulating figures come from a blockchain analytics firm, not Polymarket. The differences are natural as each tracks slightly different wallets and time windows.

The duration of withdrawal is also reported to vary. Yahoo News said trading stopped for "nearly an hour" and resumed around 3 p.m. ET. Wired, via a Slashdot summary, said "a few hours". SafeState's timeline noted the cancel-only mode started at 2:33 pm ET and the incident was marked resolved at 3:05 pm ET.

How does the attack work?

DebugBear provides RUM scripts: JavaScript snippets that are embedded in pages to measure load speed in real users' browsers. Scripts like this are loaded from a vendor's CDN, for example cdn.debugbear[.]com, and are usually updated by the vendor at any time without the need for intervention from the site owner.

According to SafeState's static analysis of compromised files, the flow goes something like this:

1. Files on the vendor's CDN are replaced. The attacker swaps the original RUM file for a malicious version. How the vendor's infrastructure was breached is not yet known.
2. Loaded in the login session. The user opens Polymarket.com, and the browser loads the script as usual, with the same privileges as Polymarket's own code.
3. Reading sensitive data. The script checks active sessions, then reads browser storage for account data, wallet addresses, and trading API credentials.
4. Execute transactions. The script looks for trading clients and signers on the page, then uses Polymarket's signed batch mechanism. There are different branches per account type: one moves position tokens, one sells assets.
5. Report to the attacker. The script contacts the vendor's data domain for instructions and sends back account details and transaction results. Funds flow to a single wallet on Polygon.

The production build commit that removed the DebugBear script was recorded at 17.59.20 UTC (00.59 WIB). SafeState insists this point only marks the end of the exposure window, not the beginning. How long the malicious file was active remains unclear.

Why can an analytics script do all that?

Because in browsers there is no concept of "guest script". Once a JavaScript file is loaded via a regular <script> tag, it runs at the site origin with full access: reading localStorage, modifying the DOM, calling application functions, and sending requests. Performance scripts that should only measure load times have the same power as the application's core code.

Is this the first time this has happened at Polymarket?

No. According to SafeState, in June 2026 the vendor's compromised script drained nearly $3 million from fewer than 15 accounts, and all victims were reimbursed. In May 2026, leaked private keys drained approximately $700K from internal top-up wallets. This recurring pattern is what makes the community question the way Polymarket manages third-party scripts.

Myth vs fact

What does this mean for developers in Indonesia?

Online shop sites, SaaS dashboards, and fintech applications in Indonesia generally contain a lot of external scripts: analytics, chat widgets, A/B testing, ad pixels, RUM. Each domain on the list is a party that can run code on your login and checkout pages. The Polymarket case shows that the losses can be direct in the form of money, not just data leaks.

1. Inventory of loaded scripts

Start with the simplest: know what's running on your page. Paste this snippet in the DevTools Console on the login or checkout page. It displays scripts from other domains along with their SRI status, including dynamically inserted scripts.

// Jalankan di DevTools Console
const own = location.hostname;
const tags = [...document.scripts]
  .filter(s => s.src && new URL(s.src).hostname !== own)
  .map(s => ({ src: s.src, sri: s.integrity || '(tanpa SRI)' }));
const loaded = performance.getEntriesByType('resource')
  .filter(e => e.initiatorType === 'script' && new URL(e.name).hostname !== own)
  .map(e => e.name);
console.table(tags);
console.log('Semua script pihak ketiga yang termuat:', [...new Set(loaded)]);

2. Lock versioned files with Subresource Integrity

SRI makes the browser reject files whose contents differ from the hash you specify. This is especially effective for fixed version libraries. Create the hash like this:

# Hasilkan hash SHA-384 untuk atribut integrity
curl -s https://cdn.contoh.com/[email protected]/lib.min.js \
  | openssl dgst -sha384 -binary | openssl base64 -A

<script src="https://cdn.contoh.com/[email protected]/lib.min.js"
        integrity="sha384-HASIL_PERINTAH_DI_ATAS"
        crossorigin="anonymous"></script>

The limitation: the RUM and analytics scripts are often updated by the vendor without notification, so the hash will keep changing and the script will stop working. For such cases, consider copying the files to your own CDN and updating them via code review.

3. Narrow it down with Content Security Policy

CSP limits where scripts can be loaded from and where pages can send data to. Direction connect-src is important to minimize the chances of exfiltration. Start with report-only mode to avoid breaking the site:

# nginx: uji dulu dengan Report-Only, lalu ganti ke Content-Security-Policy
add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' https://cdn.contoh.com; connect-src 'self' https://api.contoh.com; object-src 'none'; base-uri 'self'; report-uri /csp-report" always;

Remember, CSP is not helpful if the compromised domain is actually on the allowlist, as in this case. Therefore, the next control is actually the most powerful.

4. Clean high-value pages

Login pages, account settings, payments, and transactions do not need chat widgets or ad pixels. Remove all non-essential tags from that page. This is a direct recommendation from SafeState's analysis and the cost is almost zero.

5. Don't store secrets in browser storage

A malicious script in Polymarket reads trading API credentials from storage. Store the session token in cookie HttpOnly; Secure; SameSite to prevent it from being read by JavaScript, and require reconfirmation for high-value actions such as fund transfers. The same principle applies to API keys: never put service keys on the frontend. If you use APIPedia or another API, call it from the backend and store the key in the server environment variable.

Tips for users

• After an incident, check for active sessions and revoke any API credentials ever created.
• Reject wallet signature requests where the action is unclear or you don't expect.
• Beware of "recovery links" that come out of the blue. Official support never asks for a seed phrase.

FAQs

Will Polymarket users' funds be returned?

Polymarket stated that it would fully replace all affected traders. Until this article was written, there was no official figure for how many would be replaced.

What is a RUM script?

RUM (Real User Monitoring) is a script that measures page performance in real users' browsers, for example load time and Core Web Vitals. Because it is installed directly on the page, this script has full access like any other application code.

Can SRI prevent attacks like this?

Yes, if the vendor file is hash-locked. The browser will reject files that have been replaced. The problem is, many vendors update the script silently so SRI is difficult to use without a self-hosted and locked version.

How do I know if my site contains the DebugBear script?

Look for string debugbear in the source code and site templates, or run the inventory snippet above on the production page. DebugBear itself asks RUM product customers to remove the embedded code until the incident is resolved.

Do attacks like this only target crypto sites?

No. A similar pattern, often called Magecart, has long been used to steal card data on online store checkout pages. Crypto sites only make the impact more quickly visible because funds can be moved instantly.

Source

• SafeState: Polymarket Hack Drains $2.5M via Compromised Vendor Script
• Yahoo News: Polymarket trading halted after vendor compromise; impacted users will be "made whole"
• Slashdot (Wired report summary): Polymarket Halted International Trading After Hackers Drained Accounts
• BitDigest: technology news summary October 31, 2026