SocGholish and Fake Browser Update Attacks

By Glenn Lyvers · Updated September 20, 2026 · 4 min read

Someone tells you your website told them to update Chrome. The page looked right — correct logo, familiar wording, a single download button — and it appeared on your domain, on a page of yours they had every reason to trust. This is one of the more serious things that can happen to a site, because your visitors are now the target rather than you, and the damage runs on their machines.

What the attack actually does

The best known family here is tracked as SocGholish, though the pattern is copied widely. Injected JavaScript on your pages replaces the content a visitor sees with a full-page overlay imitating a browser update notice. It fingerprints the visitor first, so a Chrome user on Windows sees a Chrome prompt and a Mac user sees something appropriate to their setup. The download it offers is not an update. It is typically a script file inside a ZIP, and running it hands the attacker a foothold on that person's computer.

What makes this materially worse than a spam redirect is where it leads. These campaigns frequently operate as initial access brokers — the foothold gets sold on, and the eventual outcome for the victim can be credential theft or ransomware against their employer. Your site is the delivery mechanism in someone else's attack chain.

Why your site

Because it was reachable and it has traffic. These operations compromise large numbers of ordinary websites through the usual routes — an unpatched plugin, a stolen password, an old backdoor nobody cleaned — and value each one purely as an audience to put the overlay in front of. A site with real visitors and an established reputation converts far better than an obviously sketchy one, which is precisely why legitimate small business sites are so heavily used.

That also means there is nothing unusual about your situation and no reason to take it personally. What matters is speed: every hour the injection stays live is another set of visitors being handed malware in your name.

What to do first

Take the site offline or put it in maintenance mode while you work. I do not say that lightly and I usually argue against panic-driven downtime, but this is the exception. The ordinary cost of a few hours offline is small next to continuing to serve malware to your own customers, and unlike spam injection there is a live victim on the other end of every page view.

Preserve evidence before you start deleting. Copy the files and database somewhere safe, and save your access logs — they are what will tell you when this started, which matters for working out how many people were exposed. My guide on first steps after a hack covers the order to do this in without destroying the information you will want later.

Finding the injection

The overlay is drawn by JavaScript that is either injected directly into your page output or loaded from an external domain. Start by viewing the source of an affected page and looking for a script you cannot account for — commonly a long block of obfuscated code, or a short loader pointing at a domain that has nothing to do with your site or your legitimate services.

Then find what puts it there. Check your theme's header and footer templates and functions.php, check for injected content in wp_options and post content, and check for recently modified files across the install. Because this injection is frequently conditional — showing only to first-time visitors, or only to traffic from search — test with a clean browser profile and no login cookie, and compare against what a search engine crawler is served. My guides on injected JavaScript and database malware go through both hiding places in detail.

Cleaning and closing it out

Replace core, plugins and theme from clean sources rather than editing infected files, remove anything you cannot account for, and then do a proper database pass for the injected script and any attacker domains. Remove unrecognized administrator accounts, rotate every password including database and hosting, and replace your salts. Then hunt specifically for persistence — this family reinfects aggressively, and a single surviving backdoor undoes the whole job.

Do not skip the log review. You need the approximate start date both to be confident you have cleaned the full window and because it feeds directly into the next section.

What you owe your visitors

This is the part people would rather not think about, and it is the part that actually matters here. Anyone who downloaded and ran that file has malware on their machine. They do not know your site was compromised, and they have no way to find out unless you tell them. A short, plain notice — what happened, the dates it was live, what the fake prompt looked like, and advice to run a malware scan and change passwords if they ran the file — is the right thing to publish, and it does more for your reputation than silence ever does.

Whether this rises to a formal disclosure obligation depends on where you are and what data you hold; my guide on telling customers after a hack works through that question. If you want the cleanup done properly and quickly while you handle the communication side, that is what my malware removal service is for.

Common questions

Is my own computer infected because my site is serving this?

Not automatically. The malware is delivered to visitors through your pages, not installed on the machine you administer the site from. That said, a stolen administrator password is a common way in, and password stealers on a developer or owner machine are a real source of those. Scanning your own computer is a sensible precaution rather than an overreaction.

Why can I never reproduce the fake update page?

These injections fingerprint and filter. Logged-in users are skipped, repeat visitors are often skipped via a cookie, and some variants only fire for traffic arriving from search engines or from specific countries and browsers. Test in a private window, from a different network, arriving via a search result rather than typing your address directly.

Do I have to tell my visitors?

Ethically, yes, if the prompt was live long enough for anyone to have acted on it — those people have an executable running on their machine and no idea where it came from. Whether you have a legal obligation depends on your jurisdiction and the data involved. The practical answer is that a clear, early notice is almost always better received than a discovered cover-up.

Will a security plugin have caught this?

Sometimes, but do not count on it. The injected loader is often small, heavily obfuscated, rotated frequently, and stored in the database where file scanners do not look. Plenty of sites running a reputable security plugin have served these overlays for weeks. The reliable detection signal is usually a visitor complaint, not a scan result.

How long does the cleanup take?

A straightforward case is a few hours of focused work. What extends it is persistence hunting and the log review needed to establish the exposure window, and neither is optional here. Rushing to get back online before you are certain the backdoors are gone is how sites end up serving the same payload again a week later.