DNS hijack hits Polymarket; about $3.9M in trader funds returned

Key points

• An unknown actor tampered with domain-name system entries connected to Polymarket.
• DebugBear and a registrar are part of the incident and response chain.
• The impact was limited to one customer rather than a broad outage.
• Close to $3.9M in trader capital was restored and refunds were processed.

An unknown party tampered with domain-name system entries associated with Polymarket, according to the incident facts. The trail also touches DebugBear and a registrar, suggesting the response required coordination across monitoring and registration providers. The result was a domain-resolution compromise rather than a malware outbreak or software flaw; no CVE was assigned.

The immediate effect was narrow. Only one customer was singled out, and the facts do not describe a broad service outage or a large set of victims. Even so, DNS manipulation is high-impact because it can redirect users, intercept credentials, and undermine trust in a brand’s normal web presence.

Financial remediation is part of the picture. Roughly $3.9M connected to traders was sent back, and refunds were processed. Returning capital quickly reduces secondary disputes, but it does not by itself explain how the records were changed or whether account access was exposed.

For K-12 and government defenders, the lesson is that registrar and DNS controls are identity infrastructure. A compromised domain can affect email, authentication, and public communications even when internal endpoints are clean. Vendor concentration and delegated DNS administration deserve the same scrutiny as endpoint tooling.

Watch for registrar audit logs, unexpected record changes, and monitoring alerts from services such as DebugBear. Confirm who can modify authoritative zones, require multi-factor approval, and rehearse a DNS rollback plan before the next incident.

What to do now

1. Lock registrar and DNS provider accounts with hardware-based multi-factor authentication, then remove stale delegates and review recent authentication logs.
2. Compare authoritative zone records against a known-good baseline, enable registry lock where available, and configure alerts for any record change.
3. Rotate credentials and API tokens used by DNS, registrar, and monitoring services; revoke unused or over-privileged tokens immediately.
4. Require documented change approval and out-of-band verification before any DNS edit, especially for high-profile public domains.
5. Monitor certificate transparency logs and DNS telemetry for anomalous resolutions, and investigate unexpected redirects or new subdomains.
6. Prepare a DNS rollback and public communications playbook, and validate fraud/refund workflows if customer funds may be affected.

Original source

SecurityWeek