I'm a few days late on this, but two incidents from the end of last week deserve to be read together, because they share a lesson most security programs skip: the domains your website trusts are part of your attack surface, including domains you don't own.
What Happened
Polymarket and DebugBear. On October 29, Polymarket's website was loading a page-speed monitoring script from DebugBear, a legitimate performance monitoring vendor. Attackers swapped that script for wallet-draining code. Because it ran inside logged-in sessions, it could find accounts, pick assets and move them out. Polymarket said "one of our 3rd party providers was compromised," removed the script, paused trading, and has been reimbursing affected users. DebugBear told customers to remove its embed code and later said its DNS records were compromised through its domain registrar, with no evidence its own systems were breached.
Twelve crypto sites in a day. Over October 30 and 31, Blockaid flagged a DNS hijacking campaign hitting at least 12 crypto sites, including Flap and Kintsu, that sent visitors to a drainer kit. Kintsu said its domain was hijacked at the registrar level. Nobody has confirmed a common root cause, and nothing ties this campaign to the DebugBear incident yet, so I won't pretend otherwise.
The Pattern
Nobody broke into Polymarket. Nobody breached DebugBear's servers either, per DebugBear. The attacker went after the thing that tells the internet where DebugBear's script lives. Change that, and every site that loads the script runs your code, inside its users' authenticated sessions.
Think about how many of those you have. Analytics, tag managers, chat widgets, A/B testing, performance monitoring, consent banners. Each one is a domain you trust with full JavaScript access to your users' pages, and each domain sits on a registrar account, behind a login, possibly behind an email address someone stopped watching years ago. This isn't a crypto problem. Crypto just makes the payoff immediate and public.
What To Do
If you run a website:
- Inventory every third-party script on pages where users are logged in or move money. Remove the ones nobody can justify. A performance tool doesn't need to run on your checkout page.
- Pin what you can. Use Subresource Integrity hashes for static third-party files, or self-host them. A swapped script with a mismatched hash simply won't load.
- Lock down Content Security Policy so pages can only load scripts from the sources you expect, and monitor CSP violation reports.
- Isolate sensitive actions. Keep third-party code off the pages that sign, pay or change account settings.
For your own domains:
- Turn on registrar lock and registry lock where your registrar offers it, and protect the registrar account with phishing-resistant MFA.
- Monitor your DNS for changes you didn't make. A changed nameserver or A record should page someone.
- Use DNSSEC where your stack supports it.
For users: if a site you trust suddenly asks you to approve a strange transaction or "reconnect" a wallet, stop. Revoke unfamiliar wallet approvals, and check the service's official channels before doing anything.
Bottom Line
Your website's security is now the weakest registrar account among all the vendors whose scripts you load. Treat third-party JavaScript like third-party code running in production, because that's exactly what it is.
Sources: The Record on Polymarket, The Hacker News on the DebugBear script, and CircleID on the crypto DNS hijacking campaign