Polymarket and DebugBear DNS Hijack: Immediate Mitigation Steps for SecOps

What happened

On October 29, Polymarket halted trading after users reported unauthorized withdrawals. Investigation linked the activity to malicious JavaScript served from a DebugBear domain that the prediction‑market platform loaded. The script targeted logged‑in traders, inspecting their browser state and redirecting assets to an attacker‑controlled wallet.

DebugBear, a website‑performance monitoring service, later disclosed that its DNS records were compromised through its domain registrar. The hijacked records allowed the attacker to serve the malicious code to Polymarket customers without their knowledge.

Who is affected

Polymarket’s international platform suffered a supply‑chain attack that impacted 726 wallets. The company announced a $3.9 million payout to affected traders, covering the majority of losses.

DebugBear’s customers were exposed indirectly; the compromised DNS records enabled the attacker to inject malware into any site that referenced DebugBear’s scripts. Only one customer was confirmed to have been targeted, but the vulnerability remains active.

Impact

The malicious JavaScript leveraged the trading permissions of an authenticated session to move funds without requiring passwords or seed phrases. While no credential exfiltration was detected, the attacker gained full control over the victim’s trading activity.

Polymarket’s temporary shutdown caused significant disruption to traders and raised concerns about the integrity of third‑party script delivery in financial services. The incident also highlighted the risk of DNS hijacking as a vector for supply‑chain compromise.

Exposure

DebugBear’s DNS hijack demonstrates how a registrar compromise can propagate malware to downstream customers. The attacker’s ability to modify DNS records meant that any domain pointing to DebugBear’s IP could be redirected to malicious content.

Because the malicious code was served from a trusted source, traditional content‑security‑policy checks were bypassed. The attack relied on the trust relationship between Polymarket and DebugBear, underscoring the need for rigorous third‑party verification.

What to do

SecOps teams should immediately audit DNS configurations for all third‑party services. Verify that domain ownership and registrar access are protected with multi‑factor authentication and that DNS change logs are monitored.

Implement script integrity checks on all external JavaScript resources. Use Subresource Integrity (SRI) tags or hash‑based verification to ensure that only signed, unaltered code is executed.

• Review and tighten permissions for any third‑party script hosts.
• Deploy network segmentation to isolate critical trading or financial services from external script delivery networks.
• Enable real‑time monitoring of DNS changes and alert on unauthorized modifications.
• Conduct a thorough code‑review of all client‑side logic that interacts with user accounts or financial transactions.
• Perform regular penetration testing focused on supply‑chain and DNS hijack scenarios.

What to watch

Keep an eye on updates from the Domain Name System Security Extensions (DNSSEC) community. While DNSSEC can mitigate hijack risks, many registrars still lack robust deployment.

Monitor threat‑intel feeds for indicators of compromise related to DebugBear or similar monitoring services. Early detection of DNS tampering can prevent widespread script injection attacks.

Polymarket’s swift restitution and DebugBear’s public disclosure set a precedent for transparency in the face of supply‑chain attacks. Defenders must treat third‑party script delivery as a first‑line vulnerability and enforce strict controls to protect user assets.