Control Web Panel
WebPanel => CentOS-WebPanel Bugs => Topic started by: kandalf on July 07, 2025, 03:29:52 PM
-
I’m 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 CWP’s file handling or directory security
⚠️ Request to CWP Team
Please investigate this urgently. It’s 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, I’m 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.
-
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.
-
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.
It’s 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.)
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:
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, 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 (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
-
@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 Attacker’s 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.