[CRITICAL] Multiple CWP Servers Infected – Arbitrary PHP Code Execution via Publ

I have the same problem. My VPS are infected.
Im using CWPpro version: 0.9.8.1218 and Rocky Linux release 9.5
After the intrusion i have problems with SEO, google results display titles from other sources.
My websites traffic has plummeted in the last few days because of this change. When I type site:mysomain.tld into Google, I see that the results point to my websites, but the text is different.
Does anyone else have this problem? Do you know how to fix it? How did you manage to change it? I've already submitted sitemaps to Google Search Console, but I'm not sure if it will work.

Hi, read all the thread, your problem is 100% related to this topic. Our servers were exploited to show an online store. Not sure what the hacker did to gain anything with this because the webpages were not defaced. Usually they get the google refer to deface the webpage.
Take into consideration that your server has a lot of backdoors installed. But, as I said, read the thread.

I believe your websites are in wordpress. So start by removing the new user the hacker added to your websites. Then install a fresh wordpress and start all over

Make sure you remove all .php files from "wp-content\uploads".

Apparently, you're Portuguese, and so am I.
The infected VPS has 12 sites, most of which are WordPress, but it also has two sites built from scratch and a forum in SMF.
All sites were affected, and what I discovered was the following:
- Index.php, .htaccess, and robots.txt were replaced on all sites.
- Several files and folders were added. Some of these folders had single-letter names.
- There were zip files, JPG files but with malicious code, and also fake CSS files.
- Two users were created on the WordPress sites, but these users are not visible in the WordPress admin panel. To see these users, you have to use PHPmyadmin.
- The robots.txt file had an error in the word "disallow" and contained a line like "sitemap: doamain.tld/?sitemap.xml," which I believe is used to trick Google into reading a different sitemap that isn't the correct one. Because Google started indexing several URLs that don't exist, meaning all the fake URLs are of the type https://domain.tld/?f=142558512. One of the websites has 4,000 pages in the original sitemap, but Google indexed 58,000 because of these fake URLs.
- The strangest thing is that the original URLs of the sites were kept, but in Google results, they appear with titles and descriptions different from the original content.
In wp-content folders dont find any php file.

I deleted all the strange files I found, deleted the users via phpmyadmin, restored the backups of the infected files, and submitted the sitemaps to the search engines.
I renamed /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php, but the cwpanel filemanager still works. Is this normal?
I'm afraid the vulnerability won't be fixed and that all the cleanup and file restoration work will be futile.
I'm guessing this issue will affect many servers and I don't see any response from the CWP team.

your problem is 100% related to this topic.

Just to be clear, the CVE originally discussed in this thread was patched by the CWP devs in early July. Any exploit since then pertains to a whole class of PHP injection attacks that are an unfortunate reality of being a sysadmin / webmaster these days. You need to know how to harden your PHP installation and set some minimum barriers up around your web sites (web application firewalls). There used to be a setting called "DontBlameSendmail" -- but in this case, Don't Blame CWP. The onus is on YOU the sysadmin to secure your system.

Yes, I am portuguese.
As far as I can see, I don't have folders with just a single letter. That's probably from a previous hack?

Two users were created on the WordPress sites, but these users are not visible in the WordPress admin panel. To see these users, you have to use PHPmyadmin.

Oh ok, i didn't know that. I haven't checked the users in the WordPress admin panel, I only saw them in the database like you did.
If you simulate the Googlebot user agent in your browser you'll be able to see the changes on your website. The defacement probably only activates for certain countries (I'm just guessing), because there is no other way to view it without simulating the Googlebot agent.
Make sure you remove usermeta data as well (from the database).

In wp-content folders dont find any php file.

had a few PHP files inside /wp-content/uploads and they were malicious (and by the look, they are from the same creator).

I renamed /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php, but the cwpanel filemanager still works. Is this normal?

With that change, Filemanager inside admin panel it still works, but in the user panel it doesn't work anymore.
Change your CWP panel port and add “Simple Authentication” to it - It has to be done manually.
That will help prevent future damage.

Yes, I am portuguese.
As far as I can see, I don't have folders with just a single letter. That's probably from a previous hack?

Two users were created on the WordPress sites, but these users are not visible in the WordPress admin panel. To see these users, you have to use PHPmyadmin.

