“But it may be easier for an attacker to simply hack into your registrar account or other platform that has the ability to manipulate your domains, and hijack them.”
— Mark E. Jeftovic, Managing Mission Critical Domains and DNS, “Protecting your domains from unauthorized manipulation.” [6]
On October 29, 2026, that risk reached Polymarket’s customers through a service meant to measure website speed. The service, DebugBear, supplied a monitoring script that ran in visitors’ browsers. An attacker replaced it with code aimed at traders who had Polymarket open. According to Polymarket, the code used some users’ active sessions to sell positions and move funds from their wallets. [1]
The problem led back to the domain used to deliver that code. DebugBear later said its DNS records had been compromised through its registrar. It hadn’t found signs that attackers had entered its internal systems, though its investigation was still open. The company also said it could no longer receive email at its domain. [2]
Take this as a warning about what your website depends on. You can protect your own servers and still load code through a supplier’s domain. If someone redirects that domain, they may be able to change what your customers’ browsers receive without touching your servers.
To see where that risk enters the business, we’ll follow the public evidence from the reported losses through the response. Some details remain unknown, including how attackers gained registrar access. This case study reflects findings available on November 2, 2026.
The Financial Impact
Polymarket put compensation at $3.9 million. Of that, $2.7 million covered direct losses, while $1.2 million covered additional losses tied to the trading pause. In its October 30 update, the company said 95% of affected wallets had been refunded by that afternoon. [1]
The extra compensation shows how the damage can spread beyond stolen funds. When trading stops, customers can’t act while prices move. The business also has to investigate, answer customers’ questions and restore service. The sources reviewed didn’t give a total for those operating costs.
How the Attack Reached Customers
The starting point is DNS, which tells a browser where to find a website or file. If an attacker changes that destination, the browser can request a familiar script and receive malicious code instead. DebugBear said the compromise happened through its registrar, but it didn’t identify the exact records changed. [2]
What arrived in the browser helps explain the losses. Hudson Rock researchers examined a malicious file served from a DebugBear address. It looked for trading tools and signing functions already available in the user’s Polymarket session, then checked holdings and attempted sales or transfers. In that sample, researchers found no routine that sent passwords, seed phrases or private keys to its reporting server. [3]
That finding has limits. Hudson Rock read the code without running it, so the analysis shows what the file attempted to do. A request for a signature doesn’t prove that a wallet approved it or that a transfer succeeded. The sample therefore explains part of the attack, rather than every action taken against every user. [3]
Even with those limits, the lesson for website owners is clear: a script installed to measure page speed may be able to reach much more than timing data. Before adding one to a trading or payment page, check what it can read and which functions it can call.
Incident Sequence
The records below help put those findings in order. All times are UTC. They show parts of the incident and response, but they don’t establish exactly when the attack began or when every customer stopped being exposed.
- October 29 at 16:54 — Ohey found an archived error showing that the server behind the script host wasn’t responding. [4]
- October 29 at 17:10 — Ohey recorded the first POL transfer to the recipient in the transactions it traced. That dataset may not include every affected account. [4]
- October 29 at 17:38 — Polymarket acknowledged unauthorized wallet activity on its incident page. [1]
- October 29 at 17:59 — A Polymarket software build recorded removal of the DebugBear script. Hudson Rock noted that the timestamp alone doesn’t prove when the change reached all users. [3]
- October 30 — Polymarket published its response and compensation update. DebugBear reported the DNS compromise through its registrar. [1, 2]
- November 2 — Source Defense reported finding the same malicious code on an unrelated optical-services website. The finding shows that the code reached another business, but doesn’t prove that business lost funds. [5]
How Polymarket Responded
Once Polymarket identified the problem, its response went beyond removing the script. The company said it also cleared cached copies, paused trading and the service that submits transactions, and reset active login sessions. It then outlined stronger checks for outside scripts. [1]
Those steps address a problem that a DNS correction alone won’t fix: code can remain active in an open browser tab after the destination changes back. A response plan therefore needs a way to stop harmful actions and end exposed sessions. Test those steps beforehand, including who can authorize a trading or payment pause.
What We Still Don’t Know
The response gives us useful lessons, but it doesn’t answer every question about the breach. The evidence reviewed doesn’t explain how attackers gained registrar access, which account controls failed, or how DNSSEC was configured. The attackers’ identity and the full reach of the attack also remain unresolved. DebugBear initially described one customer as the target. Source Defense’s later finding suggests the code travelled beyond that target, even though losses elsewhere haven’t been established. [2, 5]
Protect the Accounts that Control DNS
That uncertainty brings us back to Jeftovic’s warning. In the chapter quoted at the beginning, he separates two jobs:
- Checking DNS answers.
- Protecting the accounts that can change DNS answers.
His advice on account access, multifactor authentication, change alerts and registry locks supports the second job. These controls help restrict who can make changes and reveal when changes occur. But they also need a workable emergency process: as Jeftovic notes, stronger locks can slow an urgent nameserver move. [6]
Where DNSSEC Helps
The first job (checking DNS answers) is where DNSSEC comes in. It uses digital signatures to verify those answers, but it doesn’t inspect the website code they lead to. It also can’t tell whether a change made through a compromised account reflects the owner’s wishes. If attackers control the relevant management and signing systems, harmful changes may still carry valid signatures. [6, 8]
DNSSEC can still help when its chain of trust remains intact. Validating services can reject a false destination that lacks the right signature. Whether that works depends on what attackers can change, including the parent’s DS record, which links the domain to its trusted key. We don’t have those details here, so we can’t say DNSSEC would have prevented this attack.
Questions for Your Next Security Review
The useful response is to review both domain control and the code your website loads. These questions give the team a place to start:
- Who can change where your domain points? Check registrar accounts, DNS accounts, API access and support recovery. Name the people responsible and confirm which approvals the provider enforces. Don’t assume a domain transfer lock also stops DNS edits. [6]
- Which outside scripts run on sensitive pages? List the scripts on login, payment and trading pages, then remove those you don’t need. Where practical, use Subresource Integrity, which checks a file against an approved digital fingerprint. You’ll also need a process for reviewing updates and configuring access when files come from another domain. [7]
- Can staff respond if the normal domain fails? Keep a separate route for emergency communications and account recovery. Then practise disabling a supplier’s code, ending exposed sessions and notifying customers. Give each task a named owner so staff aren’t sorting out responsibilities during the incident.
These checks also need to account for scripts from approved suppliers. A Content Security Policy can limit where scripts load from, but allowing a familiar address doesn’t verify each file’s contents. Pair those restrictions with content checks and isolate outside code where possible. [3, 7]
Review Your Domains and Suppliers
You don’t need to wait for another incident to begin this review. Start with your domain list and the outside services used on customer pages. Ask each critical supplier how it protects registrar access and approves DNS changes. At the same time, make sure your team knows how to remove that supplier’s code quickly.
For the domains you manage, DomainSure offers user roles and permissions, hardware-key authentication, account recovery and lock-release security, and DNS change alerts. It also provides managed DNS with DNSSEC through easyDNS. Coverage varies by plan; Enterprise includes third-party DNS checks. [9]
Those services help protect domain controls and make changes visible, while your application team reviews the code running in customers’ browsers. Bring your domain list and outside-script inventory to DomainSure’s sales team. Ask the questions this incident raises: who can make critical changes, which events trigger alerts, and how will your team respond if company email stops working?
Discuss your domain controls with DomainSure
Sources and Scope
Research cutoff: November 2, 2026. The report separates company statements, researchers’ observations and our recommendations. DebugBear’s statement is cited through news reporting because its original X post could not be retrieved directly. Findings may change as investigations continue.
1 Polymarket incident page and October 30 postmortem
2 SecurityWeek reporting of DebugBear’s statement November 2
3 Hudson Rock technical analysis October 29
4 Ohey script and transaction reconstruction October 29
5 Source Defense additional payload observation November 2
6 Mark E. Jeftovic, Managing Mission Critical Domains and DNS. Supplied project PDF: “Securing Your Domains and DNS,” particularly “Protecting your domains from unauthorized manipulation” and the subsequent account-security and lock sections. PDF page numbering is file-page numbering.
8 Cloudflare DNSSEC explanation
9 DomainSure services and protection levels
Apply for a Domainsure Invite
Get a Free Domain Health Check
Due to high demand: allow up to 24 hours for report delivery.
