Polymarket Got Robbed Through Somebody Else's Security — Twice in a Month. This Time the Lie Was in Your Browser at the Instant You Hit Sign.
- Patrick Duggan
- 6 minutes ago
- 5 min read
Here is the sentence that should change how you think about web security in 2026. Polymarket did not get hacked. A company you have never heard of, that Polymarket pays to load a piece of code into its website, got hacked. And because your browser trusts Polymarket, and Polymarket trusted that vendor, the attacker's code got to run in your browser wearing Polymarket's name. When you went to sign a routine trade, the page lied to you about what you were signing. Your wallet did exactly what you told it to do. You just did not know what you were telling it.
That is the whole attack, and it cost users close to three million dollars on June 25. I want you to understand it, not just file it, because this is the second time in about a month that Polymarket got robbed through someone else's security, and the second one is a different and worse animal than the first.
Walk the trust chain with me, because the trust chain is the vulnerability.
You trust polymarket.com. You typed it yourself, the TLS padlock is green, the domain is correct. That trust is well placed and completely irrelevant, because a modern web app is not one program from one company. Polymarket's frontend, like nearly every site you use, pulls in third-party code at load time: analytics, error monitoring, feature widgets, dependency libraries. Each of those is a company, and each of those companies is a door into your browser session on Polymarket's origin. Polymarket trusts those vendors. You inherit that trust whether you consented to it or not. According to Polymarket and the reporting from BleepingComputer, Cybernews and TechCrunch, one of those vendors was compromised, and the attacker used that access to inject malicious JavaScript into Polymarket's frontend for a subset of users.
Now the mechanism. The injected script did not steal passwords and it did not break any cryptography. It sat in the page and waited. When a victim connected their wallet and went to do the most normal thing in the world on a trading platform, approve a transaction, the script swapped what the wallet was being asked to sign. The user saw a trade. The wallet, doing its job perfectly, signed what the page handed it: an authorization to move funds out. The target was PUSD, the USDC-backed collateral token that every trade on Polymarket runs on. The attacker then bridged the proceeds from Polygon to Ethereum and converted them into roughly 1,893 ETH, consolidated into a single address. Security researchers tracked the losses across fewer than fifteen accounts and totaled them at just under three million dollars.
If that mechanism sounds familiar, it should. This is Magecart, the credit-card skimming class that has been hitting e-commerce checkout pages for a decade by injecting a script through a compromised third-party dependency. The structure is identical. What changed is the payout and the finality. A Magecart skimmer steals a card number, and a card number is a reversible instrument. You call the bank, you dispute the charge, the money comes back. A signed on-chain transaction is the opposite of that. There is no chargeback in self-custody. The 1,893 ETH left and stayed left. The only reason these victims are getting made whole is that Polymarket chose to eat the loss, contained the bad dependency within about fifteen minutes of the first public report, and pledged full refunds. That is a genuinely good incident response. It is also Polymarket paying out of pocket for a vendor's failure, which is exactly what indirect trust costs when the bill comes due.
Now the part I actually care about, the pattern.
On May 24 I sat down and wrote that the criminal marketplace had crossed into operational use of what I called indirect-trust vectors, and I named three that had landed in three weeks: the Laravel-Lang tag-pointer compromise, the Megalodon GitHub Actions workflow poisoning, the Ghost CMS theme execution primitive. Six hours later our own extractor surfaced a fourth while I was back-filling adversary profiles, and it was Polymarket, the first time, a malicious bot stealing wallet keys through a hijacked verified GitHub organization. Two days after that, over Memorial Day weekend, TeamPCP gave us the fifth when they breached GitHub itself and turned a VS Code extension into the delivery vehicle. I have been counting these out loud all spring because the count is the argument. This frontend-vendor hit is the sixth indirect-trust vector, and it is the same victim as the fourth.
Sit with that. Polymarket got hit twice in a month, and not once was the front door Polymarket's. The May incident came through the code-supply layer, a poisoned GitHub org feeding the build. The June incident came through the runtime-delivery layer, a poisoned vendor feeding the live page. Same brand, two completely different rooms of the same house, both rooms owned by somebody else.
And here is the escalation that makes the sixth one matter more than its number suggests. The first five vectors all hit developers. The artifact layer, the workflow, the IDE, the build, the org. The audience that got robbed was people who write software. This one reached past the developer entirely and weaponized the same indirect-trust structure against the end user, at runtime, in the browser, at the single most dangerous moment in the entire crypto user experience: the instant you approve a transaction. The doctrine moved downstream from the people who ship the code to the people who click the button. That is a much larger blast radius, because there are a thousand users for every developer, and not one of them can read the JavaScript running on the page they are signing from.
So what do you actually do, on both sides of the screen.
If you run a site, the frontend is now a backend-grade attack surface and you have to treat it like one. Pin your third-party dependencies to specific versions and specific hashes. Use Subresource Integrity so the browser refuses to execute a script whose contents changed out from under you, which is precisely the move that breaks this attack. Run a strict Content-Security-Policy that whitelists exactly which origins are allowed to execute, so a compromised vendor cannot quietly add a new exfiltration destination. Inventory every single third party your page loads, because you cannot defend a dependency you forgot you had.
If you are a user, the defense that would have saved these fifteen wallets is a signing experience that tells you the truth regardless of what the page claims. Use a wallet that simulates and previews transactions, that shows you in plain language "this will move fifty thousand PUSD out of your account" before you approve, not just an opaque blob of hex. When the preview and the page disagree, the page is lying. Slow down at the signature. The signature is the whole game.
I will give you the honest 95 percent. Subresource Integrity and a tight CSP defeat this specific technique, but they do not defeat a vendor who ships a malicious update through a legitimately versioned release, and transaction-preview wallets only help the users who actually read the preview. There is no setting that turns off indirect trust, because indirect trust is not a bug, it is how the modern web is assembled. The whole stack is built on running other people's code, and every one of those other people is a door. The CFTC, for what it is worth, is reportedly deepening its look at Polymarket, and the regulatory question of who is liable when your vendor's breach drains your user's wallet is going to outlast this news cycle by a long way.
The lesson is the one I keep writing because attackers keep proving it. You can harden your own house to perfection and still get robbed through the wall you share with the neighbor. Polymarket just proved it twice. Go count your own walls.
The threat feed this post is built on
1.14M+ IOCs, STIX 2.1, precursor signals, supply-chain detection. Free API key in 30 seconds.