Why
Four incidents in four months, and the interesting thing is not that they happened but that they share a root the usual threat model draws outside the boundary. On 2026-06-25 a compromised third-party vendor injected a wallet-drainer into Polymarket's frontend; about $2.94M left at least 11 wallets, the stolen pUSD was bridged from Polygon to Ethereum and consolidated into roughly 1,893 ETH, and every affected user was reimbursed — the vendor has still not been named publicly. On 2026-08-13 Trezor disclosed that its fulfilment partner ShipMonk had been breached, exposing 13,689 customers (11,742 with name, email, phone and shipping address; 1,947 partially) who ordered between 2026-05-10 and 2026-08-08 across seven countries — and ShipMonk's own root cause was a vulnerability in Metabase, a third party of the third party. On 2026-08-16 Bits of Gold, holder of Israel's first VASP licence, disclosed roughly 200,000 customers exposed through unauthorised access to a third-party support and analytics system. And back on 2026-05-22, $700,000 left a Polymarket internal top-up wallet in 5,000-POL batches every 30 seconds because a six-year-old private key was still valid. The reflex answer to the frontend case is to lock third-party scripts down with SRI and CSP, and that is exactly where the reflex fails. SRI verifies that a file matches a hash — the malicious script came from the trusted vendor's own infrastructure, so it was the expected file. CSP is a whitelist of where a script may load from — the vendor was on the whitelist. Both answer "was this script authorized?" and the attack's entire premise is that it was. The question worth building around is the one neither control asks: what is this authorized script allowed to do?
How it works
The build is an inventory and a containment test, in that order. Inventory: for one real frontend, list every third-party script and every vendor holding customer PII, and go one layer down where it is discoverable — ShipMonk's exposure arrived through Metabase, and a list that stops at direct vendors would have missed it. Capability rather than origin: for each entry, write what it could do if it turned hostile today, and for scripts make the test concrete — can it reach the wallet-signing path at all? Containment: since SRI and CSP shrink the origin set and nothing else, the thing worth prototyping is isolation — moving the signing surface into an origin that third-party JavaScript cannot address, and treating "our own page may prompt for a signature" as itself a privilege to be scoped rather than an ambient property of the site. Then the same question turned inward: a private key that has been valid for six years has a blast radius measured in years, so rotation age belongs in the inventory next to the vendors, not in a separate ops checklist. One consumer-side corollary was parked here for want of anywhere better; it now has its own card. See pick-a-signer-not-a-brand, which turns audit history, signing scheme, entropy source and fulfilment handling into a selection procedure rather than a maxim. July's Coldcard defect is the inside-the-device version of the same lesson: a 2021 build-configuration error routed seed generation to a software PRNG instead of the STM32 hardware RNG, leaving roughly 40 bits of effective entropy on Mk2/Mk3 devices, and at least 1,719 BTC — about $111M across more than 5,200 addresses — was swept once someone noticed. ShipMonk is the who-shipped-the-device version, and the leaked list is worse than it looks precisely because no key was touched: a verified roster of hardware-wallet owners with delivery addresses is raw material for targeted phishing and for the physical coercion this space calls a wrench attack, and it appears in no threat model drawn around the device.