Recent Posts
31
CentOS-WebPanel Bugs / CWP Cronjob Killing Server
« Last post by wingusupport on August 16, 2026, 04:36:15 PM »I have been fighting with this problem for days. Seems to have started after a few rounds of software and security updates a few days ago. I have finally narrowed the issue down but have not come up with a permanent fix. I think only CWP can provide the fix.
Also, I fully admit, this could be something I caused. Just yet to determine where or what.
CWPpro version: 1.8
Operating System: AlmaLinux 9.8 (Olive Jaguar)
Apache version: Apache/2.4.68
PHP version: Forced PHP-FPM: 8.3
MySQL version: 10.5.29-MariaDB
FTP version: 1.0.52
SSH Port: 4000
MySql Port: 3306
Web Servers: nginx-apache
Problem: After the CWP cronjob runs, the permissions on Mariadb are modified rendering the server unusable. No websites, no webmail, no service at all.
Testing: To recreate problem that forced me to manually fix the dead CWP server (after determining the what was triggering the issue), run # bash /etc/cron.daily/cwp.
Output: However, the PHP warning seems benign.
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
====================================================
============= CentOS Web Panel Cron ================
====================================================
###########################
Firewall Flush Daily Blocks
###########################
######################
Update Server Packages
######################
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
grep: /usr/local/cwpsrv/logs/error_log: binary file matches
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Redirecting to /bin/systemctl restart cwpsrv.service
Redirecting to /bin/systemctl restart httpd.service
Redirecting to /bin/systemctl reload httpd.service
Redirecting to /bin/systemctl reload nginx.service
Redirecting to /bin/systemctl reload httpd.service
cp: cannot stat '/root/.ssh/authorized_keys': No such file or directory
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Date which backup script is using: 2026-08-16 12:15:07
# systemctl start mariadb
Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xeu mariadb.service" for details.
Temporary Fix: I manually execute the following every morning now to resuscitate the CWP Server. Clients are not happy with this arrangement.[/]
**Use with caution and at your own risk!** (In case anyone else is experiencing this issue.)
chmod 755 / /usr /usr/bin /usr/sbin /usr/lib /usr/lib64 /var /var/lib /var/log
chown -R mysql:mysql /var/lib/mysql
chmod 755 /var/lib/mysql
systemctl daemon-reload
systemctl start mariadb
systemctl status mariadb --no-pager
systemctl restart dovecot postfix cbpolicyd opendkim cwpsrv httpd
systemctl status mariadb dovecot postfix cwpsrv --no-pager
Permanent Fix: Not discovered yet. Hoping for a CWP team based solution as the scripts are not viewable nor modifiable. I'm okay with that. Just hoping for a permanent solution fix.
In addition: I have three CWP server that the NEW Backup (beta) restore feature does not show the Restore Points for the user account. All of this started about the same time.
Automated Temporary Fix:
**Use with caution and at your own risk!** (In case anyone else is experiencing this issue.)
Step One:
cat << 'EOF' > /etc/cron.daily/dw-fix-mariadb
#!/bin/bash
chmod 755 / /usr /usr/bin /usr/sbin /usr/lib /usr/lib64 /var /var/lib /var/log
chown -R mysql:mysql /var/lib/mysql
chmod 755 /var/lib/mysql
systemctl daemon-reload
systemctl start mariadb
systemctl status mariadb --no-pager
systemctl restart dovecot postfix cbpolicyd opendkim cwpsrv httpd
systemctl status mariadb dovecot postfix cwpsrv --no-pager
EOF
Step Two:
chmod +x /etc/cron.daily/dw-fix-mariadb
Step Three:
bash /etc/cron.daily/dw-fix-mariadb
Step Four:
Keep checking server each morning to be sure it's running properly.
Also, I fully admit, this could be something I caused. Just yet to determine where or what.
CWPpro version: 1.8
Operating System: AlmaLinux 9.8 (Olive Jaguar)
Apache version: Apache/2.4.68
PHP version: Forced PHP-FPM: 8.3
MySQL version: 10.5.29-MariaDB
FTP version: 1.0.52
SSH Port: 4000
MySql Port: 3306
Web Servers: nginx-apache
Problem: After the CWP cronjob runs, the permissions on Mariadb are modified rendering the server unusable. No websites, no webmail, no service at all.
Testing: To recreate problem that forced me to manually fix the dead CWP server (after determining the what was triggering the issue), run # bash /etc/cron.daily/cwp.
Output: However, the PHP warning seems benign.
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
====================================================
============= CentOS Web Panel Cron ================
====================================================
###########################
Firewall Flush Daily Blocks
###########################
######################
Update Server Packages
######################
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
grep: /usr/local/cwpsrv/logs/error_log: binary file matches
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Redirecting to /bin/systemctl restart cwpsrv.service
Redirecting to /bin/systemctl restart httpd.service
Redirecting to /bin/systemctl reload httpd.service
Redirecting to /bin/systemctl reload nginx.service
Redirecting to /bin/systemctl reload httpd.service
cp: cannot stat '/root/.ssh/authorized_keys': No such file or directory
PHP Warning: PHP Startup: Unable to load dynamic library 'intl' (tried: /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl: cannot open shared object file: No such file or directory), /usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so (/usr/local/cwp/php71/lib/php/extensions/no-debug-non-zts-20190902/intl.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
Date which backup script is using: 2026-08-16 12:15:07
# systemctl start mariadb
Job for mariadb.service failed because the control process exited with error code.
See "systemctl status mariadb.service" and "journalctl -xeu mariadb.service" for details.
Temporary Fix: I manually execute the following every morning now to resuscitate the CWP Server. Clients are not happy with this arrangement.[/]
**Use with caution and at your own risk!** (In case anyone else is experiencing this issue.)
chmod 755 / /usr /usr/bin /usr/sbin /usr/lib /usr/lib64 /var /var/lib /var/log
chown -R mysql:mysql /var/lib/mysql
chmod 755 /var/lib/mysql
systemctl daemon-reload
systemctl start mariadb
systemctl status mariadb --no-pager
systemctl restart dovecot postfix cbpolicyd opendkim cwpsrv httpd
systemctl status mariadb dovecot postfix cwpsrv --no-pager
Permanent Fix: Not discovered yet. Hoping for a CWP team based solution as the scripts are not viewable nor modifiable. I'm okay with that. Just hoping for a permanent solution fix.
In addition: I have three CWP server that the NEW Backup (beta) restore feature does not show the Restore Points for the user account. All of this started about the same time.
Automated Temporary Fix:
**Use with caution and at your own risk!** (In case anyone else is experiencing this issue.)
Step One:
cat << 'EOF' > /etc/cron.daily/dw-fix-mariadb
#!/bin/bash
chmod 755 / /usr /usr/bin /usr/sbin /usr/lib /usr/lib64 /var /var/lib /var/log
chown -R mysql:mysql /var/lib/mysql
chmod 755 /var/lib/mysql
systemctl daemon-reload
systemctl start mariadb
systemctl status mariadb --no-pager
systemctl restart dovecot postfix cbpolicyd opendkim cwpsrv httpd
systemctl status mariadb dovecot postfix cwpsrv --no-pager
EOF
Step Two:
chmod +x /etc/cron.daily/dw-fix-mariadb
Step Three:
bash /etc/cron.daily/dw-fix-mariadb
Step Four:
Keep checking server each morning to be sure it's running properly.
32
Other / Re: Something is intercepting bots and loading a different page for them.
« Last post by xelavalle on August 15, 2026, 08:49:19 PM »As I mentioned in my previous response, the cause of the hack has been located; it's in geodim's answer.
It was infected with a backdoor Python script running as a fake ntpd process. The redirection is handled by a fake Apache module, mod_auth_form.so, which links to the libcurl library.
I'm almost certain that these fake files were uploaded to my server during the last CWP File Manager breach.
The link geodim provided (https://frantic-bytes.gr/blog/index.php/post/96/CWP+Something+is+intercepting+bots+and+loading+a+different+page+for+them) contains the steps to verify whether the files are real or fake, and to proceed with terminating the hacker's service and deleting those files.
In my case, the strings check didn't find any suspicious strings within mod_auth_form.so, but it failed the RPM integrity check, resulting in a checksum indicating a fake mod_auth_form.so file.
Similarly, the fake /usr/bin/ntpd file was enormous, many megabytes in size, while the originals are small.
By killing the service, deleting those files, and restarting Apache, the selective redirection disappeared.
It was infected with a backdoor Python script running as a fake ntpd process. The redirection is handled by a fake Apache module, mod_auth_form.so, which links to the libcurl library.
I'm almost certain that these fake files were uploaded to my server during the last CWP File Manager breach.
The link geodim provided (https://frantic-bytes.gr/blog/index.php/post/96/CWP+Something+is+intercepting+bots+and+loading+a+different+page+for+them) contains the steps to verify whether the files are real or fake, and to proceed with terminating the hacker's service and deleting those files.
In my case, the strings check didn't find any suspicious strings within mod_auth_form.so, but it failed the RPM integrity check, resulting in a checksum indicating a fake mod_auth_form.so file.
Similarly, the fake /usr/bin/ntpd file was enormous, many megabytes in size, while the originals are small.
By killing the service, deleting those files, and restarting Apache, the selective redirection disappeared.
33
Updates / Re: CWP 1.8 – Can we have a clear Production Readiness / Fixed Issues list?
« Last post by Xweb on August 15, 2026, 12:29:25 PM »Coming back to the actual purpose of this thread
Thanks for the formatting suggestion. I will use BBCode for the forum posts.
However, I would like to bring the discussion back to the actual purpose of this thread, because the technical questions raised in the original post are still unanswered.
The purpose was not to produce a perfect-looking post, nor to complain about individual bugs.
The purpose was to try to create, together with the CWP team and the community, a single place where we can establish the current production status of CWP 1.x.
At the moment, we have individual forum threads reporting individual problems, but it is often difficult to determine:
For a system administrator running production servers, this information is extremely important.
The question is very simple:
Can I safely update my production CWP server, and if I do, what should I specifically monitor afterwards?
This is why I believe a simple, maintained status list would be much more useful than scattered individual reports.
I would especially like to keep the focus on Backup / Restore / Reporting.
The New Backup system has been in beta/development for a long time, and I think we need to distinguish three different things:
1. Backup
Does the backup job actually complete correctly, both locally and remotely?
2. Restore
Can we reliably restore an account from that backup when we actually need it?
This is probably the most important question.
A backup that reports "completed successfully" is only useful if the corresponding restore has also been tested and is reliable.
Can CWP clarify which restore scenarios are currently tested and considered production-ready?
3. Email reporting
This is a separate issue that I have personally reported.
Even when a backup job runs, the administrator needs reliable reporting:
If the backup runs but the notification is missing or incomplete, the administrator does not have reliable visibility of the backup status.
This is why I don't think "use an external backup solution" answers the question.
Administrators can certainly use external backup systems, and many of us do.
But CWP also provides a Backup/Restore system, and it is reasonable to ask what its current production status actually is.
The same applies to the update process.
I understand that emergency security releases can sometimes require accelerated development and reduced testing.
However, after such releases, it becomes even more important to clearly communicate:
The CWP changelog currently does not provide enough detail for an administrator to reconstruct this information reliably.
So I would like to ask the CWP team directly:
Could you please provide an updated status for the issues raised in this thread?
Even a simple table would be enough:
It does not need to be perfect.
What matters is having a clear reference that allows administrators to understand:
what is fixed, what is not fixed, what is still beta, and what requires attention before updating a production server.
That was the reason for opening this thread in the first place.
I would really appreciate a technical response from the CWP team so that we can turn this into something useful for the whole community.
Thanks for the formatting suggestion. I will use BBCode for the forum posts.
However, I would like to bring the discussion back to the actual purpose of this thread, because the technical questions raised in the original post are still unanswered.
The purpose was not to produce a perfect-looking post, nor to complain about individual bugs.
The purpose was to try to create, together with the CWP team and the community, a single place where we can establish the current production status of CWP 1.x.
At the moment, we have individual forum threads reporting individual problems, but it is often difficult to determine:
- whether the problem is a known CWP regression;
- whether it was introduced by a specific update;
- whether it has already been fixed;
- which CWP version contains the fix;
- whether the fix has actually been tested;
- or whether the problem is still considered known/open.
For a system administrator running production servers, this information is extremely important.
The question is very simple:
Can I safely update my production CWP server, and if I do, what should I specifically monitor afterwards?
This is why I believe a simple, maintained status list would be much more useful than scattered individual reports.
I would especially like to keep the focus on Backup / Restore / Reporting.
The New Backup system has been in beta/development for a long time, and I think we need to distinguish three different things:
1. Backup
Does the backup job actually complete correctly, both locally and remotely?
2. Restore
Can we reliably restore an account from that backup when we actually need it?
This is probably the most important question.
A backup that reports "completed successfully" is only useful if the corresponding restore has also been tested and is reliable.
Can CWP clarify which restore scenarios are currently tested and considered production-ready?
3. Email reporting
This is a separate issue that I have personally reported.
Even when a backup job runs, the administrator needs reliable reporting:
- local backup status;
- remote backup status;
- successful accounts;
- failed accounts;
- warnings/errors;
- and reliable notification emails.
If the backup runs but the notification is missing or incomplete, the administrator does not have reliable visibility of the backup status.
This is why I don't think "use an external backup solution" answers the question.
Administrators can certainly use external backup systems, and many of us do.
But CWP also provides a Backup/Restore system, and it is reasonable to ask what its current production status actually is.
The same applies to the update process.
I understand that emergency security releases can sometimes require accelerated development and reduced testing.
However, after such releases, it becomes even more important to clearly communicate:
- what changed;
- what was tested;
- what could not be tested;
- what regressions are known;
- and what has subsequently been fixed.
The CWP changelog currently does not provide enough detail for an administrator to reconstruct this information reliably.
So I would like to ask the CWP team directly:
Could you please provide an updated status for the issues raised in this thread?
Even a simple table would be enough:
Code: [Select]
Component Status Fixed in Notes
--------------------------------------------------------
Backup Stable / Beta x.x.x ...
Restore Stable / Beta x.x.x ...
Reporting Open / Fixed x.x.x ...
UI Open / Fixed x.x.x ...
ModSecurity Open / Fixed x.x.x ...
CSF/Firewall Open / Fixed x.x.x ...
YUM Manager Open / Fixed x.x.x ...
PHP Selector Open / Fixed x.x.x ...
It does not need to be perfect.
What matters is having a clear reference that allows administrators to understand:
what is fixed, what is not fixed, what is still beta, and what requires attention before updating a production server.
That was the reason for opening this thread in the first place.
I would really appreciate a technical response from the CWP team so that we can turn this into something useful for the whole community.
34
Other / Re: Something is intercepting bots and loading a different page for them.
« Last post by cyberspace on August 15, 2026, 09:38:33 AM »Did you check the .htaccess file? Make sure your sites don’t contain any suspicious or obfuscated code. This could also happen if your website loads files or resources from a compromised third-party site.
If you identified the user agents that trigger the redirect, try searching the web server configs and website files for those user agents.
If you identified the user agents that trigger the redirect, try searching the web server configs and website files for those user agents.
35
Backup / Error/bug when starting a backup
« Last post by André Bastos on August 14, 2026, 08:45:25 PM »What used to work has stopped working for no apparent reason. Does anyone have a solution? This is disrupting the smooth operation of our processes.
When clicking RUN to start the manual backup of some accounts before removing them, we now get the following error:
Error...!
You must activate the backup first and then run it
When clicking RUN to start the manual backup of some accounts before removing them, we now get the following error:
Error...!
You must activate the backup first and then run it
36
Other / Re: Something is intercepting bots and loading a different page for them.
« Last post by xelavalle on August 14, 2026, 10:25:55 AM »Thanks for your replies; they are valuable for understanding the issue.
It turns out to be the same case Geodim described; I followed the steps outlined on his blog, and the problem was resolved. Many thanks!
That leads me to ask: isn't CWP supposed to show an alert if a system file is modified? Does the fact that it didn't show one mean something else has been altered?
It turns out to be the same case Geodim described; I followed the steps outlined on his blog, and the problem was resolved. Many thanks!
That leads me to ask: isn't CWP supposed to show an alert if a system file is modified? Does the fact that it didn't show one mean something else has been altered?
37
PHP / Re: PHP Version Switcher
« Last post by infoselva on August 14, 2026, 06:00:31 AM »Hi, I tried to install PHP 8.5 but alwails fail afet packaging, installing and checking get this message and I do not know what to do:
Configuring extensions
checking for io.h... no
checking for strtoll... yes
checking for atoll... yes
checking whether the C compiler accepts -Wno-implicit-fallthrough... yes
checking whether the C compiler accepts -fwrapv... yes
checking whether to build with LIBXML support... yes
checking for libxml-2.0 >= 2.9.4... no
configure: error: Package requirements (libxml-2.0 >= 2.9.4) were not met:
Requested 'libxml-2.0 >= 2.9.4' but version of libXML is 2.9.1
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables LIBXML_CFLAGS
and LIBXML_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.
Build Completed
###################
Notification added
Configuring extensions
checking for io.h... no
checking for strtoll... yes
checking for atoll... yes
checking whether the C compiler accepts -Wno-implicit-fallthrough... yes
checking whether the C compiler accepts -fwrapv... yes
checking whether to build with LIBXML support... yes
checking for libxml-2.0 >= 2.9.4... no
configure: error: Package requirements (libxml-2.0 >= 2.9.4) were not met:
Requested 'libxml-2.0 >= 2.9.4' but version of libXML is 2.9.1
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables LIBXML_CFLAGS
and LIBXML_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target `install'. Stop.
Build Completed
###################
Notification added
38
Other / Re: Something is intercepting bots and loading a different page for them.
« Last post by geodim on August 14, 2026, 12:26:05 AM »for some reason I cannot post the whole answer here, so I made an external post about your case which I came across on one of my servers too
https://frantic-bytes.gr/blog/index.php/post/96/CWP+Something+is+intercepting+bots+and+loading+a+different+page+for+them
https://frantic-bytes.gr/blog/index.php/post/96/CWP+Something+is+intercepting+bots+and+loading+a+different+page+for+them
39
Other / Re: Something is intercepting bots and loading a different page for them.
« Last post by 6Sense on August 13, 2026, 10:05:54 PM »I've pasted a couple of threads below for you to read up on, are also many different threads on the issues. There were 2 issues in the past few months (both patched now). As your finding though they can be difficult to find and persistant in nature. Searching for defauit.php (spelt with an i) is worth searching for, it was common in the 1st issue.
But as you've already stated if you can't locate/nullify the issue IMO a fresh install is the answer. Just do your reseach on upgrades you will need to do on a fresh install, maybe even a practice run before moving the prod server.
https://forum.centos-webpanel.com/centos-webpanel-bugs/cve-2025-48703-cve-2026-57517-the-gsocket-systemd-backdoor-cwp-s/
https://forum.centos-webpanel.com/centos-webpanel-bugs/critical-multiple-cwp-servers-infected-arbitrary-php-code-execution-via-publ/
But as you've already stated if you can't locate/nullify the issue IMO a fresh install is the answer. Just do your reseach on upgrades you will need to do on a fresh install, maybe even a practice run before moving the prod server.
https://forum.centos-webpanel.com/centos-webpanel-bugs/cve-2025-48703-cve-2026-57517-the-gsocket-systemd-backdoor-cwp-s/
https://forum.centos-webpanel.com/centos-webpanel-bugs/critical-multiple-cwp-servers-infected-arbitrary-php-code-execution-via-publ/
40
Other / Re: Something is intercepting bots and loading a different page for them.
« Last post by xelavalle on August 13, 2026, 04:16:01 PM »I’ve already checked the logs and configuration—nothing suspicious there. That server had been running fine for about 10 years until the CWP admin File Manager was hacked a few months ago; I’m 99.9% sure that’s where the malicious code got in. I recall the index file being overwritten with a page identical to that "welcome" page; we cleaned everything up, but clearly, something was left behind.
I’ll have to find the time to wipe the drive and do a clean reinstallation from scratch, but that’s tricky since it’s a production server.
I’ll have to find the time to wipe the drive and do a clean reinstallation from scratch, but that’s tricky since it’s a production server.
