If your WordPress site sends visitors to a page claiming they must update their browser, treat it as a site compromise, not a browser problem. The usual goal is to trick a visitor into downloading malware, while leaving the site owner unaware of what ordinary visitors see.
This attack is often called fake browser update malware. Public reporting has associated campaigns of this kind with SocGholish and ClearFake. ClearFake has also been reported using blockchain smart contracts to load parts of its delivery chain. Those family names help describe a pattern, but they do not identify every infection or prove what a particular site is serving.
What a fake browser update infection does
The infection injects JavaScript into a WordPress site and uses it to show a convincing update prompt or replace the page with an update-themed screen. It may say Chrome, Edge, Firefox, or another browser needs an urgent update, then offer a download button.
The risk falls primarily on visitors. A person who downloads and runs the offered file can infect their computer, expose their accounts, or give an attacker a foothold in their organization. The compromised WordPress site becomes a distribution point, which can damage customer trust, search visibility, and relationships with partners even if the site itself does not store customer files.
The code may be in the HTML delivered from your own domain, or it may load another script from an outside domain. It can also redirect the visitor before the normal page finishes loading. Do not click the download or try to inspect it by installing the file. Record the page URL, the time, and screenshots if possible, then close it.
Why the owner often cannot reproduce it
Fake update malware is designed to avoid the people most likely to remove it. The script can check whether a visitor is logged in to WordPress, has an administrator cookie, has visited before, or arrived from a search engine. It can also limit itself by device type, browser, country, time, or a random percentage of visits.
That behavior explains a familiar situation: a customer reports a scary update screen, but the owner visits the page and sees a normal site. It does not mean the report is mistaken. It means a logged-in dashboard session is a poor test of public behavior.
Use several clean, logged-out tests. Open a private browsing window, test on a phone using cellular data, and ask a trusted person outside your network to report what they see. Search for your own site and open a result, because some infections behave differently for search referrals. Keep these tests focused on observing the page, not downloading anything.
Start by preserving evidence and limiting exposure
The first priority is to stop visitors reaching the infected page while keeping enough evidence to investigate. If you can safely put the site into maintenance mode, do that. If the site is a store or essential service, discuss a temporary block or maintenance page with the hosting provider instead of making rushed changes on the live server.
Before cleanup, take a complete copy of the WordPress files and database. Store the copy somewhere that is not publicly accessible. Include server and access logs if your host provides them, because logs may show the account, plugin endpoint, or file upload that led to the compromise.
Also change any WordPress passwords used by administrators from a clean computer. Do not assume that is the complete remedy. An attacker who added a backdoor, stolen hosting credentials, or a malicious scheduled task may still have access after one password reset.
Where injected JavaScript commonly hides
The injected code must run on public pages, so start with code and settings that affect the site header, footer, templates, or front-end output. Check active and inactive theme files, especially functions.php, header.php, footer.php, and custom template files. Check child themes too.
Review installed plugins and directories under wp-content/plugins. A fake plugin can have a plausible name, and a modified legitimate plugin can contain a loader that adds JavaScript site-wide. Review must-use plugins in wp-content/mu-plugins, which load automatically and do not appear in the ordinary Plugins screen in the same way.
The database is another common location. Look at wp_options for unfamiliar site-wide settings, plugin settings, header or footer injection fields, and values with unexpected long encoded strings. Page builders, advertising plugins, and custom-code plugins can legitimately store scripts there, so compare a suspicious value with the plugin's purpose before removing it. Also inspect the content of pages, posts, widgets, and reusable blocks for scripts you did not add.
Do not overlook files outside the usual theme and plugin paths. A malicious loader can be placed in a WordPress core file, wp-config.php, a file in wp-content/uploads, or a recently added directory. PHP files in wp-content/uploads deserve immediate scrutiny because that folder is normally for media, not executable application code. Our guide to signs a WordPress site has been hacked gives other places to review.
Check the public page and its requests
Your browser's developer tools can help confirm what a public visitor receives. In a logged-out private window, use View Source to search for unfamiliar script references, odd inline JavaScript, and domains that do not belong to your site or known providers. View Source is useful because it shows the initial document, before some page changes obscure it.
Then open the Network panel, reload the page, and look for JavaScript requests and redirects. Note the request URL, initiating file when shown, response type, and timing. A third-party analytics, chat, payment, or CDN request is not automatically malicious. The useful question is whether the request has a clear business purpose and comes from a provider you recognize.
Compare the logged-out result with a logged-in administrator view. If a request exists only when logged out, that is a strong clue. Save a HAR file or screenshots if your browser provides that option, but avoid sharing it publicly because it can include session-related details.
Remove the infection as a complete cleanup
Removal works best as a controlled sequence, not as a search-and-delete exercise. First identify every changed or unauthorized component. Replace WordPress core files with clean copies from the same WordPress version rather than editing individual core files. Reinstall each trusted plugin and theme from its official source, and remove unused plugins and themes.
For custom themes and custom plugins, compare against a known-good repository or backup. Remove unauthorized JavaScript from the affected template or database record only after preserving the evidence and confirming what it does. Delete fake plugins, unknown must-use plugins, and PHP files in uploads that do not belong there. Check for WordPress backdoors, because a small loader can reinsert the visible script after cleanup.
Review WordPress users and remove accounts you cannot identify. Check scheduled tasks, hosting cron jobs, and server-level configuration with the host if the JavaScript returns after file cleanup. Then update WordPress, every retained plugin, and every retained theme. Patch the weakness that allowed access, such as a vulnerable extension, reused password, abandoned account, or overly broad file permissions.
Rotate access after the files are clean
Credential rotation closes access that a file cleanup cannot see. Reset WordPress administrator passwords, hosting control-panel passwords, SFTP or SSH passwords and keys, database credentials, and any API keys stored in WordPress or deployment tools. Update the database password in wp-config.php if you change it.
Review users with access to your host, domain registrar, CDN, and DNS provider. Remove former contractors and unused service accounts. Revoke and replace keys or tokens used by plugins only when you know where the replacement must be configured, so normal site functions do not silently fail.
Prevent the same compromise from returning
Prevention starts with reducing what can be attacked. Keep WordPress, plugins, and themes current, delete anything unused, and avoid plugins without a clear maintenance history. Use unique passwords and multi-factor authentication where your WordPress host and other providers support it. Limit administrator access to people who need it.
Maintain a tested backup that is separate from the live hosting account. A backup helps only if you can identify a clean restore point and still fix the original entry point. Periodically review public pages while logged out and review new administrators, plugins, and unexpected file changes. The WordPress hardening checklist is a practical routine for those checks.
When to get help
Get help when visitors are seeing the prompt, the site serves malware, or you cannot confidently account for every changed file and database record. West Oakbridge's WordPress malware removal service and WordPress hardening service can help with investigation, cleanup, and follow-up protection.