Remove DebugBear’s RUM script and audit third‑party code after the DNS hijack

On October 29, DebugBear announced that attackers had compromised its DNS records and were serving malicious JavaScript through the Real User Monitoring (RUM) script that many sites embed to track Core Web Vitals. The breach targeted at least one customer’s site, and a security analysis showed the code stealing trading credentials from logged‑in visitors.

What the DNS hijack entailed

DebugBear’s DNS records were altered at the registrar level, allowing attackers to redirect the script URL to a malicious JavaScript file. Hudson Rock’s analysis identified the malicious script on a DebugBear URL used by Polymarket on October 29, and Polymarket confirmed that the script moved funds from some users’ wallets without needing passwords.

Why immediate removal is essential

DebugBear instructed customers to delete the embed on October 29. Removing it stops further infection, though it does not reverse any actions already taken by the attackers.

Step‑by‑step remediation checklist

• Remove the DebugBear RUM embed from every page – check tag managers, CMS templates, plugins and any hard‑coded script tags. Verify with browser developer tools that the URL no longer resolves.
• Invalidate sessions and reset passwords for privileged accounts that may have loaded the compromised page. Start with administrators and any service accounts that have API access.
• Revoke and re‑issue any API credentials that were embedded in front‑end code or stored in environment variables that could have been exposed.
• Audit all third‑party scripts for unexpected changes. Compare current script URLs against a known clean list, and look for new or altered script tags in your tag‑manager history.
• Review server and application logs for unusual logins, new user creation, permission changes or file modifications that occurred while the DebugBear script was active.
• If you detect a breach, place the site in maintenance mode with a static HTTP 503 response, restore from a clean backup and confirm that no backdoors remain before going live again.

Post‑removal hardening measures

After the immediate threat is removed, strengthen your site’s defenses to reduce the impact of any future supply‑chain compromise.

• Implement a Subresource Integrity (SRI) hash for any third‑party scripts you continue to use, so the browser will reject altered files.
• Move critical monitoring to server‑side measurement or host the script on a domain you control, eliminating reliance on external DNS for delivery.
• Enable Content Security Policy (CSP) headers that restrict script sources to approved domains, limiting the ability of injected code to execute.
• Set short TTLs on DNS records for third‑party services where possible, making hijacks harder to exploit for long periods.
• Regularly review tag‑manager change histories and require multi‑factor authentication for any changes to production tags.

What to do now

Gather your development and security teams, assign ownership for each checklist item and set a tight deadline—ideally within the next 24 hours—to remove the DebugBear script and begin the audit. Document every change, keep a clean backup of the pre‑remediation state, and schedule a follow‑up review to confirm that no residual backdoors remain. If you need a replacement monitoring solution, choose one that offers tamper‑proof delivery or server‑side data collection.

Sources

• Search Engine Journal — Hackers Hijacked DebugBear’s DNS To Serve Malicious JavaScript