---
title: A third-party script on your site was compromised (analytics, RUM, chat, tag manager): cut it off, scope what it could reach, protect users, harden | ctxsec
url: https://ctxsec.com/playbooks/third-party-web-script-compromise-response
---

[← Playbooks](/playbooks)

# A third-party script on your site was compromised (analytics, RUM, chat, tag manager): cut it off, scope what it could reach, protect users, harden

For incidents like the Oct 29 DebugBear RUM compromise that drained Polymarket users' wallets. The vendor's script runs in your origin with your users' sessions, so treat it as code execution in your front end for everyone who loaded a page while it was malicious.

For: AppSec / web platform, SOC, IR lead, Fraud / customer support

[1. Cut it off](#s1)[2. Establish the exposure window](#s2)[3. Scope what it did](#s3)[4. Protect users](#s4)[5. Harden](#s5)

1.

Step 1 of 5

__

### Cut it off

Stop serving the script before investigating.

   - Remove the vendor snippet from every app and template, including tag-manager containers that inject it, and deploy
   - Purge CDN and service-worker caches so old pages stop loading it
   - Block the vendor script host in CSP script-src as a backstop
   - If the app moves money or assets, consider pausing sensitive actions (withdrawals, trades, payouts) until the script is confirmed gone

2.

Step 2 of 5

__

### Establish the exposure window

You need first-bad and last-bad times.

   - Ask the vendor when the hosted file changed; save copies of the malicious file and its hash
   - Check your own build history and CDN logs for when the snippet was last present
   - List pages that loaded it and which ones hold sessions, tokens, wallet connections or secrets

3.

Step 3 of 5

__

### Scope what it did

Read the payload; it tells you what to look for.

   - Note what it collected or triggered (form fields, tokens in localStorage, signed requests) and where it sent data
   - Search server logs for actions in the window that match the payload (unusual sells, transfers, address changes, API key reads)
   - Look up any hard-coded recipient addresses or exfil domains in transaction and proxy logs

4.

Step 4 of 5

__

### Protect users

Assume sessions active in the window are exposed.

   - Invalidate sessions and tokens issued before the fix; require re-authentication for sensitive actions
   - Reverse or reimburse unauthorized actions where possible and tell affected users plainly what happened
   - Warn users about follow-on phishing pretending to offer refunds

5.

Step 5 of 5

__

### Harden

Make the next vendor compromise smaller.

   - Keep third-party scripts off pages that authorize payments or show secrets, or isolate them in sandboxed iframes
   - Enforce CSP script-src and connect-src allowlists; self-host or pin fixed vendor files with Subresource Integrity
   - Monitor third-party script hashes and alert on change
   - Review vendor contracts for incident notification times

Original content by ctxsec. Printable checklist: use your browser's print view.