Oh ok, i didn't know that. I haven't checked the users in the WordPress admin panel, I only saw them in the database like you did.
If you simulate the Googlebot user agent in your browser you'll be able to see the changes on your website. The defacement probably only activates for certain countries (I'm just guessing), because there is no other way to view it without simulating the Googlebot agent.
Make sure you remove usermeta data as well (from the database).

In wp-content folders dont find any php file.

had a few PHP files inside /wp-content/uploads and they were malicious (and by the look, they are from the same creator).

I renamed /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php, but the cwpanel filemanager still works. Is this normal?

With that change, Filemanager inside admin panel it still works, but in the user panel it doesn't work anymore.
Change your CWP panel port and add “Simple Authentication” to it - It has to be done manually.
That will help prevent future damage.

Yes, I am portuguese.
As far as I can see, I don't have folders with just a single letter. That's probably from a previous hack?

Two users were created on the WordPress sites, but these users are not visible in the WordPress admin panel. To see these users, you have to use PHPmyadmin.

Oh ok, i didn't know that. I haven't checked the users in the WordPress admin panel, I only saw them in the database like you did.
If you simulate the Googlebot user agent in your browser you'll be able to see the changes on your website. The defacement probably only activates for certain countries (I'm just guessing), because there is no other way to view it without simulating the Googlebot agent.
Make sure you remove usermeta data as well (from the database).

In wp-content folders dont find any php file.

had a few PHP files inside /wp-content/uploads and they were malicious (and by the look, they are from the same creator).

I renamed /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php, but the cwpanel filemanager still works. Is this normal?

With that change, Filemanager inside admin panel it still works, but in the user panel it doesn't work anymore.
Change your CWP panel port and add “Simple Authentication” to it - It has to be done manually.
That will help prevent future damage.

Obrigado pela resposta e também pelas dicas.
Perdi muitas horas a tentar perceber como conseguiram entrar no servidor e este tópico serviu de ajuda para entender o que sucedeu. Afinal o problema foi causado por uma vulnerabilidade e certamente o meu servidor já está contaminado desde cerca de 2 semanas, porque foi nessa altura que começaram a descer abruptamente as visitas orgânicas aos meus sites e foi outra situação que me causou confusão e não percebia o motivo. No dia de ontem o mallware substituiu os ficheiros de index e deixou os sites inacessíveis sendo isso o que me levou a investigar a causa.
Agradeço as dicas, mas mudar a porta não serve de muito porque basta fazer um scan às portas para descobrir qual é. A porta ssh estou constantemente a muda-la e mesmo assim são quase diarias as tentativas de login ssh.
O meu caso mudei a senha dos usuários e como o servidor é só para mim, deixo desativado o filemanager.php. Também limitei o número de envio de emails porque é muito comum que estas ações ocorram para fazer spam usando o servidor de email.
Vou ficar atento aos logs e espero que tenha ficado resolvido. Importa salientar que tenho ativo o firewall, antivirus e o mallware scanner, mas não foram suficientes para mitigar a intrusão.
Mais uma vez agradeço o feedback porque este tópico poupou-me muito tempo de investigação e análise.
Deixo apenas uma última anotação à parte do tema, este fórum submete a resposta em http em vez de https, algo invulgar. Vou ponderar deixar de utilizar este cwpanel porque já é a segunda vez que tenho um problema destes causado por vulnerabilidades do próprio painel.

o scan à porta é bloqueado pela Firewall, no entanto se forem vários bots a fazer bruteforce já não serve de nada a firewall. Ainda assim é melhor do que manter a porta como está.
Entende que o teu servidor é 1 em 1 bilião. Se a porta não tiver disponível já não interessa para scanear. Normalmente este povo faz scans de IPs em vez de portas. Quando há uma vulnerabilidade zero day, as portas são sempre as mesmas para scanear.

Sobre a porta SSH coloca uma porta perto do final do range. Também podes usar chave ssh se tiveres receio de teres só 1 password.

Posso estar enganado mas o bloqueio de email não serve de muito se for feito pelo próprio php.

Os scanners de malware são inúteis. Fiz scan com eles e não valeu de nada.

Não tens soluções gratis tão completas. Mesmo o cpanel tem sofrido ataques ao mesmo nível. Vais pagar para continuar no mesmo. Possivelmente vais migrar os sites e vão ficar minados novamente.
Considera bloquear as páginas mais sensíveis com "Basic access authentication".


EN version:

