On October 29, 2026, monitoring vendor DebugBear told customers of its Real User Monitoring (RUM) product to remove the website embed code. If your site loads that snippet, this is today’s action item. If not, the incident is still a good reason to review which third-party scripts run inside your pages. Here is what to do, what the public notices establish as of our November 2, 2026 check, and what remains unverified.

What to do now

These are practical checks for owners and providers, not vendor mandates.

  • Locate the real integration in theme templates, tag manager containers and plugins, and note which authenticated or sensitive pages load it.
  • If you use DebugBear RUM, follow the dated removal instruction and obtain current recovery guidance from the vendor before restoring anything.
  • Remove the embed from your pages and purge cached copies that still reference it. Then verify forms and checkout still work, and confirm no loader requests appear in an authorized browser session.
  • Do not fetch or run suspect code to inspect it yourself.
  • Where possible, preserve existing delivery logs and page evidence before destructive cleanup.
  • Determine actual exposure and session risk with your provider. Take targeted session or credential actions when evidence warrants, not blanket key rotation or full backup restores on the vendor name alone.
  • Review your third-party script inventory and the privileges each one needs. Keep unnecessary integrations off payment and account pages.
  • Plan Subresource Integrity (SRI) and a tested Content Security Policy (CSP) where compatible. SRI checks fetched bytes against a pinned hash before execution and rejects an unexpected file; cross-origin use needs CORS support and the right crossorigin attribute. It suits exact reviewed assets with controlled updates, not an unversioned changing snippet. A host allowlist CSP verifies origins, not bytes. Pinning an already malicious file creates no trust, and neither control is a guarantee. Test before enabling and do not break business forms.

What the vendor said

In a public statement posted on October 29 at 18:00 UTC, DebugBear acknowledged an ongoing security incident and instructed RUM customers to remove the embed code from their websites. That is a dated instruction. As of our November 2 check we have not verified any newer all-clear, and the vendor homepage and blog were unavailable to us. The statement does not establish whether the service remains affected today, what caused the incident, whether all customers were affected, or whether synthetic monitoring was involved. RUM is a snippet embedded in your pages; synthetic monitoring runs from the vendor’s side and needs no embed.

What the researchers found

Hudson Rock reported on October 29 that it retrieved the per-project DebugBear CDN script used by Polymarket as inert text, twice, on that day. The researchers describe logic that looked for an already-authenticated trading client or signer and attempted asset transfers. Static analysis shows intent. It does not prove every signing request went through silently or that transfers settled, since a signer can prompt or reject. A production build timestamp in the file metadata that points to removal is not proof of live containment or that already-open tabs were safe.

Analysis published by ohey.ca on October 29 examined the same Polymarket-specific sample against archived copies and public chain data. It corroborates a malicious replacement and the vendor’s removal instruction. The target was one project’s script, not proof that every DebugBear project received malware. The Hacker News covered the discovery on November 1.

Still unverified across these sources:

  • The root cause and the initial compromise mechanism.
  • Whether any customer beyond this one project was affected.
  • The exact delivery window and the total impact.
  • Any newer all-clear from the vendor.
  • The June 25 loss and reimbursement reporting mentioned in coverage is a separate matter from the October 29 script finding.

Why this matters for a small business site

A third-party script executes in the context of the page that embeds it. From there it may read the page DOM and script-accessible data, and it may request actions the application exposes, as the Polymarket sample did when it sought an already-authenticated signer. What it can achieve is bounded by browser boundaries, server-side authorization and any confirmation a signer or payment step requires. The risk is therefore conditional: it depends on which pages load the script and what visitors do there, not on the vendor’s name.

Remaining limits

Removing the embed from updated pages stops that loader on those pages. Cached pages, tabs that were already open, other injection paths and the actual session risk of past visitors still need checks. Removal is not proof that earlier visitors were safe or that the incident is closed. ViWeb has not investigated any customer or remediated this case.

Further reading