The Third-Party JavaScript You Approved Is Now a Trading Desk

Polymarket's $3M front-end compromise is a vendor-review problem, not a crypto problem.

The bottom line

On June 25–26, a compromised third-party front-end vendor injected malicious JavaScript into Polymarket’s site and drained roughly $3M by manipulating client-side transactions. The smart contracts were untouched. Every AppSec program that treats “vendor review” as a contract-and-SOC-2 exercise, and every SOC 2 vendor list that stops at backend SaaS, just failed a real-world test.

What changed

Polymarket disclosed the incident on June 25–26, 2026. According to reporting compiled by Veracode’s CISO briefing, the attackers did not touch the on-chain smart contracts. They compromised a third-party vendor whose JavaScript loads into the Polymarket site, injected code that manipulated user transactions in the browser, bridged about $3M to Ethereum, and were contained after Polymarket issued full refunds (Veracode CISO Executive Briefing, July 8 2026).

The pattern is not new. Magecart-style skimmers hit e-commerce sites for years. What is new is the audience — a fintech-adjacent platform with a mature security posture — and what it demonstrates about how most enterprises actually govern their front end. The place attackers found leverage is the same place most SOC 2 programs draw a blank: the marketing, analytics, chat, session-replay, and A/B-testing scripts that load into the customer’s browser from domains no one on the security team explicitly approved this quarter.

If your company sells software, the equivalent question is direct: what code runs in your customer’s browser next to your login form? Who approves each origin? When was that list last reviewed?

The decision

Whether the security team owns approval for every domain that runs code in the customer’s browser — including analytics, chat, A/B testing, marketing pixels, session replay, and CDN-hosted UI libraries — or whether marketing, growth, and product each keep quietly adding origins on their own.

This is not a debate about tooling. It is a question of control ownership. In most B2B SaaS companies, the front-end script list is a legacy of Google Tag Manager tags added over five years, and no one has produced a full inventory since. When a customer sends the annual security questionnaire, someone in security answers “yes, we review third parties” and the question moves on. That answer is defensible only if the review actually covers browser-executable code.

[[AMIR: add a brief first-hand observation about the last time a customer questionnaire actually asked about third-party front-end JavaScript versus SaaS subprocessors — worth naming the gap]]

The control test

What should be true operationally:

• A single named owner — typically application security — is accountable for the list of origins that can execute JavaScript on production surfaces.

• A written policy specifies that new front-end scripts require security review before they go into Tag Manager or the codebase, and that marketing cannot add domains unilaterally.

• Content Security Policy (CSP) runs in enforce mode with an explicit allow-list of origins, not unsafe-inline and not a catch-all wildcard.

• Subresource Integrity (SRI) hashes are set on third-party script tags where the vendor supports pinned versions.

• CSP violation reports are collected, triaged, and closed. A new domain appearing in report-only telemetry generates a ticket.

• The allow-list is reviewed on a defined cadence — quarterly at minimum, with a mandatory review when a new vendor is added or a vendor changes hands.

• Exceptions to the policy have a written approver, an expiration date, and a compensating control.

The controls above are what “we manage third-party JavaScript” actually looks like. Anything softer is a policy statement without a control.

The evidence test

An auditor, a customer, or a board member asking whether this control is real should be able to see:

• The current CSP header from production, retrieved live, with a legible allow-list.

• The SRI hash strategy documented, and a spot check confirming the hashes match what production is serving.

• A ticket showing the last time a marketing pixel or analytics vendor was approved by security, with the approver’s name and date.

• The diff of allowed origins over the last 90 days, so a reviewer can see what was added and who approved it.

• A dashboard or export from browser telemetry (a report-uri endpoint or a service that aggregates CSP reports) showing violations recorded, investigated, and closed.

• The last quarterly review meeting minutes with participants and decisions.

• The exception register with any temporary allow-list entries and their expiration dates.

Weak evidence looks like a screenshot of Google Tag Manager, a policy PDF that mentions “third-party scripts” once, and no ticketing trail. That is a policy, not a control. It does not survive a determined questionnaire and it will not survive a Polymarket-style incident.

Ask this at your next meeting

1. Who on our team approves a new domain running JavaScript on our production website, and where is the record of that approval?

2. When did we last audit the full list of origins in our CSP, and how many of them are still in active use with a current owner?

3. If a marketing vendor whose script loads on our checkout page is compromised tonight, how do we detect it, and what is our containment timeline?

Three signals worth watching

1. CISA KEV additions concentrated in web-facing enterprise software. The July 7, 2026 KEV update added four actively exploited flaws including Adobe ColdFusion (CVE-2026-48282, CVSS 10) and Langflow (CVE-2026-55255), with Langflow being exploited to steal LLM provider and cloud credentials embedded in customer flows (Help Net Security, July 8 2026). The pattern — application-layer boundary crossings that ride “blessed” execution paths — is the same class of failure as the front-end vendor compromise.

2. Client-side supply chain is now a documented cash-out vector, not a hypothetical. The Polymarket loss demonstrates that a compromise below the smart-contract layer can be economically material even when core systems are pristine. Expect procurement teams and cyber insurance underwriters to add front-end vendor questions to their next questionnaire.

3. SEC 8-K disclosures continue to name third-party contractor compromise as the initial vector. AdaptHealth’s July 2, 2026 8-K described social engineering of a third-party contractor leading to cloud application access and exfiltration of PII, PHI, and insurance billing credentials (Board Cybersecurity incident tracker). The specific vendor changes; the shape of the disclosure does not.

Sources

1. Veracode CISO Executive Briefing, July 8, 2026 — https://www.veracode.com/blog/supply-chain-compromises-from-june-and-july-2026/

2. Help Net Security, “Attackers using Langflow flaw for credential harvesting (CVE-2026-55255),” July 8, 2026 — https://www.helpnetsecurity.com/2026/07/08/langflow-vulnerability-cve-2026-55255-exploited/

3. The Hacker News, “CISA Adds 4 Actively Exploited Adobe, Joomla, and Langflow Flaws to KEV,” July 8, 2026 — https://thehackernews.com/2026/07/cisa-adds-4-actively-exploited-adobe.html

4. Board Cybersecurity Incident Tracker (AdaptHealth 8-K, July 2, 2026) — https://www.board-cybersecurity.com/incidents/tracker