The Polymarket incident of 25–26 June 2026 is the cleanest available demonstration of a point the industry keeps refusing to internalise: the browser is production, and your third-party scripts are privileged code running inside it.
What happened
Per Veracode's CISO briefing, attackers compromised a third-party vendor and used that access to inject malicious code into Polymarket's website frontend. The injected code manipulated users into approving fraudulent transactions. Approximately $3 million in cryptocurrency was drained.
The smart contracts were unaffected. Not "not the primary target" — unaffected. Every line of the on-chain logic that had been audited, formally verified, bug-bountied, and reviewed continued to execute exactly as specified.
It did not matter, because the attacker was not attacking the contract. They were attacking the moment the user decided what to sign.
The asymmetry nobody budgets for
Consider how a crypto-adjacent company typically allocates security spend:
- Smart contract audits: multiple firms, six figures, before every major release
- On-chain formal verification: substantial engineering investment
- Bug bounty: significant contract-focused payouts
- Frontend: shipped by the product team, with whatever analytics, session-replay, A/B testing, error-tracking, support-widget, and consent-management scripts marketing and support asked for
Every one of those third-party scripts runs with full DOM access in the same origin as the interface where users authorise transactions. Any one of them can read what is displayed, alter what is displayed, and modify what gets submitted to the wallet for signing. There is no privilege boundary between "the session replay tool" and "the transaction confirmation screen." They are the same execution context.
This is not a web3 problem. Substitute "approve a wire transfer" for "sign a transaction" and it is a banking problem. Substitute "enter card details" and it is Magecart, which has been running the same play against e-commerce for the better part of a decade. Substitute "submit patient information" and it is a HIPAA problem.
The vector is old. What is new is how many third parties are in the average page, and how few organisations can even list them.
The vendor is the perimeter
Note the entry point: a third-party vendor was compromised, and that compromise became frontend code execution.
This is the part that makes it a supply chain incident rather than a web security incident. Nobody breached Polymarket's infrastructure. They breached something Polymarket had chosen to trust, and trust was implemented as <script src="https://vendor.example/thing.js">.
That tag is a standing grant of arbitrary code execution to whoever controls that hostname, renewed on every page load, forever, with no version pinning, no integrity check, and no review of what changed. If you would not merge a pull request from that vendor without reading it, you should not be loading their script without an integrity hash.
What actually stops this
Content Security Policy, enforced and narrow. A CSP that restricts script-src to an explicit allowlist — no unsafe-inline, no unsafe-eval, no wildcard CDNs — means an injected script from an unexpected origin does not execute. Most production CSPs are either in report-only mode indefinitely or so permissive they permit anything.
Subresource Integrity on every third-party script. SRI pins a cryptographic hash of the exact file. If the vendor's file changes — because they shipped an update, or because they were compromised — it fails to load rather than executing silently. The objection is always "but the vendor updates their script and SRI would break it." That is not a bug. That is the control working: you find out that third-party code in your transaction flow changed, before your users do.
Self-host and pin what you can. Analytics and tag managers do not need to be loaded from the vendor's CDN.
Behavioural monitoring of third-party scripts. Watch what the scripts on your page actually do — what they read, where they send it. Real-time client-side monitoring catches the injection that got past the static controls.
Ruthless inventory reduction. The most reliable control is fewer scripts. Every third-party tag is a permanent code-execution grant; the question for each is whether the marketing value exceeds that.
A signing-surface integrity check. For anything transaction-adjacent: verify at signing time that what the user is authorising matches what was displayed, ideally outside the compromised context (hardware wallet display, out-of-band confirmation).
How Safeguard helps, at scale
Client-side dependencies in the same SBOM as everything else. Safeguard's continuous CycloneDX and SPDX SBOMs cover frontend dependencies and third-party scripts, not just server-side packages and containers. For an organisation running dozens of web properties, "which of our sites loads this vendor's script, and on which pages" is a question almost nobody can answer today — and it is the first question asked when a vendor is compromised.
Third-party risk management, wired to the code. Safeguard's TPRM connects vendor risk posture to actual technical exposure — so the vendor whose script runs on your checkout page is prioritised above the vendor whose logo is in a footer. Most TPRM programmes are questionnaire exercises disconnected from where the vendor's code actually executes. That disconnection is precisely what turned a vendor compromise into $3M.
First-party DAST against real deployed pages. Safeguard's DAST tests running applications, including authenticated flows — surfacing missing or permissive CSP, absent SRI on third-party scripts, and injection paths in the delivered page rather than only in source. Static analysis of your repository cannot see that a script tag was added to a page via a tag manager by someone in marketing.
Griffin, for the fixes that are mechanical but tedious at scale. Adding SRI hashes to every third-party script across 40 web properties, tightening a CSP without breaking pages, self-hosting a pinned vendor bundle — Griffin authors and tests those PRs through your normal merge gates. This is exactly the class of work that stays permanently in a backlog because it is individually small and collectively enormous.
Eagle, for prioritisation that reflects blast radius. Eagle reasons about exploitability in context, so a permissive CSP on a transaction-signing page ranks above the same finding on a marketing microsite. At scale — thousands of findings across dozens of properties — that ordering is the entire value.
Continuous monitoring rather than point-in-time. The vendor's script that was fine at your last audit is a different file today. Safeguard's continuous scanning treats third-party frontend code as a changing input, which is what it is.
Audit your contracts. Then go and list every third-party script on the page where your users authorise money movement, and check how many have an integrity hash.
Sources: Veracode: Supply Chain Compromises from June and July 2026 · CM Alliance: Biggest Supply Chain Attacks of 2026
