Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
I can find attempts to use the exploit too but thus far they are having no luck & I can find no introduced files in home or tmp directories. I run Alma 8.

[06/Jul/2025:01:21:48 +1000] "POST /user/index.php?module=filemanager&acc=findFiles HTTP/1.0" 403 199 - Was from a ColoCrossing IP (no surprises there).

Have renamed file manager for security and shall actively watch.
22
Firstly, I didn't say delete, I said rename a single file that inconveniences your users slightly...
But you did say delete, quoted twice in the previous posts on this thread. I call that dubious advice, as with removing the .php extension -- which won't neuter it -- a file containing PHP code can still be run by a php interpreter.

Yes, but the loader of CWP will not find the file, and therefor not load it. That is what matters here. The file being loaded by the index.php in some way, and if it is renamed, that won't happen.

Also the file is literally part of the CWP distribution, so even if you delete it and want it back, it isn't like it is hand written custom code. It takes 5 minutes to get back at the most.



People like you really make me think twice about trying to help others out. Talking with such upmost confidence of things you obviously haven't tried.
23
Firstly, I didn't say delete, I said rename a single file that inconveniences your users slightly...
But you did say delete, quoted twice in the previous posts on this thread. I call that dubious advice, as with removing the .php extension -- which won't neuter it -- a file containing PHP code can still be run by a php interpreter.
24
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)
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).

Exactly, delete OR rename. I don't see your point.
25
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)
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).
26
PHP / Re: FYI - ionCube Release new loaders 13.3.0
« Last post by Starburst on July 08, 2025, 11:03:25 PM »
The current version of the ionCube Loaders is current at 14.4.1.

And yes, it's better to be safe than sorry.
27
Mod_Security / ModSecurity updated to 2.9.11
« Last post by Starburst on July 08, 2025, 11:01:47 PM »
If you already have updated your ModSecurity from the stock 2.9.1, to e.g. 2.9.8, this article will show you how to update to 2.9.11.

And if you want, there is also a script you can download & run.

https://starburst.help/control-web-panel-cwp/modsecurity-running-with-control-web-panel/update-modsecurity-to-2-9-11-running-cwp-and-apache-on-almalinux-8-9/
28
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...

Firstly, I didn't say delete, I said rename a single file that inconveniences your users slightly (they now have to use SFTP or FTP to change files, rather than a WebUI), not a core feature of CWP in the first place. You could always install a WebFTP plugin to temporarily stopgap the functionality, too.

Further, I can't force people to listen, nor do I intend to try. I'm doing my best to keep people safe. And, as stated, am willing to prove the exploit is real if that helps people feel better about it (without giving it away of course, since not wanting it to spread).
What people do with the information I provide is up to them.

Lastly, I have gotten a response from CWP support they'll have a developer look at my report, so let's hope something good comes out of that before more people get their websites turned into malware.
29
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...
30
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).
Pages: 1 2 [3] 4 5 ... 10