Control Web Panel
WebPanel => CentOS-WebPanel Bugs => Topic started by: kandalf on July 07, 2025, 03:29:52 PM
-
Im 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 CWPs file handling or directory security
⚠️ Request to CWP Team
Please investigate this urgently. Its 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, Im happy to provide them privately.
-
Are you running malware detection scans on your system?
https://basaranturizm.com (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.
-
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.
-
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
-
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)
-
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.
-
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)
-
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.
-
Youre 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
Ive renamed it to filemanager.php.disabled to block access while waiting for an official fix.
Issue 2: Lateral File Injection via /tmp (Needs confirmation)
Whats 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, heres the key problem:
Even if filemanager.php was used to inject a file into one account, it doesnt 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. Theres 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.
-
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
-
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:
[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"
-
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:
[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.
-
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 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.
-
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).
-
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.)
Thats not accurate. The problem isnt 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 dont 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. Ive renamed it on all my servers, its 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:
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:
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, were 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 (https://github.com/trh4ckn0n/CVE-2025-48703)). To help the community, Id 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 CWPs 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 youd 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 youve encountered CVE-2025-48703 or implemented additional measures, please share your experiences. Community feedback is invaluable!
Thank you,
Mr Green
-
@mrgreen Thank you for this valuable feedback and GitHub link!
On our end, since Maldet's signature is from February and Rkhunter is discontinued since 2018, we actually ran Thor Lite w/ a collection of YARA custom rules to find and clean everything across the server.
Besides that, we blocked access to "module=filemanager&acc=findFiles" through CloudFlare only allowing our Whitelist of IPs to access it.
Would you be so kind as to share the inotify script for the .php files?
-
My Approach to Stopping the CWP File‑Manager Exploit
- 1. Scan & Identify Malware
Searched for obfuscated PHP payloads
grep -rniE "(eval\s*\(|base64_decode|gzinflate|str_rot13|shell_exec|proc_open|passthru|system)" \
/home/*/public_html/
Caught the classic pair in every account:
nbpafebaef.jpg (PHP in disguise)
defauit.php (web‑shell)
Found tmp propagators reported in the forum thread:
/tmp/.auto_monitor and /tmp/.tmp_baf[/li]
[li]2. Clean & Quarantine
mkdir /root/quarantine
mv /home/*/public_html/{nbpafebaef.jpg,defauit.php} /root/quarantine 2>/dev/null
mv /tmp/.auto_monitor /tmp/.tmp_baf /root/quarantine
Manually opened every recently‑modified functions.php; all were clean, so no theme replacement required.[/li]
[li]3. Global Block via ModSecurity (NOT .htaccess)
Added to /usr/local/apache/modsecurity-cwaf/custom_user.conf:
# Put your custom ModSecurity directives here
# Please don't remove this file
# Block CWP filemanager exploit attempts (CVE-2025-48703)
SecRule REQUEST_URI "@contains /user/index.php" \
"id:4870301,phase:2,deny,status:403,log,msg:'[CWP Exploit Block] Block access to module=filemanager&acc=findFiles',\
chain"
SecRule ARGS:module "@streq filemanager" \
"chain"
SecRule ARGS:acc "@streq findFiles"
Restart Apache:
systemctl restart httpd[/li]
[li]4. Verification (cURL)
curl -X POST "https://your-domain.com/user/index.php?module=filemanager&acc=findFiles" \
-A "Mozilla" -I
# Expected: HTTP/1.1 403 Forbidden
403 confirms ModSecurity now blocks the exploit endpoint for every vHost.[/li]
Result: Infection removed, endpoint sealed, and logfile shows only blocked attempts.
Hope this helps anyone still cleaning up from the same CVE!
-
I saw that a new version was released 0.9.8.1207, did this update fix the filemanager exploit?
CWP team is doing a really bad job, no official reply no information, completely unreal.
-
I saw that a new version was released 0.9.8.1207, did this update fix the filemanager exploit?
CWP team is doing a really bad job, no official reply no information, completely unreal.
Sure would be nice to know.
-
Can someone test the latest version to see if the exploit still works?
-
just checked it, fixed. can someone also please validate the same.
-
just checked it, fixed. can someone also please validate the same.
I checked on my server. IT fixed on version 1207
-
I just saw I was affected by this issue. The php file was in each of my /home/ directories public_html folder. The modified date for the file was July 6 but my CWPpro version is currently 0.9.8.1207. Is there a way to find out exactly when this version was released?
-
🛡️ REAL-TIME MALWARE PROTECTION FOR CWP/CENTOS Auto-remove defauit.php & nbpafebaef.jpg
This guide helps you automatically detect and remove dangerous PHP backdoors named:
- defauit.php (typo: not default)
- nbpafebaef.jpg (a disguised PHP file)
These are known malware injected in CWP-based servers. We will:
- Quarantine existing files
- Monitor /home in real-time
- Auto-remove any newly created malicious files
Works on CentOS / AlmaLinux / CloudLinux using systemd + inotify.
---
✅ STEP 1 Install inotify-tools
yum install -y inotify-tools
---
✅ STEP 2 Create the watcher script
nano /usr/local/bin/watch_defauit.sh
Paste this content:
#!/bin/bash
WATCH_DIR="/home"
LOGFILE="/var/log/defauit_watch.log"
QUARANTENA="/root/quarantena_php"
mkdir -p "$QUARANTENA"
echo "### START $(date) - Initial scan" >> "$LOGFILE"
# PHASE 1 Find and move existing malicious files
find "$WATCH_DIR" -type f \( -name "defauit.php" -o -name "nbpafebaef.jpg" \) | while read FILE; do
echo "[!] FOUND EXISTING: $FILE → Moved to quarantine" | tee -a "$LOGFILE"
mv "$FILE" "$QUARANTENA/" 2>/dev/null
done
# PHASE 2 Live monitoring
inotifywait -mr -e create -e moved_to --format '%w%f' "$WATCH_DIR" | while read FILE; do
BASENAME=$(basename "$FILE")
if [[ "$BASENAME" == "defauit.php" || "$BASENAME" == "nbpafebaef.jpg" ]]; then
echo "[!] NEW FILE DETECTED: $FILE → Moved to quarantine" | tee -a "$LOGFILE"
mv "$FILE" "$QUARANTENA/" 2>/dev/null
fi
done
Make it executable:
chmod +x /usr/local/bin/watch_defauit.sh
---
✅ STEP 3 Create the systemd service
nano /etc/systemd/system/watch-defauit.service
Paste this config:
[Unit]
Description=Live watch for defauit.php & nbpafebaef.jpg
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/watch_defauit.sh
Restart=always
RestartSec=5
User=root
[Install]
WantedBy=multi-user.target
Enable and start the service:
systemctl daemon-reexec
systemctl daemon-reload
systemctl enable --now watch-defauit.service
---
✅ STEP 4 Increase inotify watch limit (if needed)
If you get "upper limit on inotify watches reached" error:
echo fs.inotify.max_user_watches=524288 >> /etc/sysctl.conf
sysctl -p
---
✅ RESULT
- All existing and new files named defauit.php or nbpafebaef.jpg under /home will be moved to:
/root/quarantena_php/
- A log of all detections is saved in:
/var/log/defauit_watch.log
---
Stay safe!
-
In the server-world, blindly following advice & installing scripts from people with a total of ONE post on this forum is the equivalent of taking candy from strangers.
If you keep your server updated, this was fixed 2 weeks ago by the CWP dev team. And by now if the perpetrators have any sense, the IOC has changed and it won't do any good to look for files named those strings.
-
I also see this file in atleast one of my sites.
Now what is the proper solution to fix this?
I have AL 8 with latest CWP
-
Are you running malware detection scans on your system?
ClamAV Maldet Scan do not detect these 2 files
I am running 3 VPS with AL8
All 3 are affected.
Have manually removed these files
Have the latest CWP
Anthing else to be done? Please suggest
-
See @overseer Reply #39
As long as your AL is up2date run:
dnf --refresh updateand you are running 0.9.8.1210 you should be fine.
But also having a secure PHP helps, by default CWP leaves nothing disabled so users can configure their server as they need.
ModSecurity has also been catching this, which again, needs to be kept updated.
-
I have 3 servers running Alma 8 with CWP Pro updated as of today. I install updates every day as they are released.
In addition to all CWP security features being active, I use Fail2ban, but clearly nothing stopped the malware injection, since an exploit in the file manager was used.
On some sites, I found both files (defauit.php and the .jpg), and in the /home directories where there were no hosted files, only defauit.php was present. I manually deleted the files from each home directory one by one, then searched across all servers for any remaining ones using this command, and double-checked by reviewing the logs keeping in mind that if an account has subdomains, it's also necessary to search and delete defauit.php and the .jpg from those folders too.
COMMON DATA:
The Attackers IP
Initial Date: July 4th
grep "defauit.php" /usr/local/apache/logs/access_log*
and it will show us ::
198.144.182.13 - - [06/Jul/2025:12:27:39 -0300] "POST /defauit.php?id=1 HTTP/1.0" 200 34
198.144.182.13 - - [06/Jul/2025:12:50:56 -0300] "GET /defauit.php?id=1 HTTP/1.0" 200 1
198.144.182.13 - - [06/Jul/2025:12:50:56 -0300] "POST /defauit.php?id=1 HTTP/1.0" 200 34
198.144.182.13 - - [06/Jul/2025:13:00:05 -0300] "POST /defauit.php?id=1 HTTP/1.0" 200 34
198.144.182.13 - - [06/Jul/2025:14:36:03 -0300] "POST /defauit.php?id=1 HTTP/1.0" 200 34
198.144.182.13 - - [06/Jul/2025:15:59:39 -0300] "POST /defauit.php?id=1 HTTP/1.0" 301 255
I didn't find the files .auto_monitor and/or .tmp_baf on any server
find /home/*/tmp -type f -name ".auto_monitor" 2>/dev/null
find /home/*/tmp -type f -name ".auto_monitor" -exec ls -l {} \; 2>/dev/nul
As an additional measure, I added the source IP (198.144.182.13) to the blocked IPs in CSF, since I see it's the same for all cases. I also inserted the mentioned rule in ModSecurity, correcting the last line (the \ was missing)
/usr/local/apache/modsecurity-cwaf/custom_user.conf:
# Block CWP filemanager exploit attempts (CVE-2025-48703)
SecRule REQUEST_URI "@contains /user/index.php" \
"id:4870301,phase:2,deny,status:403,log,msg:'[CWP Exploit Block] Block access to module=filemanager&acc=findFiles',chain"
SecRule ARGS:module "@streq filemanager" \
"chain"
SecRule ARGS:acc "@streq findFiles" \
I also made sure everything was up to date using dnf --refresh update.
Remember to check the subdomains and make sure this doesn't happen again!
-
Hi, I have 6 servers and the same error occurs on all of them. A new version, 0.9.8.1211, was released this week.
Does anyone know if the error has been fixed yet?
I renamed the browser file again and it works again for clients...
Does anyone have more information?
Thanks!!
-
This is NOT a CWP bug.
PHP Injection Attacks will happen whenever.
You need to have your php.ini secured, and run ModSecurity with the latest OWASP CRS ruleset.
Along with running the latest PHP version you choose, 8.1, 8.2, 8.3 or 8.4
You'll also need to configured the OWASP base rules for services you run on that server.
NOTE: The CWAF ruleset is dead, and the last update was over a year ago.
Which is sad, this was a great ruleset.
For the PHP Injection Attack that has been going around, there has been fixes here how to clean up your PHP-FPM.
-
Same problem here, someone fixed it?
-
You can Google the fix, it's a standard PHP Injection Attack due to an insure PHP configuration.
It also only affects people still using the EOL CentOS 7 OS.
But I think someone posted the fix here in one of the threads as well.
-
🛑 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).
i also found these two files in my public_html folder, what should i do with them should i deleted them both? how to make sure there is no other similar exploit?
-
Starburst already gave the answer above:
You need to have your php.ini secured, and run ModSecurity with the latest OWASP CRS ruleset.
Along with running the latest PHP version you choose, 8.1, 8.2, 8.3 or 8.4
And he has guides for updating ModSecurity and the OWASP CRS ruleset (tested on both AlmaLinux 8 and 9):
https://starburst.help/control-web-panel-cwp/modsecurity-running-with-control-web-panel/update-modsecurity-to-2-9-12-running-cwp-and-apache-on-almalinux-9/
https://starburst.help/control-web-panel-cwp/modsecurity-running-with-control-web-panel/update-owasp-crs-ruleset-running-cwp-and-apache-on-almalinux-9/
-
i understand that is for the future prevention but what to do with the current infection . should i delete the below two file manually from all sites public_html directories ?
defauit.php
nbpafebaef.jpg
-
Oh for sure -- I thought you had already done that as a first step. They are likely what gives the attacker persistence on your server.
-
Since I don't need the user panel, I removed ports 2082 and 2083 from the firewall configuration file. This prevents access to the user panel.
To do this: log in to the admin panel, go to Firewall, and configure the "Opened TCP/UDP Ports". This will open the configuration file in edit mode. Remove ports 2082 and 2083 (you can find them under "Allow outgoing TCP ports" and "Allow incoming TCP ports") and then restart the firewall.
You will still be able to access the user panel if you need to perform actions that cannot be done through the admin panel, because when you log in as an admin in the admin panel, your IP is unrestricted by the firewall. Other users will experience connection timeouts.
I also recommend changing your users’ passwords, as the generated passwords are quite weak. Why the concern?
I discovered that long time ago I had created a username incorrectly by swapping two characters, then deleted it and created another one. Later, I removed that second user as well since it was not needed. Although these users are removed and non-operational, they still appear in the system, specifically in the "/etc/shells" file.
After checking the access logs, I saw that these two users had been exploited by the attacker. So I assume the attacker was able to read many files including "/etc/shells".
For testing, I logged in as a non-sudo user and confirmed that I could access and modify content in many parts of the server. So by the SSH access, you are not restricted only to the /home folder, you can explore almost all directories and content of the server. So It is also possible to extract password hashes for cracking. Or maybe your server can be ordered to brute force passwords and send it to the attacker.
Additionally, last night I turned off my httpd service, but by the morning it was running again. It was restarted at 4 AM. I am not sure what caused it to turn back on, but this behavior looks weird.
I do not intend to use my server for shared hosting, so I am not particularly concerned. However, granting this kind of shell access to regular users does not seem appropriate.
-
1. You also need to harden your PHP configuration.
2. Not be running CentOS 7 still, update to AL8.
3. Only firewall ports that should be open, are the bare minimum your server needs.
With Admin IP's whitelisted.
-
Additionally, last night I turned off my httpd service, but by the morning it was running again. It was restarted at 4 AM. I am not sure what caused it to turn back on, but this behavior looks weird.
Various cron tasks will restart httpd as a matter of course. And CWP's cron tasks run overnight, particularly AutoSSL which runs at 4 am. If you really want to disable it, you could remove those cron tasks, issue systemctl disable httpd and block incoming ports 80 and 443 on the firewall. But then you won't have a web server anymore. But maybe that's what you're after...
-
Since this WAS a vulnerability in CWP, there is no point in considered that if a server was affected, there is no backdoor still installed.
The report is here: https://fenrisk.com/rce-centos-webpanel
So, if you are still in a server that have been compromised, there is no way around to know what have been done. Remove the files can be suficient, sure. But you don't know if anything else was compromised.
The information that this is a fault from PHP, WordPress or some script in the user server are not true. If you see the files stated in the first message in your accounts, your server was exploited due to the CWP vulnerability.
Also: we are still waiting for any information related to this by the CWP team.
-
So, if you are still in a server that have been compromised, there is no way around to know what have been done. Remove the files can be suficient, sure. But you don't know if anything else was compromised.
As far as I could see, this attack was only able to compromise non-sudo accounts. Through trial and error (using combinations of domains related to the server), the attacker only needed to find one valid user. Once that happened, he was able to discover other usernames to exploit additional non-sudo accounts.
In the worst-case scenario, the attacker was able to explore the server in read-only mode — likely dumping databases, backup files, SQL user credentials, and so on, across the entire system.
Non-sudo accounts should not have read access across the whole system, even the /etc/shadow file is readable with them.
Write access was only possible within the affected users’ home directories, including the /tmp directory.
Regarding WordPress what happened to your websites? Mine were defaced with a fake drop-shipping-style store, and the results got messed up in Google Search. Usually, these deface hacks are triggered when the referrer is Google, but this one didn’t behave that way. I only discovered it's real face by simulating a Googlebot user agent in my browser.
The wordpress code got so messed up that I can't even find where the infected code is. I'll have to reconfigure a brand new installation.
It looked like this:
https://i.imgur.com/zn6ji93.png
-
As far as I could see, this attack was only able to compromise non-sudo accounts. Through trial and error (using combinations of domains related to the server), the attacker only needed to find one valid user. Once that happened, he was able to discover other usernames to exploit additional non-sudo accounts.
The file dropped in the directory was a web shell. The attacker indeed have interest in change the webpages to a pseudo store, but with the webshell, he can have access to any account in the server, and any file on it - including the way of change any system file or configuration.
Yes, the exploit starts with a non-sudo user, but can change any other file on the system. If that happend or not... is complicated to know.
In the worst-case scenario, the attacker was able to explore the server in read-only mode likely dumping databases, backup files, SQL user credentials, and so on, across the entire system.
Non-sudo accounts should not have read access across the whole system, even the /etc/shadow file is readable with them.
Write access was only possible within the affected users home directories, including the /tmp directory.
With the webshell, you can have full access to the system, unless you have some way of mitigate that - like Cloudlinux does. They have a virtual filesystem to every users, so even if the website is exploited with a webshell, the attacker can only see the virtual root filesystem, not the actual system.
CWP doesn't have that. With a webshell, they can see and edit or send any command to the server.
If you use the CWPSecure kernel, i don't know if they have that protection. But i bet most of the servers don't use that.
Regarding WordPress what happened to your websites? Mine were defaced with a fake drop-shipping-style store, and the results got messed up in Google Search. Usually, these deface hacks are triggered when the referrer is Google, but this one didnt behave that way. I only discovered it's real face by simulating a Googlebot user agent in my browser.
The wordpress code got so messed up that I can't even find where the infected code is. I'll have to reconfigure a brand new installation.
It looked like this:
https://i.imgur.com/zn6ji93.png
Yes, the exploit appears to be target to wordpress websites. The file that actualy deploys the exploit can be dormant in the system for months, and only activated when the attacker sees it. Is a fake JPG file with PHP code in it.
-
Do you know which wordpress files got infected?
-
It can vary from installation to installation.
In some, the backdoor stays dormant in the server, waiting to be "activated" - the file placed first is just a exploit, to create the webshell file if access with a POST request and specific queries. If the request is done, the file "defaiult.php" is created, and that is the real webshell file.
After that, anything can be changed realy. I notice some plugins changed, and theme files. Also there is a mu-plugin that is created to the redirect.
Of course, data in the BD and other details, like the WordPress configuration file, are also changed/access. If you have any password or WordPress salt in there, change them. But at this point, the installation in your server should NOT be considered safe.
You can still use it... but at your own risk.
-
Starburst already gave the answer above:
You need to have your php.ini secured, and run ModSecurity with the latest OWASP CRS ruleset.
Along with running the latest PHP version you choose, 8.1, 8.2, 8.3 or 8.4
And he has guides for updating ModSecurity and the OWASP CRS ruleset (tested on both AlmaLinux 8 and 9):
https://starburst.help/control-web-panel-cwp/modsecurity-running-with-control-web-panel/update-modsecurity-to-2-9-12-running-cwp-and-apache-on-almalinux-9/
https://starburst.help/control-web-panel-cwp/modsecurity-running-with-control-web-panel/update-owasp-crs-ruleset-running-cwp-and-apache-on-almalinux-9/
Those guides are pointless for this issue.
They are to protect the websites, not the CWP itself. The RCE was a exploit in the CWP file manager, not in the websites.
Kindle don't provide false information, and dont mislead users to somethint that is not. You don't appear to even know what is a exploit... even less to provide info about waf protection rules - that, again, DO NOTHING about this issue in CWP.
-
Hi djprmf,
Thank you for contribution in the 1st paragraph, it is correct and may yet proove helpful to someone.
Your 2nd paragraph however is simply a personal attack on a well respected member of our community to which I and many other members in this forum do not appreciate. Please reframe from such outbursts or if you cannot simply STFU.
-
Hi 6sense.
https://forum.centos-webpanel.com/informations/is-cwp-still-maintained/
Read the topic.
You cannot take seriously someone that don't know the difference between a PHP exploit and a exploit in a implementation of the code in a application.
He could be a great person, but doesn't know what is talking and is misleading others.
Is ok to say that you don't know something.it is NOT OK to provide false information. And that was what he have done the entire time.
So yes,I provide proofs and knowledge,things that ANYONE CAN SEE AND KNOWS.
not a word from someone...
Bit is simple.prove me wrong....
Then take your conclusions...
-
Are you just trying to inflate your post count? It seems that any meaningful contribution to this thread and forum community has ceased a while ago. You're beating a war drum with no soldiers rallying behind you, so it rings more than hollow.
-
I have not posted False or Mis-information.
Your post doesn't even make sense.
And all here know that I know what I'm talking about from my posts.
So just insulting me and others here hasn't made you any friends and lost you any support.
Unlike yourself.
I'm guessing your some kid or tween who just wants to come on the forums, post your BS mis-information, and argue with everyone.
So FOCUS...
-
This is NOT a CWP bug.
PHP Injection Attacks will happen whenever.
You need to have your php.ini secured, and run ModSecurity with the latest OWASP CRS ruleset.
Along with running the latest PHP version you choose, 8.1, 8.2, 8.3 or 8.4
You'll also need to configured the OWASP base rules for services you run on that server.
NOTE: The CWAF ruleset is dead, and the last update was over a year ago.
Which is sad, this was a great ruleset.
For the PHP Injection Attack that has been going around, there has been fixes here how to clean up your PHP-FPM.
Sure, lets focus and talk.
Can you explain this sentence that you are providing in the quote text?
Kindly inform us how do you say that this is NOT a CWP security vulnerability and how do you get to that conclusion. Plese, don't refrain from use "tech mambo jambo", we are all sysadmin here after all :)
-
After that, anything can be changed realy. I notice some plugins changed, and theme files. Also there is a mu-plugin that is created to the redirect.
Location of those changes? Where can i find them?
-
After that, anything can be changed realy. I notice some plugins changed, and theme files. Also there is a mu-plugin that is created to the redirect.
Location of those changes? Where can i find them?
The attacker have access to every file in your system. It could change anything...
I cannot provide you a "list" of what was changed in your case. Could be just the theme files, or nothing at all - some servers may still have the backdoor placed due to the exploitation of this vulnerability in CWP, but not "activated" - are there just waiting to a request that activates the malicious payload.
The WAF rules provided here can help, but don't fix the problem if your server is already affected.
The good news is that CWP already "silently patched" this vulnerability, so you should be safe from be attacked again if you use CWP.
I didn't check all the WAF rules provided here, but the request is activated with a specific query in a POST request made to the files placed in your server. If you simply access the files, they do nothing.
It should be a request like "domain.xxxx/defaiult.php?t=XXXXXXXXXX" - where XXXXXXXXXX is a specific query.
I did decode the files, and they install a webshell - thats it. What they do after that is from the attacker point of interest.
Unfortunately, if you have been affected by this, you have two options:
- Try to see the files that have been recently changed in your system. Not just the account that is affected, but ALL the system. After that, see if something was malicious changed.
- Don't consider the server safe. Try to deploy your accounts in a fresh new server - and make sure that every single website is also clean. Use something like WordFence, or more abroad, something like CPGuard to scan the accounts.
-
Cool. Thank you