DebugBear's DNS got hijacked, and the entry point for a $2.7 million theft was a tag marketing teams installed

Hackers hijacked the DNS records of DebugBear, a web-performance monitoring vendor widely embedded by SEO and marketing teams, and used that access to swap its tracking script on one customer's site, the prediction-market platform Polymarket, draining roughly $2.7 million from signed-in traders before anyone could respond.

The incident, first reported by Search Engine Journal and independently confirmed by The Hacker News, started on October 29. DebugBear sells real user monitoring, a small script that times page loads and Core Web Vitals for marketing and SEO teams who want performance data without engineering overhead. According to a statement DebugBear posted, its DNS records were compromised through its domain registrar, not through a break-in to its own systems. Only one customer's copy of the script was swapped: DebugBear serves a separate file to each client from Google Cloud Storage, and attackers redirected just Polymarket's version.

What changed

Per The Hacker News' reconstruction, the swapped script reused the browser session of any trader already signed in, reading account details and trading API keys without needing a password, seed phrase or private key. Wallet-login accounts had positions moved directly; email-login accounts had positions sold at progressively worse prices before funds moved out. Blockchain tracing found the attacker's wallet collecting tokens and positions from 33 wallets between 17:10 and 18:02 UTC, worth about $2.64 million at the time.

Polymarket says it removed the script "within the hour," cleared caches, reset active sessions and paused trading until the site was clean. It is refunding about $2.7 million across 726 wallets, with 689 made whole within a day, plus another $1.19 million to roughly 5,500 wallets affected by the trading halt, for $3.9 million returned in total. The malicious address had no DNS record left when The Hacker News checked it on November 1, and Polymarket says it referred the case to law enforcement and plans to add a stronger content security policy, pinned script versions and sandboxing for third-party code going forward.

Why this is a marketing problem, not just a security one

RUM, analytics, tag managers, heatmaps and A/B-testing snippets are the kind of third-party code marketing teams add to a site directly, often through a tag manager, with no security review beyond whether it loads fast. That is exactly the category DebugBear sits in, and exactly why this incident matters here: the vulnerable surface was not a login form or a payment API, it was a performance widget someone on the growth team installed to chase Core Web Vitals scores.

Polymarket was not running crypto-specific software when it got hit, it was running the same kind of third-party script that sits on thousands of SaaS marketing sites, SEO dashboards and app shells. Any product with signed-in users and sensitive account actions, billing, API keys, admin settings, carries the same exposure if a vendor's DNS, registrar account or CDN gets taken over. The attacker here did not need to breach the target's own code at all, only the vendor's domain settings.

The timing is not reassuring. In the same week, CircleID reported a separate campaign that hijacked the DNS of at least twelve other crypto sites at the registrar level, redirecting visitors to wallet-draining pages. The two incidents are not linked and use different techniques, but together they show that domain registrars, not just application code, are now a live attack surface for anything a marketing team hands a DNS record to.

What a software marketer should do differently

This lands on whoever owns the marketing tech stack, not just security, because that is usually who added the script in the first place and who holds the vendor relationship. Most B2B SaaS products have a logged-in account area, and most of them load at least one third-party script there for analytics or support.

• Inventory every tag-manager and analytics script running on account, billing and settings pages, not just the public marketing site.
• Push for a Content Security Policy and Subresource Integrity on any script that can be pinned to a known file hash, so a swapped file simply fails to load instead of running.
• Treat a vendor's own account security, registrar MFA, DNS monitoring, who can change their nameservers, as a vetting question before you add their snippet, the way you would vet a payment processor.
• Build an incident playbook for a marketing vendor you embed getting compromised, since the fix is a code change on someone else's domain, not a password reset for your own team.

Security researcher Hudson Rock, whose analysis of the malicious file is cited by The Hacker News, told site owners to keep unneeded third-party code off any page where users trade or sign something, and to check what a logged-in page's scripts are able to ask a signer to approve. That advice applies just as well to a SaaS admin console as to a trading platform.