Recent Posts
31
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/
32
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.
33
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?
34
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by Starburst on July 08, 2026, 08:06:59 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.
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.
35
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by 6Sense on July 08, 2026, 04:21:17 AM »Changing SSH port is imperative IMO.
Just be aware that the gsocket exploit bypasses the firewall entirely (doesn't matter what ports you block) so this is not an effective measure against it. Was glad to see multiple CWP version upgrades in quick succession to help keep us safe.
Just be aware that the gsocket exploit bypasses the firewall entirely (doesn't matter what ports you block) so this is not an effective measure against it. Was glad to see multiple CWP version upgrades in quick succession to help keep us safe.
36
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by xwete on July 08, 2026, 04:06:34 AM »None of my servers were hit. Probably because I'm running low on the radar to script kiddies, worms, and Shodan.
https://azdigi.com/en/blog/webserver-panel/centos-web-panel/how-to-change-the-port-on-centos-web-panel-cwp
https://wiki.centos-webpanel.com/how-to-change-ssh-port
Yeah, I never use port 22 on my servers either — it's one of the first things I change during configuration. But since the issue came from public panel access, you probably weren't affected because you changed CWP's default ports or had other protections. Now that I know CWP access is risky, I'll put it behind a firewall or block public access entirely.
37
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by overseer on July 08, 2026, 03:03:48 AM »None of my servers were hit. Probably because I'm running low on the radar to script kiddies, worms, and Shodan.
https://azdigi.com/en/blog/webserver-panel/centos-web-panel/how-to-change-the-port-on-centos-web-panel-cwp
https://wiki.centos-webpanel.com/how-to-change-ssh-port
https://azdigi.com/en/blog/webserver-panel/centos-web-panel/how-to-change-the-port-on-centos-web-panel-cwp
https://wiki.centos-webpanel.com/how-to-change-ssh-port
38
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by xwete on July 08, 2026, 01:21:10 AM »Thanks, but maybe some introductions are in order...
Sure, introductions are fair.
I've run CWP for about 5 years, and all 5 of my servers on the panel got hit in this wave. I spent several days doing the cleanup myself, so what I'm sharing are my own notes from actually working these boxes, not theory.
Here is what it came down to on my side, now that the picture is clear.
The entry point was the panel, not SSH and not the database port. In my case it lines up with the newer bug, CVE-2026-57517, the unauthenticated blind SQL injection in the panel (the userRes parameter). It runs inside the panel's own MySQL root session, so the injected SQL executes as root on its own, then it writes a PHP file to a web path and that gives remote code execution, then full root. It was fixed in 0.9.8.1225, but that fix landed around the July disclosure, which is after my servers were already breached in June, so at the time there was no patch to apply even on a fully updated box. The older file manager RCE (CVE-2025-48703, fixed a year ago in 0.9.8.1205) was not my vector, my boxes had been patched against that one for months.
The part I want people to take away: the firewall was never what saved or doomed a box here. One of my servers had a full firewall (CSF) and still got rooted, because the panel ports have to stay open for you to administer them, so the firewall was gating the database and the random ports but never the panel itself. Every one of my servers was rooted the exact same way through the panel, firewall or not. What actually differed from one box to the next was only what each server was worth to the attacker, so a static content server just got the backdoor while my main WordPress site is where they went after the app layer.
So the real fix on my end was not another IP rule. I closed the panel ports to the public completely, and I now reach them only through an SSH tunnel, with the key itself protected by a passphrase. Nothing on those ports is exposed to the internet anymore, even if my IP changes or the next panel bug drops.
39
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by xwete on July 07, 2026, 11:47:04 PM »
Another new AI troll account with a very, very supicious link at the end...
No wonder, I've largely resolved the leaks with AI tools that CWP's fix couldn't address. Plus they destroyed the root user's authorized keys, which caused a lot of concern among forum users.
Rentry is just a pastebin service with markdown, so there's no risk. https://www.scamadviser.com/check-website/rentry.co?url=%2Fh2cqmbco
However, I also resolved quite a few issues on my end with Wordfence and ClamAV. Despite the fixes CWP quietly applied, the damage was already too extensive, so I think this will help a lot of users. I can't see how CWP can fix the intrusion of malicious scripts when the behavior can vary from one server to another. The truth is that thousands of servers have been infiltrated by one or more malicious hackers, and surely thousands of servers have backdoors that give unlimited access to any bad actor without the owners even knowing.
This is the first time I've left a review because on my end, what the intruder managed to pull off on my servers was very serious.
Translated with GLM 5 xD
40
CentOS-WebPanel Bugs / Re: CVE-2025-48703 + CVE-2026-57517: the gsocket systemd backdoor CWP's
« Last post by Starburst on July 07, 2026, 03:17:09 PM »
Another new AI troll account with a very, very supicious link at the end...