The port scan is blocked by the firewall, however, if multiple bots perform a brute-force attack, the firewall becomes useless. Still, it’s better than leaving the port as it is.
Understand that your server is one in a billion. If the port isn’t available, it’s no longer useful to scan. Usually, these guys scan for IPs rather than ports. When there’s a zero-day vulnerability, the ports are always the same to scan.

About the SSH port, choose a port near the end of the range. You can also use an SSH key if you’re worried about relying on just one password.

I could be wrong, but blocking email doesn’t help much if it’s done via PHP itself.

Malware scanners are useless. I ran scans with them, and they were worthless.

You won’t find free solutions that are this comprehensive. Even cPanel has suffered attacks at the same level. You’ll end up paying to remain in the same situation. Most likely, you’ll migrate the sites, and they will be compromised again.
Consider protecting the most sensitive pages with “Basic Access Authentication.”

I use a Key file access for SSH access rather than password authentication. It requires you to have the cert on each puter you use to access but it pretty much ends the success of any bots trying to brute force SSH as they need the cert.

You can also search in your files. "\x3c\x66\x6f\162\x6d\40\x6d\x65\x74\150\x6f\x64\x3d\"POST\"";"
Might be another backdoor.

Don't trust to find this sequence. All injected files, even if they do the same, all of them have different obfuscation codes even with different sequence of code.
Best way is to search for index files within the folders and check your main index file.
Also consider to disable php execution inside folders that are not needed. Also disable direct execution of php files that don't need to be called directly from URL. This can be done with folder permissions and .htacess files.

This is not obfuscated code. This is ASCII equal to <form method="post".
Attacker uses this pattern in many backdoor files. Its safe for mass remove unless you use regex in your search parameters.

My wordpress wibsites also infeted. And other websites non worpress also. Replaced index.php, added  licelic.c" backup.c defauit.php. I found admin accounts in database WP-user wpadmin@volovmart.ru. I dont know how its happened. But i think it is Panel hacked because it is not effect  only WordPress CMS. Im using CWP pro.

Hello,

We're encountering the same situation on one of our servers.
While we're actively performing cleanup operations, the critical question remains: Has this vulnerability truly been resolved by the "silent patch"?

Do you have any informations about when end what version of the patch/update ?

Best regards,

I have the same problem. My VPS are infected.
Im using CWPpro version: 0.9.8.1218 and Rocky Linux release 9.5
After the intrusion i have problems with SEO, google results display titles from other sources.
My websites traffic has plummeted in the last few days because of this change. When I type site:mysomain.tld into Google, I see that the results point to my websites, but the text is different.
Does anyone else have this problem? Do you know how to fix it? How did you manage to change it? I've already submitted sitemaps to Google Search Console, but I'm not sure if it will work.

First thing to do is renaming /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php as /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php.disabled

Then follow the messages sent by @pedromidiasf and me at page 5 to page 7. You will see the names of the malicious files dropped by attackers.

What exploiters are capable of is equal to filemanager at the start and this might not seem worrying. But then they take full advantage of PHP so if they want to remove whole of your files, they can and they can redirect your visitors to other websites.

If I was the one whos using this exploit I could convert this to a DDoS tool by redirecting every visitor to the website that I want to cause DoS. So, there is no limit, they can do anything they want and every IT admin should take this seriously.

@pedromidiasf, but did you manage to find the vector of the attack?

The file manager issue was some time ago, but yesterday some of my websites were changed, and they weren't even WordPress sites. Some files were injected, and I really need to find out what caused that. I only found out because they were development websites and someone tried to add them to Google Search Console, which notified me.

PS. I'm also Portuguese

This is not obfuscated code. This is ASCII equal to <form method="post".

That's exactly how obfuscation works

Attacker uses this pattern in many backdoor files. Its safe for mass remove unless you use regex in your search parameters.

Every file I found has a different footprint. You can't just regex it in trust you have found every one. You should better search for php files that has "eval" and other interpretative functions.

@pedromidiasf, but did you manage to find the vector of the attack?

The file manager issue was some time ago, but yesterday some of my websites were changed, and they weren't even WordPress sites. Some files were injected, and I really need to find out what caused that. I only found out because they were development websites and someone tried to add them to Google Search Console, which notified me.

PS. I'm also Portuguese

I have other websites that aren’t WordPress that were also infected, but unlike the WordPress sites they were not defaced,they only got the backdoor. I discovered the problem because Google Search results for our websites were completely messed up (with store items). I Then tried emulating Google’s bot on my browser and checked Google Search Console to see how the websites were being indexed.

