Fake browser-update malware is usually an injected presentation layer, not a browser problem. Visitors see a convincing “update Chrome/Edge/Safari” prompt because compromised WordPress code, a third-party asset or an edge layer changes the page delivered to them.
Capture the affected response before removing the lure
Save the rendered HTML, script URLs, redirect destination and time of observation. Compare an affected browser with a clean request and note whether the injection depends on device, referrer, geography or login state.
Separate local injection from a compromised external asset
- Inspect recently modified theme and plugin files.
- Review inline scripts and unexpected remote JavaScript domains.
- Check database options and widgets that can inject markup.
- Verify CDN/edge rules and tag-management changes.
Trace the entry point, not only the visible script
If executable code appears in uploads, compare malicious PHP under wp-content/uploads. If the visible payload is stored or configured in the database, review malware persistence in wp_options.
Contain without destroying the evidence chain
Remove public access to the malicious response if necessary, but preserve the suspicious file or configuration and relevant access logs before cleanup.
Rebuild the compromised delivery path
- Remove the injected loader and every confirmed payload.
- Patch or replace the vulnerable component or account.
- Rotate privileged credentials and third-party tokens implicated by the incident.
- Purge CDN, page and browser-facing caches after the origin is clean.
Do not block only the final redirect domain
The injected code can switch domains while the compromised WordPress component continues serving the lure.
Verification across contexts
Test logged-in and logged-out sessions, multiple devices and direct/referral traffic. The page source and network requests should remain clean after cache expiry, and no injection should return through scheduled or database persistence.
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.