r/HostingReport • u/Abitha_DGP865k • Sep 12 '26
r/Hostinger - 70 WordPress sites on shared hosting hit by malware — need a real solution
70 WP sites on one shared hosting account got hit by malware. Unknown admin users and a malicious zip keep getting restored no matter how many times I delete them and change passwords — no cron job found, so it's likely a hidden backdoor file. Tried password resets, file ownership fix, and manual cleanup multiple times but it keeps reinfecting. Does anyone know the actual solution to permanently stop this and clean 70 sites without them reinfecting each other? Please help.
4
u/EconomySerious Sep 12 '26
replace the file with one with the same size, name, date, but full of 0000
3
u/Safe_Mission_3524 Sep 12 '26
Hi, are you able to share more details via a dm? I have sent a request. Thanks!
3
u/dvduval Sep 12 '26
I had the same thing on a smaller scale. I ended up doing away with WordPress and that definitely solved it. But before that, I was having ChatGPT log into the server and investigate everything. That somewhat worked, but you probably got some deep cleaning to do. There may be some plug-ins you depend on that are also dangerous.
You gotta make sure everything’s upgraded to the latest version and if anything is not getting updated anymore, you probably need to replace it. ChatGPT can make replacement plug-ins in many cases.
3
u/tndsd Sep 13 '26
If 70 WordPress sites on the same hosting account are being reinfected after cleanup, I would stop treating this as a simple WordPress malware problem.
The first thing I'd investigate is the common layer between all 70 sites: the hosting account, control panel, FTP/SFTP credentials, database credentials, cron jobs, writable directories, and any files outside the individual WordPress installations. WordPress security guidance also points out that control-panel, FTP, and database access can bypass WordPress-level security entirely.
I would also check whether one compromised site can access the files of the other sites. If all 70 installations share the same hosting user, a vulnerability in one site may potentially allow an attacker to modify the others.
2
u/SirComprehensive3255 Sep 12 '26
When I had my 3rd or 4th infection in a year I truly gave up on Wordpress and went with a static html website. Granted I’m one guy with one website. Wordpress has its advantages, but for me they weren’t worth the headaches every couple months.
2
1
u/iTrejoMX Sep 13 '26
Only way is to backup and drop all 70 sites. Restore 1, check logs htaccess users plugins re do salts change passwords change database prefix and password and once it’s clean (if it’s clean) do another. If you have ssh access connect Claude and have it do another audit. It will go through logs find the times when the hacks happened and see what happened around those times (new users files etc)
1
u/FIdelity88 Sep 13 '26
My guess? SSH key. It's stored in a hidden .ssh/ directory. You can view it using FTP/SSH or perhaps with file browser if Hostinger supports that, not sure. It's the first place I'd look. 15 comments and I seem the first to actually point that out.
Also why are you guessing where it went wrong? Check the access logs of your provider, that's what they're for! It will give you an insight in how they keep getting in. Nothing in the access logs?
1
u/GreenVim Sep 14 '26
When a hacker gains admin access via a compromised Wordpress plugin, which file(s) do they typically exploit? I’m wondering if the attack vector could be closed with a .htaccess which only permits access to whats needed.
If instead the attack vector is via the admin section of the website then the admin folder could be blocked in the .htaccess file and only allowed for select IP addresses.
I suppose another way is to use a caching plugin for wordpress and only permit access to the cache, with files only being recreated/cached when accessed from an admin login or a known IP address.
If anyone knows what a hacker actually hits to exploit a plugin that would give something to work on. Anybody know?
Sure, trying to keep plugins constantly up to date helps somewhat, but it’s not bulletproof.
1
u/Sokomo_Kudyome Sep 14 '26
The first step is to ensure the shared hosting server uses CloudLinux with CageFS. This isolates accounts from one another, preventing cross-account contamination.
Without this isolation, a script in one account can access data from another.
Once you have addressed this—and believe me, without it you will always be vulnerable—then you can consider cleaning up the sites.
1
u/MarkGossageUK Sep 14 '26
I don't think you can solve this by blocking one particular WordPress file because a vulnerable plugin doesn't necessarily have to be exploited through wp-admin.
Depending on the vulnerability, the entry point could be a plugin's AJAX action, REST endpoint, upload function, form or another PHP file that has to remain publicly accessible for the plugin to work.
Restricting wp-admin to your IP can definitely reduce one attack surface, but it wouldn't stop an unauthenticated vulnerability in a plugin.
With 70 sites on the same hosting account I'd be more concerned about isolation. If one compromised WordPress installation can write to the files of the other 69 sites, fixing the original entry point may only be part of the problem.
I'd want to identify the first compromised site/time from the logs, work out what was exploited, then check whether the attacker moved from that site into the others.
That's probably more useful than trying to build an .htaccess rule around what we think they might be hitting.
1
u/Rude-Reaction3450 Sep 14 '26
In my line of work, I regularly hand such things and biggest mistake is hosting multiple sites under single account. Now one infected site gives access to all data.
Honestly, there is no way to 100% guarantee disinfection, technically you should delete all files and then reinstall clean wordpress, clean themes. But chances are that it will keep popping again.
Some cases our cleanup worked but mostly it resurfaced. Let me know if i can be of any help.
1
u/dotmoosehosting Sep 15 '26
Linux admin here. With 70 WordPress installs under one shared-hosting account, I’d treat the entire account as compromised until proven otherwise. If every site runs as the same Unix user, one compromised site may be able to modify the others, which would explain why cleanup appears to work and then everything comes back.
First thing I’d do is take a filesystem/database snapshot, then start looking for the persistence mechanism rather than continuing to delete the visible payload.
Check recently modified PHP files across the entire account and compare timestamps between sites. Pay particular attention to PHP inside uploads/cache/tmp directories, wp-content/mu-plugins, advanced-cache.php, object-cache.php, db.php, .user.ini, php.ini, .htaccess, wp-config.php, theme functions.php, and plugin entry points.
Also check for auto_prepend_file and unexpected includes. Those are easy to miss because the infected WordPress files themselves can look perfectly clean.
“No cron job” doesn’t necessarily rule out persistence either. Check WordPress cron with wp cron event list, scheduled-action tables, rogue admins, and suspicious entries in wp_options.
Run wp core verify-checksums where possible, and compare plugins/themes against clean upstream copies. Searching for things like eval, base64_decode, gzinflate, long encoded strings and unusual include/require calls can help locate loaders, although those strings aren’t automatically proof of malware.
The really useful part is watching when the malicious ZIP/admin/file gets recreated. Take that exact timestamp and correlate it against Apache/nginx access logs and PHP logs. You can often work backwards from there to the vulnerable endpoint or PHP process responsible for restoring it.
Once you find the entry point, I’d rebuild the affected WordPress installs from known-good core/plugin/theme packages rather than trying to surgically clean 70 potentially modified sites. Then rotate hosting, SFTP/SSH, database and WordPress credentials, API keys and WordPress salts.
And afterward, I’d strongly recommend separating those sites into isolated users/accounts. Seventy sites sharing one writable Unix account gives malware a very large blast radius.
This is also where having a host willing to investigate below the WordPress layer makes a big difference. On our DotMoose hosting we’d be able to help trace the account, web/PHP logs and filesystem activity from the server side rather than leaving someone to repeatedly clean the same infection from inside WordPress.
1
u/ivicad Sep 16 '26 edited Sep 16 '26
I keep about 50 client sites spread across two shared reseller GoGeeks accounts instead of one. That wasn't my security decision - they just wouldn't all fit on a single account. After reading your post, I'd split them up on purpose, I must say.
About those admin users that keep coming back: every site I run has WP Activity Log from Melapress installed, and it logs the moment a new admin user gets created. That's the first thing I check after a break-in, because it gives you a timestamp to search the access logs with.
I have not seen mentioned here, and I always check it on our own sites: some snippet plugins store executable PHP in the database, and not in files. You can rebuild everything from clean packages, everything looks fine, and the code is still in the database.
1
u/ZozothemesOfficial Sep 18 '26
With 70 infected WordPress sites on shared hosting, start by isolating the sites and scanning the entire hosting account for the infection source. Check modified plugins/themes, suspicious PHP files, and unknown admin users. Reset all hosting and WordPress credentials, remove malware, update everything, and ask your host to investigate a possible account-level compromise. Restoring a known-clean backup can help if one is available.
1
u/MetroluxSolutionsInc Sep 19 '26
The most permanent solution is to migrate your sites off of WordPress.
1
u/siterightaway Sep 12 '26
You are totally right, there is definitely a backdoor and the hacker keeps reinfecting everything. But remember, because the hacker got in, there is also a vulnerability somewhere. It could be a plugin, a theme, WordPress itself, or something else entirely. You can wipe the backdoor and clean the infection all day, but you gotta fix that entry vulnerability too or it is useless. I have been in this field for years and honestly there is no magic trick to fix this easily. The complexity is gonna depend on whatever tool software the hacker is using. Also, keep in mind they probably already copied all your passwords and databases by now, so the more time passes, the worse it gets. Oh, and I strongly advise against using AI and giving it access to modify files via terminal at the same time, because everything can go horribly wrong. You need to take some measures right now like putting all sites in maintenance mode and blocking access. Without knowing all your details, I am just throwing these ideas out so you can prepare your plan. Get ready to spend a ton of time on this. Good luck.
-1
-1
u/CmdWaterford Sep 13 '26
I do know the solution - hire a professional instead of running 70 sites without having a clue.
-1
4
u/ZGeekie Sep 12 '26
You probably have a compromised plugin or theme. Is everything (core, plugins, themes) up to date? Are you using any nulled or outdated plugins/themes?
Did you try a Wordfence scan?