The procedure: I found files in the access log that didn’t belong to me, and related to those, the logs contained some IP addresses. I searched those IPs on Google and found results discussing this vulnerability. I then looked up the CVE ID to understand how the exploit works.

Then follow the messages sent by @pedromidiasf and me at page 5 to page 7. You will see the names of the malicious files dropped by attackers.

What exploiters are capable of is equal to filemanager at the start and this might not seem worrying. But then they take full advantage of PHP so if they want to remove whole of your files, they can and they can redirect your visitors to other websites.

If I was the one whos using this exploit I could convert this to a DDoS tool by redirecting every visitor to the website that I want to cause DoS. So, there is no limit, they can do anything they want and every IT admin should take this seriously.

That's right. And it could even be used as a VPN or proxy, cryptojacking, and so on. This exploit is fully capable of exploiting the server in PHP code (limited to the users privileges [non sudo] and PHP resources).
I haven't format the server (only sanitized the public_html folders) and I didn't find anything ever since. Hope it keeps itself as it is.

I might be wrong (and I hope not), but the hacker with full control would delete log files (or entries) clear shell histories, create privileged sudo accounts and add their public SSH keys, schedule tasks and so on. And none of those were implemented. On the other hand, public_html folders were invaded with trash.

(Just a guess) Oh be aware that the mysql root password might have been dumped. I've created some modules before and that password is stored as a variable that go inside the panel system. So if the plain text password is there, it might be stored somewhere else. I've disabled phpMyAdmin on my server in order to secure it.


I've implemented some more secure measures, I'll leave it here when I get some free time.

Thank you all. I found defauit.php date stamp on JUL 05, 2025

Intruders:

Code: [Select]

194.156.230.148
198.144.182.13
205.198.68.5
207.154.240.68
43.198.83.83
61.222.202.149
Command to check log files:

Code: [Select]

grep -E "filemanager" /usr/local/cwpsrv/logs/*

grep -E "defauit|defauIt|nbpafebaef" /usr/local/apache/domlogs/* /usr/local/apache/logs/*

Command to find suspect files:

Code: [Select]

find / -type f \( \
    -iname 'defauit.php' \
    -o -iname 'defauIt.php' \
    -o -iname 'licelic.c' \
    -o -iname 'backup.c' \
    -o -iname '.c' \
    -o -iname 'c' \
    -o -iname 'nbpafebaef.jpg' \
    -o -iname '.auto_monitor' \
    -o -iname '.tmp_baf' \
    -o -iname 'wp-login.php' \
    -o -iname 'index.php' \
    -o -iname 'robots.txt' \
    -o -iname '.htaccess' \
  \) -exec ls -l {} \; 2>/dev/null

Command to temporarily disable the user panel filemanager:

Code: [Select]

mv /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php.disable.5456RANDOM2547
Command to check php config:

Code: [Select]

php -i | grep open_basedir
php -i | grep disable_functions


Thank you all. I found defauit.php date stamp on JUL 05, 2025

Every file has a different date stamp. Those files were touched to a close date and time of the neighbor files, that date stamp is not the right one. Don't mind searching for time and date, it won't do anything.

Those IP addresses are the same as mine. So, same hacker.

'nbpafebaef.jpg'
'.auto_monitor'
Where these files were present? Do you still know?

Thank you all. I found defauit.php date stamp on JUL 05, 2025

Every file has a different date stamp. Those files were touched to a close date and time of the neighbor files, that date stamp is not the right one. Don't mind searching for time and date, it won't do anything.

Those IP addresses are the same as mine. So, same hacker.

'nbpafebaef.jpg'
'.auto_monitor'
Where these files were present? Do you still know?

.jpg files are always in the same folder with defauit.php file and with sappurit's reply its confirmed that nbpafebaef.jpg file is not randomly named(Same filename with my screenshot earlier at page 7) but its not the only jpg file.
I think IP addresses are irrelevant because blocking them are not solution. Its easy to change IP address or tunnel connections.
The timestamp might be touched but it still tell us that most likely vulnerability is still exists.

Maybe someone could decode filemanager.php and apply a fix by adding a check for php sessions.

Maybe someone could decode filemanager.php and apply a fix by adding a check for php sessions.

I read that filemanager.php it is already patched. If necessary, disable the client panel ports (2083 and 2082) on the firewall, then restart it to apply the changes.
Logged as admin, you will still be able to access these ports (firewall will whitelist your IP address). Ask a friend to test the URL to see if he gets timed out.