Hosting Blocked Your Website Because of Malware: What Now?

Your hosting provider blocked your website because of malware? A block is a protective measure — the provider uses it to stop your site from spreading an infection, sending spam or serving phishing from its IP addresses. It is not a punishment, and in most cases it is not permanent. It is, however, a clear signal that something is running on your site that should not be there, and that deleting a single suspicious file will not fix it.

This article covers what to request from your provider, what to do in the first hour, what to avoid, and how to word the unblock request so it is approved the first time.

What a block means — and what it does not

Providers use several different measures, and it helps to know which one applies to you, because they differ in scope and in what you will need to get back online:

• Site suspension. The site is unreachable and the provider’s notice page is served instead. Files and the database stay in place and you can still reach them over FTP/SFTP or the file manager.
• File quarantine. The site keeps running, but an automated scanner moved specific files out of the webroot. This usually shows up as a broken feature or a 500 error — and it is the most deceptive variant, because it looks like an ordinary fault.
• Account suspension. Every site is down and often email with it. This is typically a response to spam being sent from your space.
• Outgoing mail block. The site works, but orders, registrations and contact forms never arrive. Common on compromised sites abused as mail relays.

What a block does not mean: that the host knows how the attacker got in. An automated scanner reports files matching signatures — it does not determine the entry vector, does not inspect the database and cannot tell you whether another, still undetected copy exists. Nobody will do that part for you.

What to request from your host in the first email

Most people reply asking to be unblocked. Ask for the evidence instead — without it you are working blind, and the second block arrives within days:

1. The specific reason for the block. Malware in files, outgoing spam, a phishing page, an attack on another server, or a third-party report?
2. The full list of findings — file paths, signature names and detection times. This is the single most valuable item: it gives you the first timestamp of the incident.
3. Where quarantined files were moved and how long they will be kept. Quarantine directories are often purged automatically — and they are your evidence.
4. Access and error logs covering several days before the detection. Finding the entry vector without them is considerably harder.
5. Whether provider backups exist, for which dates, and how long they remain available.
6. The unblock procedure and its conditions — exactly what they need to see before the site goes back up.
7. Whether the block was reported onward (Google Safe Browsing, outbound mail blacklists). If it was, a second round with those services is waiting for you.

The procedure differs between providers — each one runs its own scanner and its own rules for bringing a site back. That is exactly why it pays to ask specific questions instead of sending a generic unblock request: the list above works with any of them.

The first hour: what to do and what to avoid

1. Preserve a copy before deleting anything. Download the webroot, a database export and whatever logs you can get. Even an infected copy is valuable — it is often the only source that can explain how the attacker got in.
2. Write down the timeline. When the notice arrived, when the site last worked, when something was last updated or installed. Those three dates explain a surprising amount.
3. Restrict access. Change passwords for the CMS, hosting, FTP/SFTP, database and email, and disable unknown administrator accounts. Change them from a clean device — if your computer is infected, the new passwords leak exactly like the old ones.
4. Do not delete blindly. Attackers routinely use multiple entry points and files that look legitimate. Fast deletion destroys evidence without closing the hole — and the site gets blocked again days later.
5. Do not restore a backup unchecked. If it was taken after the compromise, you restore the infection with it. If it predates the compromise by a long way, you lose orders and content. The backup has to be reviewed first.
6. Do not assume the scanner “removed it”. Deleting the reported files is the beginning, not the end.

Shared hosting, VPS and managed hosting are handled differently

On shared hosting the block is usually fast and automatic, because one compromised site threatens the reputation of the whole server. Your forensic options are limited — you cannot reach system logs and you depend on whatever the provider supplies.

On a VPS nobody usually blocks anything until the problem becomes externally visible: outgoing spam, an attack on another server, or a complaint. In exchange you have full access to logs and to the system, so the analysis is considerably more thorough — but hardening the whole server is your responsibility.

With managed hosting, cleanup assistance is often part of the service. It is worth establishing what exactly is included: frequently it means deleting the reported files rather than tracing the cause.

How a safe recovery works

We begin with an inventory: CMS version, template, extensions, administrators, cron jobs, redirects and configuration changes. Next comes comparing files against trusted sources, hunting for backdoors and obfuscated code, and inspecting the database, user accounts, injected iframes and unusual URLs. On WordPress we also check mu-plugins, wp-cron and the uploads directory; on Joomla the components, plugins, templates and any files outside the standard structure.

The recovery itself is not a matter of deleting individual findings but of a clean rebuild: core and extensions are deployed from verified packages, only reviewed content and data are carried over, vulnerable components are updated, credentials are rotated and hardening is applied. Only then does putting the site back into production make sense.

The deliverable is not a list of deleted files. It is a classification of findings by severity and confidence, a description of the probable entry vector, and recommendations for ongoing operation. Where the scope cannot be determined reliably, we say so — for some incidents that is a more honest answer than false reassurance.

How to get the unblock approved first time

Providers reject requests that do not demonstrate the problem cannot immediately recur. The request should therefore state:

• what exactly was found and how it was removed,
• what the probable entry vector was and how it is now closed (update, replaced extension, corrected permissions),
• that all credentials were rotated,
• which preventive measures are newly in place,
• how the recovery was verified.

If the site was also reported to Google Safe Browsing, that is handled separately through a review request in Search Console — and it should be submitted after hardening is complete, not before. We cover that in Google flags your website as unsafe.

Why the block comes back

A repeat block within days or weeks almost always has one of four causes: an undetected backdoor remained, the entry vector was never closed, an infected backup was restored, or compromised credentials were never changed. In all four cases the first intervention addressed the symptom rather than the cause — and that is the most expensive way to handle an incident.

Frequently asked questions

How long does unblocking take?

The unblock itself is usually a matter of hours once the request is approved. The work before it takes considerably longer: the scope of the incident and the state of your backups decide whether it is hours or several days.

Is restoring the latest backup enough?

Not always. If the backup was created after the compromise, you restore the infection with it. It has to be reviewed first — and even a clean backup only returns the site to the state in which it was vulnerable.

Will I lose content or orders?

The goal is to preserve content, design and operational data. A working copy is created before any intervention and changes are made in a controlled way. On a badly damaged site, however, zero loss cannot be promised without diagnostics; any such risk is described up front.

Can the site stay online during the cleanup?

It depends on the type of block and on the risk. For an online store we usually prioritise keeping trading and data safe; with an active web shell the correct call is to keep the site down until the webroot is trustworthy again.

Will a security plugin solve it?

A plugin helps with detection and with hardening after recovery. It cannot establish the scope of a compromise or the entry vector, and with an active backdoor it runs inside the very environment the attacker controls — so its verdict cannot be treated as confirmation that the site is clean.

What if the host has no backups?

Then you work with what exists: the current (however infected) state of the site, database exports and logs. A clean rebuild is usually the only safe route in that situation.

Order a security diagnosis · More about website malware removal · Ongoing website management