Author Topic: [CRITICAL] Multiple CWP Servers Infected – Arbitrary PHP Code Execution via Publ  (Read 254 times)

0 Members and 3 Guests are viewing this topic.

Offline
*
I’m reporting a critical security issue affecting multiple servers running CWP (CentOS Web Panel). During a security review on a Laravel-based website hosted via CWP, I found malicious PHP files in the public/ folder that allowed arbitrary code execution.

🛑 What I Found

On my server, inside /home/username/public_html/public/ and /home/username/public_html/, I found two suspicious files:
   •   nbpafebaef.jpg – Contains PHP code despite the .jpg extension:
<?php echo md5("gewafwaef1");die;?>

   •   defauit.php – A PHP script with a misleading name (looks like “default.php”).

These files execute when accessed via a browser. This confirms that PHP is being executed from the public folder, even if disguised with a .jpg extension.

🔍 Widespread Issue – Other Sites Also Affected

After further investigation, I found that other unrelated websites also running CWP have the exact same malicious files in the same locations:
   •   https://basaranturizm.com/
   •   https://coutos.pt/

This strongly suggests a systemic vulnerability, likely related to how CWP manages public folders or file permissions. These sites are not connected to me — I simply found them through Google search using the filename.

❗ Possible Vectors

Some possibilities include:
   •   Insecure permissions on public/ allowing PHP file uploads or writes
   •   Compromise via CWP File Manager or outdated software
   •   Global vulnerability in CWP’s file handling or directory security

⚠️ Request to CWP Team

Please investigate this urgently. It’s very likely that:
   •   CWP has a flaw allowing code execution in public folders
   •   Default permissions or services are enabling attackers to inject files across multiple servers

If CWP developers need any of the samples or log details, I’m happy to provide them privately.


Offline
*****
Are you running malware detection scans on your system?

https://basaranturizm.com indeed serves up examples of these trojan files -- oddly that's all the domain serves and it allows file listing, so something is not normal about it. Looks to be PayPal scam related. Perhaps it is even a source domain for the files to be retrieved from. I located some of those files on a backup of a CentOS 7 system VM running Apache. One CentOS 7 system I have in legacy mode is clean -- but it runs Nginx, not Apache. Two newer AlmaLinux servers I have are clean. So my suspicion is that there is a weakness in the default Apache config on CWP or a problem with CentOS 7 systems -- all the more reason to get off of EL7 and get to an EL8 or EL9 foundation.

Offline
*
Scary but is it true?
What system does CWP run on?
Please provide the CWP version you are using?
Apache version?
PHP version for the CWP panel?
What web server?
Modsecirutes enabled? If so, in what version?
Roundcube in what version?
I am not affiliated with the creators of CWP, I just want to compare it with my installation. There could be many attack vectors.
« Last Edit: July 07, 2025, 05:03:52 PM by tomkolp »

Offline
*
My server have AlmaLinux 8, everything was updated and in the last version I have more servers only one was affected.
But all client accounts on the server have the same 2 files.
In the logs I found this
/usr/local/cwpsrv/logs/access_log:127.0.0.1 - - [04/Jul/2025:16:50:38 +0100] "POST /user1/index.php?module=filemanager&acc=findFiles HTTP/1.0" 302 16 "-" "python-requests/2.18.4"
/usr/local/cwpsrv/logs/access_log:127.0.0.1 - - [04/Jul/2025:16:50:39 +0100] "POST /user2/index.php?module=filemanager&acc=findFiles HTTP/1.0" 302 16 "-" "python-requests/2.18.4"
/usr/local/cwpsrv/logs/access_log:127.0.0.1 - - [04/Jul/2025:16:50:40 +0100] "POST /user3/index.php?module=filemanager&acc=findFiles HTTP/1.0" 302 16 "-" "python-requests/2.18.4"
/usr/local/cwpsrv/logs/access_log:127.0.0.1 - - [04/Jul/2025:16:50:41 +0100] "POST /user4/index.php?module=filemanager&acc=findFiles HTTP/1.0" 302 16 "-" "python-requests/2.18.4"
/usr/local/cwpsrv/logs/access_log:127.0.0.1 - - [04/Jul/2025:16:50:41 +0100] "POST /user5/index.php?module=filemanager&acc=findFiles HTTP/1.0" 302 16 "-" "python-requests/2.18.4"
/usr/local/cwpsrv/logs/access_log:127.0.0.1 - - [04/Jul/2025:16:50:42 +0100] "POST /user6/index.php?module=filemanager&acc=findFiles HTTP/1.0" 302 16 "-" "python-requests/2.18.4"

This is at the same time that defauit.php was created the nbpafebaef.jpg was created some days after.

On root /tmp folder I found to suspect files:
/tmp/.auto_monitor and /tmp/.tmp_baf

.auto_monitor was the file tht have the code to duplicate the .tmp_baf on each account and rename it to efauit.php


Offline
*****
Actually, it looks to be a Thai porno/romance portal -- the PayPal payment script is probably to reel in payments.
https://www.nongwangkudrung.go.th/video/
(not going to make this a clickable link)

