Practical guides on websites, online stores, and getting found on Google — written for business owners, not developers.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
Your WordPress site was clean and updated, yet it got hacked anyway. Here's how one infected neighbor on shared hosting can take you down with it.
In cleanup work, this is one of the stranger patterns we watch for. A site owner insists nothing changed on their end, and when we check, they're usually right. WordPress core current. Every plugin current. Admin password long and unique. None of the usual causes fit, because the usual causes aren't what happened. The infection came in through another site sharing the same hosting account, not through anything on theirs.
This happens more than most site owners realize. Shared hosting puts multiple sites in one account, sometimes one server, and a hack on one can spread to the rest without anyone doing anything wrong. People call it cross-contamination, and it flips the usual security advice on its head. You can do everything right and still get hit.
Two questions matter here: what actually lets a hack jump from one site to another, and how do you find out if your own hosting account makes that possible right now.
Security researchers have a specific term for this: cross-contamination. It means malware reaches your site through a neighbor, not through anything you did.
A normal hack starts with a weakness on your own site, something like an outdated plugin or a guessed password. Cross-contamination skips that step entirely. The attacker never touches your code first. They break into a different site on the same server, then use that as a way in to yours.
From the outside, the two look the same. Same malicious files, same spam injections, same blacklist warning from Google. The difference only shows up once you ask where the infection actually started, and it's a different question from most of what our why WordPress sites get hacked piece covers, since that one is about weaknesses on your own site. This is about what happens when the weakness sits on someone else's.
It's also a different animal from an attack like the ClickFix fake-Cloudflare attacks we've documented elsewhere, which start by tricking a visitor into running a command themselves. Cross-contamination never needs a visitor to do anything. It moves entirely on the server side.
Most shared hosting accounts run every site under one system user. Every WordPress install on that account shares the same file permissions and the same PHP process. Nothing separates them from the inside.
That setup opens a specific trick called a symlink attack. A script on the hacked site creates a link pointing at a file that belongs to a different site on the same account. Through that link, the script reads the second site's wp-config.php file, which holds database credentials. Once an attacker has those, they don't need a plugin vulnerability or a weak password on your site. They already have a way in.
Some hosts block this. A setting called open_basedir can stop PHP from reaching outside its own folder, and proper account isolation, the kind built on tools like CloudLinux CageFS, blocks it at a deeper level. Plenty of budget shared hosting plans skip both.
This isn't a rare edge case. In 2021, Wordfence disclosed an attack where a malware kit called AnonymousFox used exactly this method to jump from one infected WordPress site to multiple other accounts on the same server. The whole spread took under 90 minutes.
Ninety minutes is faster than most site owners check their own dashboard.
A few things point to a neighbor, not you. They sit alongside the more general signs your WordPress site is hacked, narrowed down to where these particular signs actually came from.
Your plugins, theme and WordPress core were current before the infection. Your admin password was long and unique. Nothing on your side had changed in weeks.
The malicious files turned up somewhere you never go. A PHP file sitting inside your uploads folder, where nothing should ever execute. An unfamiliar theme folder you didn't install. Files like that don't come from a vulnerability in your own plugins. They come from someone dropping them in from outside your site entirely.
The timing doesn't line up with anything your team did either. No update, no new plugin, no login from an unfamiliar location around when the infection appeared.
And if you check, other unrelated sites on the same server show the same blacklist warnings around the same week. A quick reverse IP lookup shows every domain sharing your server's address, and two or three of them going down at once isn't a coincidence.
None of this is proof on its own. Together, it's a strong pattern. If you want to walk through it more carefully, our hacked-site investigation guide covers the fuller diagnostic process.
Three questions tell you where you stand.
Ask your host whether the account runs on CloudLinux CageFS or something equivalent. That's the layer that stops one site from reading another site's files, even when they sit on the same server.
Ask whether your PHP process runs separately from everyone else on the account, or whether it's shared. A shared process is what makes the symlink trick from the last section possible in the first place.
Ask what happens if another site on the same server gets hacked. Some hosts scan and lock down every account automatically. Others only touch the one account that got reported, and leave the rest exposed until someone notices on their own.
Most site owners never ask any of this before signing up. The answers usually decide whether a neighbor's hack stays their problem or becomes yours too.
Cleaning your own site is not the end of this.
If the source account is still live and still infected, your site gets reinfected within days. The attacker still has the same way in they used the first time, and removing the malware from your files without fixing the account it came through just resets the clock.
Push your host to scan and lock down the whole account, not just the site that got reported. This matters more than anything else here.
Rotate every credential connected to the site: WordPress admin, database, FTP or SFTP, and the hosting panel itself. Assume all of them were exposed, not just the one the attacker actually used.
This is exactly the kind of case our malware removal service is built to catch: clean the site, then push to get the account itself secured, not just the one domain that got reported. If you want the full process we use, it's written up in How to Manually Scan and Clean WordPress Malware and in our recovery case study.
Cleaning up one hack answers the immediate problem. It doesn't answer when to actually change hosting.
One low-traffic personal site sharing an account with a couple of others is not much of a risk. A business site sharing an account with unrelated sites nobody is actively managing is a different calculation entirely.
The lever that matters most is simple. Once a site does real business, put it on its own hosting account, not a five-domains-for-one-price deal and not a shared reseller plan. Its own account, isolated from whatever mistakes anyone else makes.
If a full move to managed WordPress hosting isn't realistic yet, look for a host that states isolation clearly instead of leaving it to a support ticket answer. Hostinger runs CloudLinux with LVE containers for exactly this, isolating each account instead of pooling everyone into the same shared space.
This one change removes most of the risk in this article. Everything else here matters less once nothing else is sharing your account.
Only if you're the only account on it. A VPS shared with unrelated sites carries the same risk, just at a smaller scale. Isolation is the fix, not the label on your plan.
Ask the three questions from earlier. Does the host run CloudLinux CageFS or something equivalent. Is your PHP process separate from other accounts. What happens to the rest of the server if one site on it gets hacked. A host that answers clearly is usually doing it right.
Not entirely, but they set the conditions. A host running proper isolation makes this close to impossible. One that doesn't leaves every customer exposed to every other customer's mistakes. Choosing that host was still your decision.
If section 4 sounded familiar, it's worth getting someone to check the account itself, not just the site. Once a hosting account turns out to be the actual cause, the fix moves faster than most site owners expect, because you're no longer chasing a mystery.
SEO & Security Expert, AppDeel
Azizul Hakim is an SEO and website security specialist at AppDeel, the agency he founded and where he still handles client work himself. For more than ten years he has helped business owners and eCommerce brands get found in search and keep their websites secure.
Read more posts by Md Azizul Hakim →Block unwanted IPs, countries, and regions in WordPress the right way — .htaccess, nginx, plugins, and Cloudflare, with a decision table for each.
XSS lets hackers run malicious scripts on your WordPress site through comments, forms, or vulnerable plugins. Here's what it is and how to stop it.
Comment spam, form spam and fake registrations all cost you time, leads and security. Here's a business owner's guide to stopping WordPress spam for good.
A brute force attack is a hacker's program trying login after login, thousands or millions of combinations, until one works.
Tell us about your business today — get a free quote within 24 hours. No pressure, no confusing tech talk.
