Recent Posts
41
Other / Re: New CVEs in Linux Kernel: CVE-2026-53359, CVE-2026-46242, CVE-2026-43499
« Last post by cgauthey on July 11, 2026, 06:21:45 PM »In my case, when I update the server, it prevents startup with the CWP secure kernel.
42
Updates / Re: CWP7: 0.9.8.1230
« Last post by jlout on July 11, 2026, 08:12:22 AM »0.9.8.1244 and the problem persists.
The log clearly shows that when it begins the backup process, while reaching the end of the first one in order it will successfully move and delete the tar.gz but it will also delete the marker file inside /home/tmp_bak/.backup_temp (the default temp folder, yours may differ) which gives the following message:
"SAFE_CLEANUP_DIR: BLOCKED - no marker file in /home/tmp_bak/.backup_temp, refusing to delete."
It should be really simple to fix but i cannot see/edit the backup_cron because i believe it is encrypted.
Either way, please fix this problem. I have been watching the backup because it fills up my disk space and i have to babysit it while the backup takes place.
Thank you
The log clearly shows that when it begins the backup process, while reaching the end of the first one in order it will successfully move and delete the tar.gz but it will also delete the marker file inside /home/tmp_bak/.backup_temp (the default temp folder, yours may differ) which gives the following message:
"SAFE_CLEANUP_DIR: BLOCKED - no marker file in /home/tmp_bak/.backup_temp, refusing to delete."
It should be really simple to fix but i cannot see/edit the backup_cron because i believe it is encrypted.
Either way, please fix this problem. I have been watching the backup because it fills up my disk space and i have to babysit it while the backup takes place.
Thank you
43
Updates / Re: CWP7: 0.9.8.1243
« Last post by Reikor on July 10, 2026, 04:14:17 PM »Dev Team Member went Rogue and start Hacking CWPro servers, thats why the updates.
nop, only new hackers with AI are now attacking...but we solve them.
ok so its way worse... i get it. ill let you work, just keep in mind to drop some changelogs so we are aware of changes because some of them are messing with our works, i have to nullified your script to keep my servers working.
Also it would be good if you let us know if they are accesing trough 2087, 2083 or just simple ssh or how so we can firewall the entire server.
44
Other / Re: New CVEs in Linux Kernel: CVE-2026-53359, CVE-2026-46242, CVE-2026-43499
« Last post by overseer on July 10, 2026, 03:14:05 AM »Let the summer of AI fuzzing continue!
45
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by Netino on July 09, 2026, 11:41:57 PM »The issue with the 'temp_hacker_check' script's SSH key removal process is that the script is poorly coded; it removes SSH keys for a specific list of users, including the 'operator' user, which shares the same home directory as the 'root' user (/root).
By deleting the contents of the .ssh directory from 'operator' user, it inadvertently deletes the contents of /root/.ssh.
Therefore, rather than modifying the script itself, a simple and effective solution for future versions is to change the 'operator' user's home directory:
The 'operator' user is a standard user created by Linux long ago specifically for backups. It is created with the same user ID as root (0) but uses an unprivileged shell; this change does not affect server operations.
I implemented this modification on my servers six days ago; it is working well, and the 'root' user's SSH keys are no longer being deleted.
Regards,
Netino
By deleting the contents of the .ssh directory from 'operator' user, it inadvertently deletes the contents of /root/.ssh.
Therefore, rather than modifying the script itself, a simple and effective solution for future versions is to change the 'operator' user's home directory:
Code: [Select]
# usermod -d /root/operator operatorThe 'operator' user is a standard user created by Linux long ago specifically for backups. It is created with the same user ID as root (0) but uses an unprivileged shell; this change does not affect server operations.
I implemented this modification on my servers six days ago; it is working well, and the 'root' user's SSH keys are no longer being deleted.
Regards,
Netino
46
Other / New CVEs in Linux Kernel: CVE-2026-53359, CVE-2026-46242, CVE-2026-43499
« Last post by cyberspace on July 09, 2026, 09:53:54 PM »It is time to update the servers and reboot 
https://almalinux.org/blog/2026-07-09-ghostlock/
https://almalinux.org/blog/2026-07-06-januscape-bad-epoll/
https://almalinux.org/blog/2026-07-09-ghostlock/
https://almalinux.org/blog/2026-07-06-januscape-bad-epoll/
47
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by xwete on July 09, 2026, 06:41:48 AM »The date math isn't mathing...
No offense.
The CVE you posted here, CVE-2026-57517.
https://nvd.nist.gov/vuln/detail/CVE-2026-57517
And was published on 2026-07-01. CWP had fixed that security hole as the CVE shows with 0.9.8.1225 and later.
CWP 0.9.8.1225 was pushed to servers on the night of 2026-05-06.
CWP 0.9.8.1226 was pushed to servers on the night of 2026-05-10
--
CVE CVE-2025-48703:
https://nvd.nist.gov/vuln/detail/CVE-2025-48703
And was published on 2025-09-19. CWP had fixed that security hole as the CVE shows with 0.9.8.1205 and later.
CWP 0.9.8.1205 was pushed to servers on the night of 2025-06-16.
CWP had those 2 security holes patched almost 2 months BEFORE the CVE's came out.
So if you had an up2date server, the security holes were already closed, and wouldn't allow hackers in using those methods.
I've also never seen a SysAdmin leave SSH on the default port and not behind some kind of firewall to limited access.
If you are truly running 5 servers for 5 years, I'm guessing these are EOL (2024-06-30) CentOS 7 boxes from the date you gave.
The CWP migration tool works between CentOS 7 and AlmaLinux 8.
Unfortuently, it currently doesn't between CentOS 7 and AlmaLinux 9, or AlmaLinux 8 -> AlmaLinux 9.
Changing SSH port is imperative IMO.Definitely don't run on port 22, and even 2222 is not safe from FritzFrog:
https://arstechnica.com/information-technology/2022/02/after-lying-low-ssh-botnet-mushrooms-and-is-harder-than-ever-to-take-down/
You are right on the dates, and here is the detail that actually proves your point for me: I am on 0.9.8.1244, and my box carries /scripts/temp_hacker_check, which only ships from 1239 onward. So my panel is clearly auto-updating, which means I was patched against both CVE-2025-48703 (fixed 1205) and CVE-2026-57517 (fixed 1225) well before my June compromise. So neither of those was my entry point. Thanks for pushing on it.
Two quick corrections on the assumptions, though. My SSH runs on a custom port behind a firewall, not open on 22. And the boxes are not EOL CentOS 7: turin is AlmaLinux 8.10 and the others are fresh AlmaLinux and Rocky 9 installs. The "5 years" is how long I have run CWP, not the age of the OS.
To be honest, I do not know my exact entry point, and I am not going to pretend I do. The panel CVEs are ruled out, and the foothold was found too late to prove the vector (the June access logs had already rotated). It was likely something the panel does not patch, or an earlier window before I was current. The one lead I am still looking at is my own Roundcube, which was on an old version and exposed on 2095/2096, and which the panel updater does not keep current (even the version it ships is still behind on CVE-2025-49113). I have closed those ports either way. But that is a hypothesis, not a proven entry.
What I can say for certain is that being current on the panel did not protect me, and the backdoor that got planted survived everything. It is a gsocket reverse shell running as a systemd service disguised as a kernel thread, and CWP's own cleanup never removes it.
That cleanup is the tell. CWP shipped temp_hacker_check to the whole fleet in 1239. There is no CVE for it, because it is not a patch, it is an eviction script: it strips the IPCsi58x attacker key, null routes gsocket[.]io in /etc/hosts, and locks the operator account. You do not push that to every server unless you already know a lot of patched boxes are still carrying the backdoor. Patching closes the door. It does not evict someone already inside.
So I am dropping the claim that a CVE was my way in, you were right about that. I am not replacing it with another guess dressed up as fact. What holds is the persistence, the IOCs, and the detector, and the plain fact that a patched box is not a clean box. I have corrected the linked writeup accordingly.
48
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by overseer on July 08, 2026, 02:43:22 PM »Changing SSH port is imperative IMO.Definitely don't run on port 22, and even 2222 is not safe from FritzFrog:
https://arstechnica.com/information-technology/2022/02/after-lying-low-ssh-botnet-mushrooms-and-is-harder-than-ever-to-take-down/
49
Backup / Re: problem with the local beta backup
« Last post by cgauthey on July 08, 2026, 01:49:29 PM »Bug Report – CWP SFTP Backup Compatibility with SFTPGo
Hello,
I would like to report what appears to be a compatibility issue between the CWP SFTP backup feature and SFTPGo.
Environment
CWP: Latest available version
Backup Server: SFTPGo (latest Docker image)
Protocol: SFTP / SSH
Port: 22
Authentication: Username + Password
Issue Description
When configuring an SFTP backup destination in CWP, the connection always fails with the following error:
Login Failed:
Permission denied, please try again.
Received disconnect from xxx.xxx.xxx.xxx port 22:2:
too many authentication failures
At first glance, this appears to be an authentication problem, but after analyzing the SFTPGo server logs, the issue is actually different.
Investigation
The SFTPGo logs show that CWP performs several authentication attempts in the following order:
Public Key authentication
Keyboard-Interactive authentication (without credentials)
Password authentication (without credentials)
Finally, a successful login using keyboard-interactive authentication.
Immediately after the successful authentication, CWP executes the following remote command:
mkdir -p ~/.ssh &&
chmod 700 ~/.ssh &&
echo <public_key> >> ~/.ssh/authorized_keys &&
chmod 600 ~/.ssh/authorized_keys
However, SFTPGo is a pure SFTP server and does not provide an interactive shell.
As a result, SFTPGo returns:
ssh command not enabled/supported: "mkdir"
and the session is terminated.
Root Cause
The current implementation appears to assume that every SFTP server also provides a full SSH shell.
This assumption is not always valid.
Modern SFTP servers such as:
SFTPGo
AWS Transfer Family
Azure SFTP
Google Cloud SFTP
may expose only the SFTP subsystem without allowing remote shell commands.
Because CWP automatically attempts to execute shell commands in order to install an SSH public key, the connection fails even though SFTP authentication itself succeeds.
Expected Behaviour
The SFTP backup feature should support standard RFC-compliant SFTP servers without requiring shell access.
Ideally, CWP should:
perform a standard SFTP login;
verify read/write access using SFTP operations only;
avoid executing remote shell commands unless explicitly requested;
provide an option to disable automatic SSH key installation.
Why this matters
Many hosting providers and secure backup appliances intentionally disable shell access while still offering fully functional SFTP services.
Currently, these servers cannot be used with CWP backups even though they fully support the SFTP protocol.
Supporting pure SFTP servers would improve compatibility with modern backup infrastructures and managed storage services.
Thank you for investigating this issue.
Hello,
I would like to report what appears to be a compatibility issue between the CWP SFTP backup feature and SFTPGo.
Environment
CWP: Latest available version
Backup Server: SFTPGo (latest Docker image)
Protocol: SFTP / SSH
Port: 22
Authentication: Username + Password
Issue Description
When configuring an SFTP backup destination in CWP, the connection always fails with the following error:
Login Failed:
Permission denied, please try again.
Received disconnect from xxx.xxx.xxx.xxx port 22:2:
too many authentication failures
At first glance, this appears to be an authentication problem, but after analyzing the SFTPGo server logs, the issue is actually different.
Investigation
The SFTPGo logs show that CWP performs several authentication attempts in the following order:
Public Key authentication
Keyboard-Interactive authentication (without credentials)
Password authentication (without credentials)
Finally, a successful login using keyboard-interactive authentication.
Immediately after the successful authentication, CWP executes the following remote command:
mkdir -p ~/.ssh &&
chmod 700 ~/.ssh &&
echo <public_key> >> ~/.ssh/authorized_keys &&
chmod 600 ~/.ssh/authorized_keys
However, SFTPGo is a pure SFTP server and does not provide an interactive shell.
As a result, SFTPGo returns:
ssh command not enabled/supported: "mkdir"
and the session is terminated.
Root Cause
The current implementation appears to assume that every SFTP server also provides a full SSH shell.
This assumption is not always valid.
Modern SFTP servers such as:
SFTPGo
AWS Transfer Family
Azure SFTP
Google Cloud SFTP
may expose only the SFTP subsystem without allowing remote shell commands.
Because CWP automatically attempts to execute shell commands in order to install an SSH public key, the connection fails even though SFTP authentication itself succeeds.
Expected Behaviour
The SFTP backup feature should support standard RFC-compliant SFTP servers without requiring shell access.
Ideally, CWP should:
perform a standard SFTP login;
verify read/write access using SFTP operations only;
avoid executing remote shell commands unless explicitly requested;
provide an option to disable automatic SSH key installation.
Why this matters
Many hosting providers and secure backup appliances intentionally disable shell access while still offering fully functional SFTP services.
Currently, these servers cannot be used with CWP backups even though they fully support the SFTP protocol.
Supporting pure SFTP servers would improve compatibility with modern backup infrastructures and managed storage services.
Thank you for investigating this issue.
50
Backup / problem with the local beta backup
« Last post by cgauthey on July 08, 2026, 01:37:42 PM »I notice this problem with the local beta backup
I am encountering an issue with the local backup restore feature (beta version).
Hello,
We are experiencing a problem with the new local backup restore feature on our server.
The backup files are present on the server and appear to be complete and intact. However, the restore process does not start correctly.
Whenever we attempt to restore an account, the process consistently gets stuck at the "Detecting files" stage and makes no further progress.
The restore log repeatedly shows the following information:
2026-07-07 14:14:06 UPDATE restore SET ST='20260707201406' WHERE ST='1'
2026-07-07 14:14:06 >>>>>>>>> [1,1,1,1,1,1,1,1,1,grizzy,2026-06-27_17-15-04,0,,1,1,1,1,1]
2026-07-07 14:14:06 Detecting files
We have verified that the backup directory exists and that all backup archives are available.
Based on our investigation, it appears that the restore utility is generating an incorrect path and attempting to locate a non-existent backup archive, even though the backup data is available at the correct location.
Could you please check if this is a known issue with this new local backup restore feature?
If so, is there a fix, a workaround, or an updated restore procedure available to successfully restore the accounts?
I am encountering an issue with the local backup restore feature (beta version).
Hello,
We are experiencing a problem with the new local backup restore feature on our server.
The backup files are present on the server and appear to be complete and intact. However, the restore process does not start correctly.
Whenever we attempt to restore an account, the process consistently gets stuck at the "Detecting files" stage and makes no further progress.
The restore log repeatedly shows the following information:
2026-07-07 14:14:06 UPDATE restore SET ST='20260707201406' WHERE ST='1'
2026-07-07 14:14:06 >>>>>>>>> [1,1,1,1,1,1,1,1,1,grizzy,2026-06-27_17-15-04,0,,1,1,1,1,1]
2026-07-07 14:14:06 Detecting files
We have verified that the backup directory exists and that all backup archives are available.
Based on our investigation, it appears that the restore utility is generating an incorrect path and attempting to locate a non-existent backup archive, even though the backup data is available at the correct location.
Could you please check if this is a known issue with this new local backup restore feature?
If so, is there a fix, a workaround, or an updated restore procedure available to successfully restore the accounts?