Offline
*
Well, I figured the bug out. It is bad. Quite bad. Lock down your file manager is all I can say publicly for obvious reasons.
But yeah, you can upload arbitrary files to any CWP user as long as you know (or can guess) their username.

Just registered on here after testing this on my own CWP installation out of curiosity (and wanting to make sure my servers are secure).

Does anyone know a security contact at CWP I could poke? Just using their "contact us" form as well, I suppose.

Offline
*
Since I realized I can't edit my own posts and I forgot better instructions.

You want to delete /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php (or rename it to like filemanager.php.disabled, make sure it no longer has .php extension at the end)

Offline
*
Thanks for that.

I'm wondering (maybe it sounds stupid) but if a malware can elevate their permissions to "root" level, then file uploads would be the least of my concern?

Else how can the malware read, write, or execute anything on this file if it is under 644 root ownership?

Again it might sound stupid. Newbie here.
A global boutique AI consulting, marketing & advertising agency, helping businesses worldwide achieve success - headquartered in Singapore, Southeast Asia.

Offline
*
You’re absolutely right to be concerned — and I believe we may be dealing with two distinct but related security issues.

Issue 1: File Manager Vulnerability (Confirmed)
As already pointed out, the filemanager.php module in CWP seems to allow arbitrary file upload to any user account, as long as the attacker can guess the username. This is a critical flaw in access control and should be treated as a top-priority zero-day vulnerability.

This alone explains how attackers managed to inject malicious files like defauit.php or nbpafebaef.jpg across multiple accounts.

➡️ Temporary mitigation: Disable or rename the file:
/usr/local/cwpsrv/var/services/user_files/modules/filemanager.php
I’ve renamed it to filemanager.php.disabled to block access while waiting for an official fix.

 Issue 2: Lateral File Injection via /tmp (Needs confirmation)
What’s particularly concerning is that on my server, all user accounts had identical malicious files — including accounts with no websites or activity.
I found two suspicious scripts in /tmp/:
   •   /tmp/.auto_monitor: Contains code to iterate over all user accounts and drop malicious files
   •   /tmp/.tmp_baf: A payload later renamed per user as defauit.php

