What matters first: Visitors are shown a fake Chrome, CAPTCHA or browser update prompt that attempts to deliver malware. The WordPress site may only host the injected JavaScript or redirect logic.
What this symptom actually tells you
Because the payload is often conditional and remotely controlled, the site can look normal to administrators. Capturing script sources and network requests is essential.
Capture evidence before changing anything
- Record device, referrer, geography, cookie state and destination.
- Capture the HTML, JavaScript URLs and network waterfall without running downloads.
- Search themes, plugins, database options, tag managers and server rules.
- Check remote scripts whose content can change without local file modification.
Most common causes
- Injected JavaScript: Malicious code is stored in theme files, widgets or database content.
- Compromised tag manager: An authorised third-party container loads the payload.
- Remote loader: A small local snippet fetches changing attacker code.
- Conditional redirect: Server or PHP rules target selected visitors only.
Safe diagnostic and repair sequence
- Remove the local or third-party loader and revoke compromised publishing access.
- Replace modified components with trusted copies and clean persistence.
- Patch the entry point and rotate relevant WordPress, hosting and tag-manager credentials.
- Re-test under the original trigger with caches and CDN purged.
How to choose between the likely causes
Do not treat Injected JavaScript and Compromised tag manager as interchangeable. Malicious code is stored in theme files, widgets or database content. By contrast, an authorised third-party container loads the payload. Use two checks to separate them: Record device, referrer, geography, cookie state and destination; and capture the HTML, JavaScript URLs and network waterfall without running downloads. Those observations usually show whether the next safe move is to remove the local or third-party loader and revoke compromised publishing access or to preserve the current state and widen the investigation.
On a compromised site, containment and cleanup are separate decisions. Preserve the suspicious artefact and access logs before removing persistence, then rotate credentials only after the active path has been closed. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not download or execute the offered update on an administrative workstation. Use isolated analysis and treat the destination as hostile.
How to verify the repair
- The original visitor conditions no longer show the prompt.
- No unapproved remote script or tag-manager change remains.
- Security monitoring and browser reputation checks stay clean.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
Because the payload is often conditional and remotely controlled, the site can look normal to administrators. Capturing script sources and network requests is essential.
Record device, referrer, geography, cookie state and destination.
Capture the HTML, JavaScript URLs and network waterfall without running downloads.
Search themes, plugins, database options, tag managers and server rules.
Check remote scripts whose content can change without local file modification.
What must be verified
- The original visitor conditions no longer show the prompt.
- No unapproved remote script or tag-manager change remains.
- Security monitoring and browser reputation checks stay clean.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
If the site looks completely fine to an administrator, does that rule out this infection?+
No. This payload is often conditional and remotely controlled, meaning it can be shown only to specific visitors based on device, referrer, or geography, while looking entirely normal to an administrator browsing the same pages.
Is it okay to click the fake update or CAPTCHA prompt on an admin machine just to see what it does?+
No, this should never be done on a workstation with administrative access. The destination should be treated as hostile and analyzed only through isolated, controlled methods rather than by downloading or executing what it offers.
Could this attack be running through a legitimate-looking tool like a tag manager rather than the WordPress files themselves?+
Yes. A compromised tag manager container that has legitimate publishing access can load the malicious payload without any local file on the WordPress site being modified, which is why third-party scripts and tag managers need to be checked alongside theme and plugin files.
Why might the malicious script not be found by scanning the local WordPress files at all?+
A remote loader pattern uses only a small local snippet that fetches changing attacker-controlled code from an external source, so the actual malicious payload can vary or update without any corresponding change to the local files being scanned.