Read the host's notice, compare each removed file with a clean copy from the official source, restore only files that match exactly, and treat any genuine detection as a hacked site that needs proper cleaning.

A site that broke overnight

Yesterday the booking calendar worked. This morning it shows an error, or a blank space, or the whole site is a white page.

Nobody changed anything. Somewhere in an inbox, perhaps one nobody reads, is an email from the host saying its scanner found a suspicious file and quarantined it overnight.

Sometimes the scanner found a real infection. Sometimes it removed a perfectly legitimate file belonging to a plugin or theme. The notice usually looks the same either way.

What to do next depends entirely on which it was.

What the scanner does

Many shared hosts scan the files in every account for known malicious code, because one infected site on a shared server can harm the others and the server's reputation.

When a file matches, the scanner may move it to a quarantine folder, strip its permissions so it cannot run, or delete it. Some hosts also suspend the account until the owner responds.

The scanner looks for patterns. It does not know what your site needs, or whether the file was there yesterday for a good reason.

Why a legitimate file gets caught

The second is the most ironic. A security plugin's own list of what to look for can contain exactly the strings the host's scanner searches for, and the plugin is flagged as the thing it was meant to find.

Reading the host's notice

The notice usually lists each file by its full path, the name of the pattern it matched, what was done to it and when.

The path tells you where it belongs. A file inside a plugin's folder points to that plugin; a PHP file inside the uploads folder, where only images and documents should live, is suspicious on its own.

If the notice went to an old address, ask the host to resend it and to show what is in quarantine. Many can restore a quarantined file on request, but they will not decide whether it should be restored.

Restore or not

The test is a comparison. Download a fresh copy of the same plugin, theme or WordPress version from its official source, and compare the flagged file with the original, line by line.

If they are identical, the detection was a false alarm. Restore the file, tell the host it was a false positive, and ask them to stop flagging it.

If the flagged file has extra lines, often a long block of scrambled text at the top, or if it has no original at all, the scanner was right.

Never restore a file simply because the site needs it. That puts the infection back.

A worked example

A commercial kitchen rents its two kitchens by the hour to caterers, bakers and food truck owners, who book shifts through a calendar on the kitchen's WordPress site.

One morning the calendar page showed only an error. Renters began phoning to check their bookings, and a baker arrived for a shift she could not confirm.

The host's notice had gone overnight to a manager who left the year before. It listed two quarantined files: one inside the booking plugin, and a small PHP file in the uploads folder.

The owner's instinct was to ask for both back. The site's developer compared the booking file with a newly downloaded copy of that plugin version, found them identical, and had it restored by lunchtime.

The uploads file had no original. It was a back door, planted through an outdated gallery plugin, so the developer removed both, changed every password and checked the rest of the site.

The host's contact address now reaches the owner and the developer.

When the detection is real

A genuine detection means the site has been broken into. The scanner found one file; it did not find how the attacker got in, or what else was left behind.

Treat it as a hacked site. Find the entry point, usually an outdated plugin, theme or WordPress version, and close it by updating or removing it.

Look for other added or altered files and for administrator accounts nobody created, then change every password: hosting, FTP, database and each WordPress administrator.

Then see whether Google has flagged the site: Search Console, formerly Webmaster Tools, lists any security problems it has found. Removing one file without the rest of that work usually means another notice within weeks.

Backups and their dates

Restoring yesterday's backup brings back the missing file, and possibly the infection too if the break-in happened earlier.

Know which dates your backups cover, who keeps them and how far back they go. A host that keeps a few days of copies may have nothing from before the attack.

A clean backup is useful for comparison even when you do not restore it, because it shows which files changed.

Who should get the notice

Hosts send these notices to the contact address on the account, which often belongs to whoever set the hosting up years ago.

Check that address today. It should reach the owner and whoever looks after the site, so that a quarantined file is noticed within hours rather than when customers complain.

The counter-case

Scanners are on your side. A host that quarantines suspicious files catches infections owners would otherwise miss for months, and an occasional false alarm is a fair price.

A plain site without plugins or uploads rarely triggers one at all.

The answer is not to switch scanning off but to respond to it properly: read the notice, compare before restoring, and clean the whole site when the detection is real.

When the next notice arrives

  1. Read the notice and list each file.
  2. Ask the host what is in quarantine.
  3. Download clean copies from the official sources.
  4. Compare each file line by line.
  5. Restore only exact matches and report false positives.
  6. Treat anything else as a break-in.
  7. Update the contact address on the hosting account.

Step four settles everything after it. Without the comparison, restoring and cleaning are both guesses, and the wrong guess either leaves the site broken or puts the infection back.

Another way a site disappears overnight after something changes at the host is covered in the host's default page showing instead of yours.


Frequently asked questions

Why did my host remove a file?

Its scanner matched the file against patterns of known malicious code and quarantined, disabled or deleted it. The match can be a real infection or a false alarm.

How do I tell a false alarm?

Compare the flagged file with a newly downloaded copy of the same release from its official source. Identical means a false alarm; extra lines or no original mean infection.

Can I just restore the file?

Only after comparing it. Restoring a genuinely infected file because the site needs it puts the infection straight back, and the scanner will usually remove it again.

What if the detection is real?

Treat it as a hacked site: find and close the entry point, look for other added files and accounts, change every password and check Search Console.

Why do legitimate plugins get flagged?

Some hide their code to protect licences, security plugins carry lists of malware patterns, and old versions of scripts match signatures for known flaws.

Who should receive the host's notices?

The owner and whoever looks after the site. The account's contact address often belongs to someone who set up the hosting years ago and no longer reads it.

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.

A notice from your host about quarantined files?

Forward it to us. We will compare every file, restore what is safe and clean the site if it was hacked.

Start a Conversation