The auto_monitor script appears to loop through /home/*/public_html/ and replicate the payload across accounts.

Now, here’s the key problem:
Even if filemanager.php was used to inject a file into one account, it doesn’t explain how the malware was then able to write to other accounts — unless:
   1.   The injected script gained elevated privileges or exploited a weak configuration
   2.   Some CWP service or cron is running PHP scripts from /tmp under a shared or root context
   3.   There’s a misconfigured global process that allows cross-account write access from within user space

This part needs deeper analysis. But the implications are very serious:
Even a single compromised account could lead to full lateral infection.

Offline
*
New update this security issue is already public on https://fenrisk.com/rce-centos-webpanel and https://cybersecuritynews.com/linux-centos-web-panel-vulnerability/, with code CVE-2025-48703.
This articles tell that this is already fixed on 0.9.8.1205 but Im on 0.9.8.1206 and I have the problem.

Please we need some update from someone on the CWP Team

Offline
*****
So according to the 2 vulnerability reports you mentioned, it's limited to EOL CentOS 7 systems -- for which support ended over a year ago. Not too surprising, really. The longer those systems are on the internet, the more of sitting ducks they become. Time to migrate to AlmaLinux!

Can you confirm that you both are running CentOS 7 systems?

Caught one probe for this vuln on one of my Alma systems, coming from Hong Kong:
Code: [Select]
[root@alma]# grep "module=filemanager" /usr/local/cwpsrv/logs/access_log
91.124.30.69 - - [08/Jul/2025:04:50:00 -0500] "POST /myuser/index.php?module=filemanager&acc=changePerm HTTP/1.1" 404 147 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 14.7; rv:134.0) Gecko/20100101 Firefox/134.0"
« Last Edit: July 08, 2025, 02:29:47 PM by overseer »

Offline
*
So according to the 2 vulnerability reports you mentioned, it's limited to EOL CentOS 7 systems -- for which support ended over a year ago. Not too surprising, really. The longer those systems are on the internet, the more of sitting ducks they become. Time to migrate to AlmaLinux!

Can you confirm that you both are running CentOS 7 systems?

Caught one probe for this vuln on one of my Alma systems, coming from Hong Kong:
Code: [Select]
[root@alma]# grep "module=filemanager" /usr/local/cwpsrv/logs/access_log
91.124.30.69 - - [08/Jul/2025:04:50:00 -0500] "POST /myuser/index.php?module=filemanager&acc=changePerm HTTP/1.1" 404 147 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 14.7; rv:134.0) Gecko/20100101 Firefox/134.0"

No is not, this is a panel issue (Im in version 0.9.8.1206), I use AlmaLinux 8 not CentOS 7. This is is a Filemanager issue, is better to remove the filemananger for now.

Offline
*
It is indeed a filemanager issue. I have tested found the vulnerability by testing against my own CWP server (which is up fully up to date, and runs AlmaLinux 8 ).

You can effectively convince the filemanager to perform any operation without being correctly authenticated as any user (so long you know or can guess their username).

Luckily, this does not work against the "root" user, only valid CWP users, so it does not allow for total system compromise.

As for why it makes non-.php files run as code? Possibly a malicious ".htaccess" file or similar could be uploaded to changes the handler directives, or another vulnerability (which I did not discover) allows reconfiguring the webserver.


I tried reporting the issue (privately) using the contact form and have been informed I need a support subscription, and have responded that I will not pay for reporting security issues. If I get another negative response, I might have to put the information into the bug tracker so the engineers actually can see it, but I would really rather avoid sharing any information in public to not cause this to be exploited even more widely than it already seems to be.


The easiest sign of a compromise (or attempt) through this bug are POST calls to "/USERNAME/index.php?module=filemanager&..." with a 302 response code in your logs, especially with non-browser user-agents.

I am also not sure what the discussion of "execution" here is, PHP does not care if a file is chmod 644 or 755 or anything else, so long as it can read the file, it can (and will) run the file when accessed via a browser through the webserver.

There might well be more security issues present in CWP, given the one I found was not too difficult to discover, that allow actually running arbitrary commands or things of that nature, but checking is hard as all of CWP is encoded with ionCube, and therefor I have to try random things to see what happens, I can't just read the code.

I will look for more issues in the filemanager code myself as well, just for completeness sake.

And again, if anyone knows of a way to (privately) report this to CWP without telling potential "bad guys" the exact exploit path, please tell me.

If anyone needs verification of this bug, feel free to create me a test user on a CWP installation of your choice and I can upload a (harmless!) file using the exploit.

Offline
*
It is indeed a filemanager issue. I have tested found the vulnerability by testing against my own CWP server (which is up fully up to date, and runs AlmaLinux 8 ).

You can effectively convince the filemanager to perform any operation without being correctly authenticated as any user (so long you know or can guess their username).

Luckily, this does not work against the "root" user, only valid CWP users, so it does not allow for total system compromise.

As for why it makes non-.php files run as code? Possibly a malicious ".htaccess" file or similar could be uploaded to changes the handler directives, or another vulnerability (which I did not discover) allows reconfiguring the webserver.


I tried reporting the issue (privately) using the contact form and have been informed I need a support subscription, and have responded that I will not pay for reporting security issues. If I get another negative response, I might have to put the information into the bug tracker so the engineers actually can see it, but I would really rather avoid sharing any information in public to not cause this to be exploited even more widely than it already seems to be.


The easiest sign of a compromise (or attempt) through this bug are POST calls to "/USERNAME/index.php?module=filemanager&..." with a 302 response code in your logs, especially with non-browser user-agents.

I am also not sure what the discussion of "execution" here is, PHP does not care if a file is chmod 644 or 755 or anything else, so long as it can read the file, it can (and will) run the file when accessed via a browser through the webserver.

There might well be more security issues present in CWP, given the one I found was not too difficult to discover, that allow actually running arbitrary commands or things of that nature, but checking is hard as all of CWP is encoded with ionCube, and therefor I have to try random things to see what happens, I can't just read the code.

I will look for more issues in the filemanager code myself as well, just for completeness sake.

And again, if anyone knows of a way to (privately) report this to CWP without telling potential "bad guys" the exact exploit path, please tell me.

If anyone needs verification of this bug, feel free to create me a test user on a CWP installation of your choice and I can upload a (harmless!) file using the exploit.

It’s completely unacceptable that no one from the CWP team has replied to us. This issue was identified as early as June 22nd and was supposedly fixed, yet it continues to occur.

Offline
*
It seems like the filemanager is riddled with bugs itself (beyond its authentication bypass). Without looking too hard, I have now also managed to find a command injection vulnerability (as in, you can get it to run arbitrary shell commands as the user), which might explain another path how these malicious scripts run.

From how quickly I found this after probing random features, it is likely there's more as well, they might just be harder to find, or I didn't try them, yet.


I have also poked around at the other various endpoints in CWP, those seem to validate authentication correctly. But the filemanager code just seems to be of substantially worse quality than the rest of CWP (not sure why, as I can't read the code as previously mentioned, just judging from finding multiple bugs very easily, while the rest of CWP seems to hold up to some poking and prodding)

I do agree, this necessitates an immediate response as it puts every single user of CWP at high risk. Really only a matter of time until some scanner finds any CWP installation and tries to exploit it.


As for lateral movement: That is quite easy. You can simply list all folders in /home (which reveals all usernames) and repeat the exploit against every single user (possibly via the above mentioned command injection to bypass mitigations like open_basedir). You can likely even run the exploit locally from the machine itself. As mentioned, the exploit works against any valid user. And with one, you can enumerate all users.

To reiterate, this allows dropping files and running shell commands as any CWP user, no matter if they have an active domain or not. It does not allow going to "root" or "admin" levels.


So, all existing symptoms (lateral movement after finding a single user, uploading files into user's /home folders, and running files) can currently be explained with the filemanager vulnerabilities.

If any files are running as root, then everything gets much worse, but so far I have not found a path to root user / system compromise. That does not mean it is impossible, of course.

For now, however, I would like to repeat: Make sure no one can access your filemanager by deleting the file /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php (or renaming it to filemanager.php.disabled).