Recent Posts
31
CentOS-WebPanel Bugs / Re: I think there is a very serious security vulnerability in CWP right now.
« Last post by Logician on June 20, 2026, 01:52:23 PM »Our server was also one of the victims of this issue.
For safety reasons, we are dumping this server and moving to a new server now because we can't make sure how comprimised the server is while attacker has root access for days.
I wanted to share my way of dealing with it but forum is rejecting some parts of my post (probably because of mod_security). Let me know if there is another way to share it with everyone:
For safety reasons, we are dumping this server and moving to a new server now because we can't make sure how comprimised the server is while attacker has root access for days.
I wanted to share my way of dealing with it but forum is rejecting some parts of my post (probably because of mod_security). Let me know if there is another way to share it with everyone:
Code: [Select]
#check if there is someone connected to your server except you:
netstat -antp | grep -E "ESTABLISHED|LISTEN"
#if yes, kill its process and ban the ip
kill [PID]
=============================
#Then Hunt for the signature:
grep -R "/usr/bin/defunct\|mm_percpu_wq" /etc /root /var/spool/cron /usr/local/cwpsrv /usr/local/apache 2>/dev/null > /root/defunct-references-small.log
# You are likely to see this line:
/etc/systemd/system/multi-user.target.wants/defunct.service
ExecStart=/bin/bash -c "GS_ARGS='-k /lib/systemd/system/defunct.dat -ilq' exec -a '[mm_percpu_wq]' '/usr/bin/defunct'"
#Kill it:
systemctl stop defunct.service
systemctl disable defunct.service
rm -f /etc/systemd/system/multi-user.target.wants/defunct.service
rm -f /usr/bin/defunct
rm -f /lib/systemd/system/defunct.dat
systemctl daemon-reload
#recheck:
systemctl status defunct.service
ps aux | grep '[m]m_percpu'
find /etc/systemd /lib/systemd -name '*defunct*' -o -name '*mm_percpu*' 2>/dev/null
#Then go for the injected SSH keys:
find / -path '*/.ssh*' 2>/dev/null
#remove all ssh keys except root:
find / -path '*/.ssh/authorized_keys*' -type f ! -path '/root/.ssh/authorized_keys' -print0 2>/dev/null | while IFS= read -r -d '' f; do
chattr -i "$f" 2>/dev/null
rm -f "$f"
done
# remove all ssh directories except root:
find / -path '*/.ssh' -type d ! -path '/root/.ssh' -print0 2>/dev/null | while IFS= read -r -d '' d; do
chattr -i "$d"/* 2>/dev/null
rm -rf "$d"
done
# own root ssh back:
chown root:root /root/.ssh
chmod 700 /root/.ssh
chattr -i /root/.ssh/authorized_keys
# edit root ssh:
nano /root/.ssh/authorized_keys
# remove all injected lines with CTRL+K and save it with CTRL + X
(if you don't have a SSH key yourself for root, remove that authorized_keys file too rm -f /root/.ssh/authorized_keys )
#now deal with injected php files under public_html
#find injections:
grep -RIl --include='*.php' 'aW5pX3NldCgiZGlzcGxheV9lcnJvcnMi' /home
<forum didn't allow me to post clean line due to mod_security>
#check if its cleaned now:
grep -RIl --include='*.php' 'aW5pX3NldCgiZGlzcGxheV9lcnJvcnMi' /home
#check injected .html / .json / .htaccess files:
<forum didn't allow me to post this line due to mod_security>
#remove injection:
<forum didn't allow me to post this line due to mod_security>
change your root password just in case
32
Backup / Re: Critical Backup Bug After Latest Update (new backup)
« Last post by ljb on June 20, 2026, 04:24:01 AM »I have confirmed that all my instances are set for stable channel updates.
My concern is the erroneous programming that slipped through the cracks for a working feature that worked for months without fail. This effectively deems the emails of a successful backup as null and void and practically unbelievable since it is now evident that there is no checking that the compressed files have landed in the relevant path for each day of a daily backup. This is the local backup feature and technically should be the absolute robust and most reliable option of the lot as there is no external variables to take into account.
Unlike others, I am able to comprehend your stand in the marketplace for an extremely cheap (aspiring to be enterprise-level) web and mail control panel. Perhaps a good and working system starts with absolutely reliable local backups. The onus then remains on the SysAdmin to ship the completed backups to another location to prevent the machine from choking up.
My concern is the erroneous programming that slipped through the cracks for a working feature that worked for months without fail. This effectively deems the emails of a successful backup as null and void and practically unbelievable since it is now evident that there is no checking that the compressed files have landed in the relevant path for each day of a daily backup. This is the local backup feature and technically should be the absolute robust and most reliable option of the lot as there is no external variables to take into account.
Unlike others, I am able to comprehend your stand in the marketplace for an extremely cheap (aspiring to be enterprise-level) web and mail control panel. Perhaps a good and working system starts with absolutely reliable local backups. The onus then remains on the SysAdmin to ship the completed backups to another location to prevent the machine from choking up.
33
CentOS-WebPanel GUI / Re: Bug in GUI for New Backup (beta)
« Last post by vox on June 19, 2026, 10:47:02 PM »I guess I'll reach out to them and see. It gives a invalid username/password error.
34
CentOS-WebPanel GUI / Re: Bug in GUI for New Backup (beta)
« Last post by overseer on June 19, 2026, 10:43:42 PM »Is your IP address whitelisted on their firewalls?
35
CentOS-WebPanel GUI / Re: Bug in GUI for New Backup (beta)
« Last post by vox on June 19, 2026, 08:37:06 PM »Is the new backup broke again? I updated to 0.9.8.1235 and I can't get any back ups to connect to Hetzner servers.
Does anyone has any luck connecting to Hetzner servers?
Does anyone has any luck connecting to Hetzner servers?
36
Backup / Re: Critical Backup Bug After Latest Update (new backup)
« Last post by overseer on June 19, 2026, 11:54:56 AM »There is a beta vs stable track if you prefer the immediate security benefits or the 2 weeks of testing before the updates get pushed out to all users. Your choice of which track.
37
Backup / Re: Critical Backup Bug After Latest Update (new backup)
« Last post by ljb on June 19, 2026, 10:10:29 AM »I'm observing a few successive CWP minor update versions in matter of 10 days. I'm ready to let it run autonomously overnight. Hopefully this is the last time I have to stay awake after 2am.
Perhaps a beta / stable / LTS differentiation in the future can prove helpful to unsolicited coding errors that are caught before making it to production.
Perhaps a beta / stable / LTS differentiation in the future can prove helpful to unsolicited coding errors that are caught before making it to production.
38
CentOS-WebPanel Bugs / Re: I think there is a very serious security vulnerability in CWP right now.
« Last post by Administrator on June 19, 2026, 06:28:00 AM »to resolve hackers issues just update cwp with this script, run the script two times.
This will also be resolved by cwp update automatically so even if you don't run the script it will be updated in 24h.
This will also be resolved by cwp update automatically so even if you don't run the script it will be updated in 24h.
Code: [Select]
/scripts/update_cwp39
CentOS-WebPanel Bugs / Re: I think there is a very serious security vulnerability in CWP right now.
« Last post by Daan on June 18, 2026, 10:08:01 PM »Pleases update cwp sh /scripts/update_cwp
0.9.8.1235 that is fast!
40
CentOS-WebPanel Bugs / Re: I think there is a very serious security vulnerability in CWP right now.
« Last post by Daan on June 18, 2026, 10:05:55 PM »Well, this is so bad that I feel uncomfortable that share it now publicly when there is no fix.
But I can say this:
BLOCK THIS IP NOW!!!! 152.53.173.29 that is the C&C server.
EDIT: Where can I send a message to an dev?
This is a Netcup IP, and they are very good at suspending service of hackers on their network.
You can send the hacker info to: abuse@netcup.de
Great, I send them a mail aswel.
89.248.172.118 is also good to block, it gave the original payload, but it's apparently an IP from an 'bulletproof hoster'.
