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

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...

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.

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).

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.

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.

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.

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.

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.

You are gravely mistaken about this.

This is a critical security issue. I've included two links from official security sources that detail the problem: https://fenrisk.com/rce-centos-webpanel and https://cybersecuritynews.com/linux-centos-web-panel-vulnerability/.

Doridian did an excellent job by adding a temporary fix to prevent more attacks. If you don't believe us, then please stop making unhelpful comments.
Otherwise, give us a domain and user account from one of your servers, and we'll prove you wrong.

Funny, this started as an information sharing thread but then devolved from there -- getting into sour personal attacks. I'm sorry I ever touched this tar baby. My point was, I can appreciate your report and will keep it on the radar because I see that you have a history here and contribute in a meaningful way. But when someone brand new comes on the scene trotting out security buzzwords and offering dubious advice about deleting the filemanager (instead of mitigating the attack vector in a non-destructive way)... well, take that for what it is. I'll go back to monitoring my servers now.

(Both security disclosures you linked to claim the CWP devs have patched the flaw, and both indicated it was against CentOS 7 -- so it bears monitoring but not hyperventilating.)

Funny, this started as an information sharing thread but then devolved from there -- getting into sour personal attacks. I'm sorry I ever touched this tar baby. My point was, I can appreciate your report and will keep it on the radar because I see that you have a history here and contribute in a meaningful way. But when someone brand new comes on the scene trotting out security buzzwords and offering dubious advice about deleting the filemanager (instead of mitigating the attack vector in a non-destructive way)... well, take that for what it is. I'll go back to monitoring my servers now.

(Both security disclosures you linked to claim the CWP devs have patched the flaw, and both indicated it was against CentOS 7 -- so it bears monitoring but not hyperventilating.)

That’s not accurate. The problem isn’t limited to CentOS 7 — it also affects AlmaLinux 8. The vulnerability lies in filemanager.php, which is written in PHP and is identical across all supported OSes. What changes between CentOS and AlmaLinux is the system environment, not the CWP PHP panel code.

All six of my servers run AlmaLinux 8, and three were compromised due to this exact issue.

I don’t know Doridian personally, but his suggested solution is a good temporary mitigation. Renaming or removing filemanager.php is low-risk, and CWP will restore it once an official patch is released. I’ve renamed it on all my servers, it’s a simple step to reduce exposure.

This is a critical vulnerability, and it is not fixed in the current version, despite what the articles say.

You can check if your server might have been affected by running:
find /home -type f -name "defauit.php" 2>/dev/null

That file (defauit.php with an “i”) appeared across all compromised accounts on my affected servers.

I had the same problem, was going crazy, thinking it was a wordpress vulnerability, then started seeing processes from one user trying to access other users. This made me notic only 3 of my users are in jail and others aren't, no idea why this behaviour by CWP.

I've ran:

Code: [Select]

find / -type f \( -name "defauit.php" -o -name "nbpafebaef.jpg" \) -exec rm -f {} + 2>/dev/nullto delete all of this 2 files.

I've also renamed filemanager.php

Could any one provide with more insight/what more steps should be done to make sure it's clean?

I had the same problem, was going crazy, thinking it was a wordpress vulnerability, then started seeing processes from one user trying to access other users. This made me notic only 3 of my users are in jail and others aren't, no idea why this behaviour by CWP.

I've ran:

Code: [Select]

find / -type f \( -name "defauit.php" -o -name "nbpafebaef.jpg" \) -exec rm -f {} + 2>/dev/nullto delete all of this 2 files.

I've also renamed filemanager.php

Could any one provide with more insight/what more steps should be done to make sure it's clean?

What do you mean by “my users are in jail”?

Also, make sure to delete two hidden files that may have been used in the attack. They were found in /tmp on my compromised servers:
   •   .tmp_baf
   •   .auto_monitor

These files are part of the script that spreads the malicious payload across all user accounts.

Let us know if you find anything else suspicious, we’re trying to understand the full scope of this breach.

I noticed I had 3 users in /home/jail/ possibly from jailkit. But I never actually made any configs about this, so 3 of my users are using it, and the others aren't. That's just something odd but probably unrelated.

About the hidden files, just deleted them, thanks!
I had first renamed /tmp to /tmp_inf and created a new /tmp but that broke my websites sessions.

I will try to help as I can, I only have medium server experience!
I've noticed some executables and scripts being created and hidden inside wordpress folders, I've cleared them but if more appear I'll share here the names and contents.

Also just to confirm, I am indeed using AlmaLinux 8.10 (Cerulean Leopard)

# CVE-2025-48703 Vulnerability and Implemented Security Measures

Hello CWP Community,

We recently became aware of a security vulnerability identified as **CVE-2025-48703**, affecting the file manager module in CWP. You can find more details on [GitHub](https://github.com/trh4ckn0n/CVE-2025-48703). To help the community, I’d like to share the steps we took to secure our server (running CentOS 8.5.2111 with CWP).

## Implemented Security Measures

1. **Blocking File Manager Access** 
   The vulnerability involves the file manager module. To mitigate this, we added the following `.htaccess` rules to all users’ `public_html` directories:
   ```apache
   <IfModule mod_rewrite.c>
       RewriteEngine On
       RewriteCond %{QUERY_STRING} module=filemanager&acc=findFiles [NC]
       RewriteRule ^ - [F,L]
   </IfModule>
   ```
   We applied these rules across all relevant user directories.

2. **Firewall Blocking for Suspicious Access** 
   We blocked suspicious IP addresses using the firewall:
   ```bash
   firewall-cmd --permanent --add-source=<suspicious-ip> --zone=block
   firewall-cmd --reload
   ```

3. **Fixing User Permissions** 
   To correct file and directory permissions, we used CWP’s permission repair script:
   ```bash
   /usr/local/cwpsrv/htdocs/resources/scripts/fixperms <username>
   ```

4. **CWP Update** 
   We updated CWP to the latest version:
   ```bash
   /usr/local/cwpsrv/htdocs/resources/scripts/update_cwp
   ```

5. **Malware Scanning** 
   We performed scans to detect malicious files:
   ```bash
   /usr/local/cwpsrv/htdocs/resources/scripts/maldet_scan
   rkhunter --check
   ```

6. **PHP File Monitoring System** 
   For our high-traffic server, we developed a script to monitor newly created `.php` files. The script recursively monitors user directories, skips session files (e.g., `sess_*`), and sends hourly email notifications for detected `.php` files. It uses `inotify-tools` and is compatible with CentOS 8. If you’d like the script details, please let me know!

## Additional Recommendations
- **Email Notifications**: We use Postfix for email notifications. If you encounter email issues, check the Postfix logs:
  ```bash
  tail -n 50 /var/log/maillog
  ```
  Alternatively, you can configure Gmail SMTP:
  ```bash
  dnf install -y cyrus-sasl-plain
  nano ~/.mailrc
  ```
  Contents:
  ```
  set from="your-email@gmail.com"
  set smtp=smtp.gmail.com:587
  set smtp-auth-user=your-email@gmail.com
  set smtp-auth-password=your-app-specific-password
  set smtp-auth=login
  set ssl-verify=ignore
  ```

- **inotify Limits**: For recursive monitoring on high-traffic servers, we increased `inotify` limits:
  ```bash
  echo 524288 | sudo tee /proc/sys/fs/inotify/max_user_watches
  sudo sysctl -p
  ```

These measures have secured our server and enabled us to monitor new `.php` files effectively. If you’ve encountered CVE-2025-48703 or implemented additional measures, please share your experiences. Community feedback is invaluable!

Thank you, 
Mr Green