Recent Posts
31
CentOS-WebPanel Bugs / Re: [CRITICAL] Multiple CWP Servers Infected Arbitrary PHP Code Execution via Publ
« Last post by overseer on July 08, 2025, 06:10:10 PM »Might need some more street cred here than just the 4 posts on this thread before people listen to the advice and go deleting (!) their filemanagers... A Chicken Little response doesn't usually end up well.
But, the file manager always has struck me as a sore thumb, bolted on to CWP -- and it looks to be an implementation of the Vue library, with treeVue and other JS integrated. Probably overdue for some attention & modernization. It hasn't changed much at all over the last 5+ years. Probably plenty of fleas...
But, the file manager always has struck me as a sore thumb, bolted on to CWP -- and it looks to be an implementation of the Vue library, with treeVue and other JS integrated. Probably overdue for some attention & modernization. It hasn't changed much at all over the last 5+ years. Probably plenty of fleas...
32
CentOS-WebPanel Bugs / Re: [CRITICAL] Multiple CWP Servers Infected Arbitrary PHP Code Execution via Publ
« Last post by Doridian on July 08, 2025, 05:14:52 PM »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).
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).
33
CentOS-WebPanel Bugs / Re: [CRITICAL] Multiple CWP Servers Infected Arbitrary PHP Code Execution via Publ
« Last post by kandalf on July 08, 2025, 04:39:44 PM »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.
Its 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.
34
CentOS-WebPanel Bugs / Re: [CRITICAL] Multiple CWP Servers Infected Arbitrary PHP Code Execution via Publ
« Last post by Doridian on July 08, 2025, 04:30:03 PM »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.
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.
35
CentOS-WebPanel Bugs / Re: [CRITICAL] Multiple CWP Servers Infected Arbitrary PHP Code Execution via Publ
« Last post by kandalf on July 08, 2025, 03:03:33 PM »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.
36
Installation / Re: I don't receive a single message from root..??
« Last post by overseer on July 08, 2025, 02:50:57 PM »Code: [Select]
mydestination = $myhostnameis most canonical, then you only have to change it once at the top of the file if the hostname needs to change. But for any of the main directives (mydestination, smtp_helo_hostname, smtpd_sasl_local_domain), you can hardcode the hostname if you want. Just get rid of CWP's buggy double equals on a line (interpreted as setting a string, then a variable). 37
Backup / Re: Can't locate diagnostics.pm in @INC (you may need to install th....
« Last post by overseer on July 08, 2025, 02:45:42 PM »See Starburst's post here to see his prerequisites on AL9 before installing CWP:
https://forum.centos-webpanel.com/csf-firewall/possible-fix-to-why-csflfd-isn-t-installing/msg51087/#msg51087
https://forum.centos-webpanel.com/csf-firewall/possible-fix-to-why-csflfd-isn-t-installing/msg51087/#msg51087
38
CentOS-WebPanel Bugs / Re: [CRITICAL] Multiple CWP Servers Infected Arbitrary PHP Code Execution via Publ
« Last post by overseer on July 08, 2025, 02:25:06 PM »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:
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"39
Backup / Re: Can't locate diagnostics.pm in @INC (you may need to install th....
« Last post by venty on July 08, 2025, 02:21:52 PM »How did you install perl? Base install of AlmaLinux 9, then CWP installer? Anything custom installed as pre-requisites (as Starburst recommends on an AL9 system)?
Hi,
I just installed base AL 9, then CWP, and from Starburst I used this, if it's relevant:
UPDATE DEPENDENCIES
Code: [Select]
dnf install php-cli libsodium libsodium-devel php-sodium php-pecl-zip php-pecl-mailparse php-mbstring php-pear php-devel php-pecl-imagick
Code: [Select]
pecl channel-update pecl.php.net
I also upgraded to MariaDB 10.11.13, and I use the rules OWASP CRS v4.16.0...
BR
Venty
40
Installation / Re: I don't receive a single message from root..??
« Last post by venty on July 08, 2025, 02:12:36 PM »Hi,
Ok, lastly, for this topic, the following remains as a summary:
1.In main.cf under #network settings, replace:
"mydestination = $myhostname = name.hostname.com'
with "mydestination = srv1.domain.net"
?
2. To the main.cf file, add:
UNDER (# rules restrictions):
smtp_helo_name = $myhostname
?
BR
Venty
Ok, lastly, for this topic, the following remains as a summary:
1.In main.cf under #network settings, replace:
"mydestination = $myhostname = name.hostname.com'
with "mydestination = srv1.domain.net"
?2. To the main.cf file, add:
UNDER (# rules restrictions):
smtp_helo_name = $myhostname
?BR
Venty
