Recent Posts

Pages: [1] 2 3 ... 10
1
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.
2
Mod_Security / Re: OWASP CRS v4.15.0 Just Release
« Last post by mind5t0rm on Today at 10:43:02 AM »
That's very helpful because I plan to update the OWASP rules to the latest version and we are hosting various websites.

Thanks.
3
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.
4
PHP / Re: FYI - ionCube Release new loaders 13.3.0
« Last post by venty on Today at 06:52:48 AM »
Hi,

Many thanks to Starburst for this post...

His last post on the subject:

https://starburst.help/control-web-panel-cwp/control-web-panel-cwp-admin-tutorials/ioncube-error-after-building-php-8-3-with-cwp-on-almalinux-8-9/

but should I do it on the condition that I will not be using PHP 8.3 for now?

BR
Venty
5
Installation / Re: I don't receive a single message from root..??
« Last post by venty on Today at 06:25:24 AM »

Hi,

Thank you very much, I understood everything, just one last thing to clarify :)

When going through CWP,  I go to the Postfix Mail Server Manager, and check the box where it is shown in the picture:

https://prnt.sc/TXLDNMUAot9p

In this case, when building the mail server, what exactly add or change in the entries in the main.cf file ?

Many thanks in advance!

BR
Venty

Hi,

My question is whether when rebuilding the mail server, will everything we added or changed in the main.cf file be saved or deleted?

Thank you very much!

BR
Venty
6
Hi,

I returned installation of a  CWP (with AL 9.6) and have a standard configuration for backup, but today I checked and found the following in the archive message:

etc/cron.daily/csget:

Can't locate diagnostics.pm in @INC (you may need to install the diagnostics module) (@INC contains: /usr/local/lib64/perl5/5.32 /usr/local/share/perl5/5.32 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5) at /etc/cron.daily/csget line 9.
BEGIN failed--compilation aborted at /etc/cron.daily/csget line 9.

How to check and/or fix?

Thank you very much!

BR
Venty
7
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)
8
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.
9
Let me try
Thanks
10
The error appears to be on the legacy CentOS 7 end; no problems on the AlmaLinux 8 end. The 35 in the SSL connect error was a good clue:
Code: [Select]
[root@srv]# /usr/local/cwpsrv/htdocs/resources/scripts/check_api
User API port 2302 check: OK
Oauth query check: OK
User API folder check: OK
External API port 2304 check: OK
curl: (35) SSL received a record that exceeded the maximum permissible length.
External API files and htaccess : OK
CSF Firewall status check: DISABLED
And testing curl directly:
Code: [Select]
[root@srv]# curl -v https://127.0.0.1:2304/v1/testapi/
* About to connect() to 127.0.0.1 port 2304 (#0)
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 port 2304 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* NSS error -12263 (SSL_ERROR_RX_RECORD_TOO_LONG)
* SSL received a record that exceeded the maximum permissible length.
* Closing connection 0
curl: (35) SSL received a record that exceeded the maximum permissible length.
Pages: [1] 2 3 ... 10