Introduction

Injected malicious JavaScript can hijack visitors without making the whole site look obviously broken. It may steal form data, redirect traffic, load scam pages, inject spam, or only trigger for certain users. The fix is to treat it as a compromise, not a front-end bug. Remove the payload, find how it got there, and close the access path before the code is reinserted.

Symptoms

  • Visitors report redirects, fake popups, or wallet prompts that you do not see in normal admin sessions
  • Browser developer tools show unexpected external scripts or obfuscated inline code
  • Security scanners flag suspicious JavaScript on otherwise legitimate pages
  • The issue appears only on mobile, only for search visitors, or only on specific landing pages
  • Theme files, template snippets, CMS settings, or tag manager containers changed unexpectedly

Common Causes

  • Attackers modified theme, template, or layout files to load a malicious script
  • A compromised plugin, extension, or tag manager container injected hostile code
  • Stolen admin or hosting credentials allowed unauthorized edits
  • Third-party script dependencies were changed to serve malicious content
  • Cleanup removed the visible script once, but the original entry point stayed open

Step-by-Step Fix

  1. Capture the malicious script source, affected URLs, timestamps, and any modified files before removing anything so you preserve evidence for investigation.
  2. Compare the page source, rendered DOM, and CMS configuration to identify whether the payload comes from a file, database setting, tag manager, or third-party include.
  3. Put the site into a controlled cleanup state if needed so new visitors are not exposed while you remove the injection.
  4. Remove the unauthorized script from all affected templates, database fields, tag containers, or static assets, and verify no duplicate payload remains elsewhere.
  5. Check recent file changes, admin accounts, plugins, extensions, deployment history, and hosting logs to find how the attacker gained write access.
  6. Patch the original entry point, such as a vulnerable plugin, exposed credential, insecure admin account, or compromised deployment token.
  7. Rotate relevant credentials including CMS admin, hosting, database, SFTP, CDN, and script-management access if exposure is possible.
  8. Retest with clean browsers and multiple user paths, including mobile and uncached sessions, to confirm the malicious code no longer appears.
  9. Monitor file integrity, outbound script changes, security alerts, and search-console or browser warnings closely to catch any reinfection quickly.