Your site has been hacked, and the first person you contact is your hosting company. You pay them every year, after all, and “security” was on the plan’s feature list. The reply is polite and short: the server is fine, the infection is inside your website, and you should hire a developer or buy their cleanup add-on. It feels like being sent away.
Sometimes that answer is fair, and sometimes it is not. Which one applies depends on where the weakness was, and on what kind of hosting you actually bought. This post explains the usual split of responsibility, the cases where the host really is at fault, and how to get the most out of them while you deal with the problem.
The basic split: the building and the flat
A useful way to picture ordinary hosting is a block of flats. The hosting company owns the building. It looks after the walls, the wiring, the main entrance and the lifts. You rent a flat. What you put inside, who you give keys to, and whether you leave the window open are up to you.
On a typical shared or VPS plan, the host is responsible for the server: its operating system, the web server software, the network, physical security and keeping one customer’s account separated from another’s. The website is yours: WordPress itself, the plugins and theme you chose, the passwords for your admin users, and any custom code a developer added.
Most WordPress hacks come in through the website layer. An outdated plugin with a known flaw, a reused password, a file manager plugin left installed after a migration. None of those are things the host controls, which is why their first answer is so often “it is inside your site”.
What hosts usually do when a site is hacked
Every company has its own policies, and plans within one company differ. Read your own host’s terms. Broadly, though, these are the things a host commonly does.
- Detect and warn. Many hosts run malware scans across their servers and email you when something matches a known pattern.
- Suspend or restrict the account. If your site is sending spam, attacking other servers or hosting phishing, the host may disable it to protect everyone else on the server. This is about them, not you, and they will usually explain how to get it lifted. We cover that situation on our page about hosting suspended for malware.
- Provide backups. Some plans include automatic backups that you can restore. How far back they go, and whether you can download them, varies.
- Share logs. Most hosts give you access to web server access and error logs, often through the control panel, and support can sometimes provide older ones on request.
- Offer paid cleanup. Some hosts sell malware removal as an add-on or partner with a security company that does.
What hosts usually do not do
This is the part that surprises people, because it is often not spelled out on the sales page.
- Update your plugins and themes. On ordinary hosting, keeping WordPress components current is your job. Some hosts update WordPress core automatically; that does not cover everything else.
- Clean the infection as part of the plan. A scanner finding malware is not the same as someone removing it. Most standard plans do not include hands-on cleanup.
- Find out how the attacker got in. Tracing the entry point through logs and files takes time, and it sits outside normal support.
- Promise that their backups are clean. If the infection is older than the oldest backup, every backup contains it.
- Handle your Google warnings. Search Console and Safe Browsing reviews are requested by the site owner, not the host.
Managed WordPress hosting is a different deal
“Managed WordPress” plans usually take on more of the website layer. Depending on the company, that can include automatic plugin updates, a built-in firewall, daily backups kept off the server, blocked plugins known to cause problems, and sometimes a promise to help clean a hacked site.
The word “managed” means different things to different companies, so check what yours actually includes rather than relying on the name. If the plan says malware cleanup is included and they decline to do it, you are on firm ground in pointing to the terms.
When the host really is responsible
There are real cases where the weakness is on the host’s side. They are less common than website-level hacks, but they happen.
Server software left unpatched
If the operating system, web server or control panel software has a known security flaw that has gone unpatched for a long time, and that is how the attacker got in, the fault is theirs. You will rarely be able to prove this alone, but repeated infections across many unrelated sites on the same server are a clue.
Weak separation between customers
On shared hosting, your account should be walled off from the other customers on the same machine. If one stranger’s hacked site can read or write your files, the separation has failed. That is different from several of your own sites infecting each other inside one account, which we explain in our post on cross-site infection on shared hosting.
A breach of the host itself
Hosting companies are targets too. If the host’s own systems are compromised, customer passwords and files can be exposed. Hosts normally notify customers when that happens.
Something they promised and did not do
If your plan includes daily off-site backups and none exist when you need one, or the plan advertises malware removal and they refuse it, that is a failure to deliver the service you paid for.
How to tell where the weakness was
You do not need to win an argument with the host. You need to know where to look. These clues help.
- The infected files are inside a plugin or theme folder, or in
wp-content/uploads. That points to the website layer. - A new administrator appeared in WordPress before any other change. That points to stolen credentials or a plugin flaw.
- Files outside your home directory are affected, or the host’s own scripts have been changed. That points to the server.
- Other unrelated customers on the same server report the same infection at the same time. That also points to the server.
Our article on how websites get hacked describes the common entry points, which makes it easier to read these signs.
Getting the most out of your host during a hack
Whoever is at fault, the host has information and tools you will need. Being specific gets better answers than being angry. When you open a ticket, ask for the following.
- The scan report. Which files their scanner flagged, with full paths and the detection names.
- Access logs for the period before the first sign of trouble. Ask how far back they keep them, and ask them not to rotate them away while you investigate.
- A list of available backups with dates, and whether you can download them without restoring over the live site.
- The reason for any suspension and what they need from you to lift it.
- Confirmation that the server itself is patched and that they have no wider incident affecting other customers.
- Whether a temporary block is possible on a specific file or folder, so the infected part stops serving visitors while it is cleaned.
Keep the replies. They are useful later if the same thing happens again, and they help whoever cleans the site.
Should you move host after a hack?
Moving an infected site to a new host moves the infection with it. The backdoor files, the injected database entries and the vulnerable plugin all travel in the same backup. Clean first, then decide.
Moving does make sense when the host’s support was unhelpful during the incident, when the plan cannot give you basics like logs or downloadable backups, or when there is evidence the server itself was the weak point. Our guide to choosing web hosting lists what to look for, and it applies whether you are in India or elsewhere. If a move is the right call, plan it after the cleanup so you land somewhere new with a clean copy.
Who fixes what from now on
The hack is a good moment to write down, in plain terms, who is responsible for each part of the site: the server, WordPress updates, backups, monitoring, and what happens when something goes wrong. Our post on website hosting and maintenance responsibilities goes through that split in more detail. Having it agreed in advance means the next problem does not start with an email exchange about whose job it is.
If you are stuck between a host saying “it is your website” and a site that is still infected, we can help with the website side and speak to the host’s support for you where that helps. The hacked website repair page explains how to reach us: message us on WhatsApp and start with the word HACKED. We look first, tell you honestly what we see, and take a backup before changing anything.
Next in this series: Shared Hosting Cross-Site Infection: Why Hacks Spread
