Ep51: Polymarket Had a CSP. Here's Why It Didn't Help

Episode Summary: On October 29, 2026, a performance-monitoring script Polymarket loaded from an outside vendor was swapped for code that used logged-in traders' open sessions to sell positions and move funds out. Researchers traced the file to DebugBear, which confirmed a security incident, but Polymarket hasn't named DebugBear and the root cause is unconfirmed. Marc uses the attack to explain one thing: any outside script on your site runs with your users' full access, and a Content Security Policy is the browser rule built to limit that. He covers what a Content Security Policy is, why Polymarket's own policy still let this attack through, and why so few sites use one at all, or use it well. Key Topics Covered: How a page-speed script on Polymarket was swapped and used open sessions to move funds Why a third party script runs with the same access as your own code Why two-factor authentication doesn't stop code running inside an open session What a Content Security Policy is, and what it can and can't block Why Polymarket's policy allowed every server the malicious script used How few sites deploy a Content Security Policy, and how many policies have gaps Main Takeaways: Every outside script on your page runs with your users' full access. A Content Security Policy blocks code and connections to servers not on your list. It trusts every server that is on the list, so keep the list short. Per the HTTP Archive Web Almanac 2025, Content Security Policy adoption reached 21.9%, and about 92% of policies that set script rules include unsafe-inline, which weakens them. Start in report-only mode, list what your site loads today, cut what nobody uses, and keep outside scripts off login, donation, and checkout pages. Timestamps: [0:00] Cold open [0:32] Intro [0:55] What happened at Polymarket [1:56] Why an outside script gets full access [2:49] What a Content Security Policy is [3:28] Would it have stopped this one? [4:19] Few sites use it, fewer use it well [5:12] Your homework [5:59] Outro Loss Estimates by Source (each measured something different): Hudson Rock: about $2.19 million at the script's recipient wallet, from a screenshot, "not a verified total of stolen funds." BleepingComputer: about 28.6 million POL, "valued at roughly $2.57 million," moved to three other wallets. The Record: blockchain firms traced "more than $2.1 million." Polymarket postmortem: returning $3.9M to traders, "the $2.7M plus $1.2M to cover pause-related losses." Tools & Resources Mentioned: Paired guide on the blog: Third Party Scripts: Lessons From the Polymarket Hack (2026) Polymarket status page and postmortem DebugBear on X, incident notice (Oct 29) DebugBear on X, follow-up (Oct 29) Hudson Rock, Polymarket Breach Alert: Wallet-Draining Code Found in a Third-Party Script Ohey, Polymarket wallet drainer served from DebugBear's script CDN BleepingComputer, Polymarket halts trading after crypto-draining script breach, $2.5M traced The Record, Polymarket confirms cyberattack on third-party provider after outages MDN, Subresource Integrity MDN, Content Security Policy guide MDN, Content-Security-Policy-Report-Only header W3C, Content Security Policy Level 3 HTTP Archive Web Almanac 2025, Security chapter (Content Security Policy adoption and script-src keywords) Weichselbaum, Spagnuolo, Lekies, Janc (Google), CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy, ACM CCS 2016 W3C, Subresource Integrity This episode's audio was produced with an AI voice clone of Marc, from a script Marc reviewed and approved. --- I do hope you enjoyed this episode of the podcast. Here are some helpful resources including any sites that were mentioned in this episode. -- Listen and subscribe: https://bytesizedsecurity.show/listen -- Support ByteSizedSecurity (501(c)(3)): Donate via GiveLively -- Questions or tips: email marc@bytesizedsecurity.show (subject: Byte-Sized Security). TikTok: @bytesizedsecurity